Don't hard code openshift/k8s things in the apb-base

[flaper87]

apb-base assumes the APB will talk to either OpenShift or Kubernetes. It should not attempt to login to the cluster.

Ideally, there should be 2 base APB. The first one is the actual base with the entrypoint script and the second one should add the oc-login.sh call.

[jwmatthews]

@flaper87 please add a little more context

What do you suggest the usage is for the 2 base APB images?
Are you looking to handle differences of K8S vs OCP, or something else?

Thank you,

[flaper87]

@jwmatthews sure, sorry for the lack of context in the description.

There are 2 things, really. The first one is handled differences between k8s and OCP but the one that I'm more interested in is being able to use APBs to provision/deprovision apps on other COEs other than k8s and OCP. I've created a small APB that can be used as an init container on docker to install other apps.

I guess my goal would be to make APB's API not k8s/OCP centric if possible and rather have specific base images for those cases.

apb-base
     |
     | ------- ap-base-k8s
     | ------- ap-base-ocp

Does this make sense?

[rthallisey]

Hey @flaper87. I agree with your proposal. But right now, the broker is not cluster agnostic and it's something we hope to implement. I think the first pass at this will be to broaden support to add Kubernetes as a target. After that, we can consider adding more COEs if folks have a use case for them. Here's an issue in the broker outlining the work required to add Kubernetes support openshift/ansible-service-broker#233.

[jwmatthews]

@flaper87 thank you, that information helps.

[flaper87]

@rthallisey makes sense to me. Do you think we can start by splitting the base image into 2 images? Once the ASB feature is implemented, we can then make the COE image agnostic.

I can help with the former if y'all agree.

[rthallisey]

@flaper87 Sure. Let's start with a discussion on how we want to do this because I think it can be done a few different ways:

• Create dockerfiles for apb-base-k8s & apb-base-oc
• Template the apb-base Dockerfile
• A directory per COE

cc @eriknelson @jmrodri @fabianvf @jmontleon

[eriknelson]

@flaper87 Thanks for your contribution!

Is the suggestion there should be a single agnostic base image, and then individual apbs that are cluster specific, I.E. postgres-apb-k8s, postgres-apb-openshift?

The broker is going to need branches of logic specific to each flavor. To do this right, we need to encapsulate cluster specific logic behind an interface and abstract it away. Call the interface ApbRunner, or something similar. APB's indicate (apb.yml makes sense) what flavor of "ApbRunner" it wants. Scratch thoughts:

// Create appropriate runner for spec
var runner ApbRunner = RunnerFactory.Create(&spec)
runner.ExecuteApb()

Lets us write as many runners as we'd like to support in a runner package, or whatever we end up calling it.

Anyone take issue with having cluster specific apbs aside from the obviously having to manage a bunch of different apbs floating around?

[flaper87]

Is the suggestion there should be a single agnostic base image, and then individual apbs that are cluster specific, I.E. postgres-apb-k8s, postgres-apb-openshift?

Yes. I'm not sure what the best way to implement this is, though. My suggestion was to have 2 base images. The first one creates the user, adds the base entrypoint and a few cluster agnostic operations. On top of that one, we could have a Kubernetes one, an OpenShift one (or one that is generic for both) or simply have an APB created on top of the the generic top image.

Here are some examples:

• This is an APB that talks to either kubernetes or openshift: https://github.com/flaper87/tripleo-apb-roles/tree/master/mariadb-apb
• This is an APB that runs docker containers: https://github.com/flaper87/tripleo-undercloud-init-container

I'd like to be able to build the second APB without any k8s/openshift specific dependencies.

[eriknelson]

My suggestion was to have 2 base images. The first one creates the user, adds the base entrypoint and a few cluster agnostic operations. On top of that one, we could have a Kubernetes one, an OpenShift one (or one that is generic for both) or simply have an APB created on top of the the generic top image.

Sounds reasonable to me. Truthfully, the broker has been designed with the expectation there's some kind of orchestration engine available, not vanilla docker. I don't see a technical reason we can't support this in the broker if we move towards an agnostic runner design.