The "Kubelet regular resource usage tracking over 30m0s with 0 pods per node"
was broken and fixed after the v1.1.1 cut, by pull request #14603. Trusty
release jobs always pin to the latest release version of k8s, so we would have
to wait until next 1.1 release to pick up the fix. Temporarily skipping that
test for Trusty jobs now.
Just sync the documentation up since the latest [virt7-docker-common-release](http://cbs.centos.org/koji/packages?tagID=112) has newer packages that work together.
Tested this on a single node Centos 7.1 node with the following packages and it all works well so far:
```
yum list -q docker etcd kubernetes flannel
Installed Packages
docker.x86_64 1.8.2-7.el7.centos @extras
etcd.x86_64 2.1.1-2.el7 @extras
flannel.x86_64 0.2.0-10.el7 @extras
kubernetes.x86_64 1.1.0-0.4.git2bfa9a1.el7 @virt7-docker-common-release
```
The node.yaml has some logic that will be also used by the kubernetes
master on trusty work (issue #16702). This change moves the code
shared by the master and node configuration to a separate script, and
the master and node configuration can source it to use the code.
Moreover, this change stages the script for GKE use.
- add busybox static pod to mesos-docker cluster
- customize static pods with binding annotations
- code cleanup
- removed hacky podtask.And func; support minimal resources for static pods when resource accounting is disabled
- removed zip archive of static pods, changed to gzip of PodList json
- pod utilities moved to package podutil
- added e2e test
- merge watched mirror pods into the mesos pod config stream
This adds a very basic Zeppelin image that works with the existing
Spark example. As can be seen from the documentation, it has a couple
of warts:
* It requires kubectl port-forward (which is unstable across long
periods of time, at least for me, on this app, bug incoming). See
* I needed to roll my own container (none of the existing containers
exactly matched needs, or even built anymore against modern Zeppelin
master, and the rest of the example is Spark 1.5).
The image itself is *huge*. One of the further refinements we need to
look at is how to possibly strip the Maven build for this container
down to just the interpreters we care about, because the deps here
are frankly ridiculous.
This might be a case where, if possible, we might want to open an
upstream request to build things dynamically, then use something like
probably the cut the image down considerably. (This might already be
possible, need to poke at whether you can late-bind interpreters
later.)
