[Container-tools] Atomic Developer Bundle and OpenShift

[Max Rydahl Andersen]

> * a method for docker images to be pre-loaded on to the vagrant boxes: 
> As you probably agree, we would really like the v-up experience of the 
> ADB to be as quick and painless as possible. One of things that will 
> make that possible is to "pre-install" the docker images for 
> OpenShift, AtomicApp, v2c, etc. However, the build tooling (koji) does 
> not allow a build to access the general internet. As a result, "docker 
> pull" is not an option (at least from docker-hub). We have a couple 
> options here:
> * stand up a docker registry in the build environment that the builds 
> can access: While this seems like a good idea, the timeline to make 
> this happen is probably on the order of months not days
> * auto-rpm-ify the docker images: Build the images in koji, use koji 
> to rpm-ify the binary images, pull the rpms as per normal, extract the 
> rpm and inject them in to the docker-images storage. Likely, this is 
> the most viable solution. However, it may run in to problems with 
> docker-registry-v2 (doesn't support import at this time).
> Is anyone owning testing and resolving this issue?

I can say from the Developer Tooling we would probably "pre-pull" a very 
different set of images than you are listing.
i.e. we would be into getting the EAP images pre-seeded.

Thus I would actually suggest that the "base" ADB/CDK don't do this by 
default but maybe just have a preloaded command users or an additional 
installer can run to easily "pre-load" the set they are interested in.

> * OpenShift needs dns to allow a user to access their applications: 
> For OpenShift to give a good user experience, it needs to manage some 
> wildcard domain. In other words, when a user sets up an application, 
> they need to give it a name and they access the application from their 
> host web browser at something like "myCoolApp.myADB.lcl". OpenShift 
> uses host-headers to route the browser to the correct app. However, 
> this means, if OpenShift is running in a VM, the host machine needs to 
> know to route *.myADB.lcl to the VM and then to OpenShift. As the VM 
> will come up on an (likely) unknowable IP, we planned to use 
> vagrant-landrush, a plugin for vagrant that manages a DNS server for 
> this type of use case. Currently, this plugin still has some problems 
> on windows and has never been tested in this exact use case. Is 
> someone working on:
> 1) testing that this setup will actually work with OpenShift (even on 
> mac or linux where, i believe, v-landrush is known to work)
> 2) looking in to the issues on windows?

I don't have confirmation on QE working on this yet but this is 
definitely on our todo list to verify.

Yes, we plan on using land rush since that at least seem to work on 
Linux for the main VM+openshift, but on Mac and Windows I believe it 
will only work for the main VM - it won't work for the dynamically 
created apps by openshift.

I was hoping there would be one on the CDK team that knew enough about 
vagrant to tell if it would be possible to write a vagrant plugin that 
would somehow run in the background and either listen or poll frequently 
if openshift added new routes, and if yes - write back to the main host 
"/etc/host" (diff location on win) file to add them.

Alternatively (and I don't know if this actually possible) I was 
wondering if CDK could host a dns or similar that we could configure 
Windows to use as fallback when it otherwise couldn't resolve the host 
names ?

> * allow for k8s + docker to work independently of OpenShift: In the 
> plans for ADB we wanted to allow a developer to use k8s+docker 
> directly as well as OpenShift. However, this is not quite as easy as 
> it seems as the k8s version on CentOS and the k8s version in OpenShift 
> are not the same. As a result, even if they are installed separately 
> (see installation bullets elsewhere), they need to be listening on 
> different IP bindings to allow them to listen on the same port. Does 
> someone own testing and ensuring the setup of these conflicting 
> services?

This one i'm interested in too - not because I want to actually work 
with k8s + docker raw, but so this is at least kept very separate so 
there is no conflicts.

/max
http://about.me/maxandersen