Revisit 'apb-base/Dockerfile-src'

[jwmatthews]

Is there value in keeping this around?
If there is let's document what the file is used for to avoid confusion.

[jmontleon]

The -src Dockerfiles are installing various libraries from source rather than from RPM.

I think @fabianvf has used it from time to time to test updates. We're going to end up with the same thing in ansible-service-broker.

To compound source/rpm binary install differences what I'm seeing is downstream also bares very little resemblence to upstream. The FROM line is different, Openshift package names change (e.g. origin-clients vs. atomic-openshift-clients) and we're not supposed to do yum updates downstream because we can pick up unreleased packages so yum commands bare little resemblance, the encoded data is different because the project and repository names differ, etc. etc. It's just plain ugly all around.

There's a not a great way to template Dockerfiles within docker itself. though there are some tools we may want to look into, though with three significantly different versions I'm not sure how readable anything will be by the time we're done templating it. Not to mention encoded data would need to be included for upstream and downstream so the apb.yml would have to be processed twice any time anything is changed if we try to take that approach.

[jwmatthews]

From what I remember, Dockerfile-src was used to get the pre-released k8s/ocp modules for Ansible in a running container. At that time we decided to run ansible from a git checkout along with the modules. I'm not sure this is the direction we want to go for a developer workflow to build apb-base from source in a container....

[rthallisey]

Do we want a source image for all these apb-examples? What would we gain from it?

[fabianvf]

Confusingly we now have two Dockerfile-srcs. We have one in apb-base which installs the ansible modules from source, which I think we can and should remove since getting the role is working great. The other is in the actual apbs and they are for building using the playbook/role directories in the project rather than RPM. @rthallisey what we gain from that is the ability to test code without having to rebuild the RPM every time.