hypothesis: The old userspace proxier would internally retry connections. The
new one does not. When this test comes up, the firewall might not yet be open or
something is causing a long delay and a timeout. I can't repro this failure
locally, so I am shooting in the dark. It's sort of plausible.
evidence: I can SSH into the jenkins master that is hung and I can see the hung
curl. I can run that curl by hand and it works. I can see that my shell is in
the same netns as that hung curl.
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
```
- 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.)
