[Container-tools] Atomic Developer Bundle and OpenShift

[Pete Muir]

On 3 November 2015 at 15:23, Max Rydahl Andersen <manderse at redhat.com> wrote:
>
>> * 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.

We = CDK team?

>
> 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
>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools