On 4/12/18 12:38 AM, Steve Baker wrote:
On 11/04/18 12:50, Emilien Macchi wrote:
Greetings,
Steve Baker and I had a quick chat today about the work that is being
done around containers workflow in Rocky cycle.
If you're not familiar with the topic, I suggest to first read the
blueprint to understand the context here:
https://blueprints.launchpad.net/tripleo/+spec/container-prepare-workflow
One of the great outcomes of this blueprint is that in Rocky, the
operator won't have to run all the "openstack overcloud container"
commands to prepare the container registry and upload the containers.
Indeed, it'll be driven by Heat and Mistral mostly.
But today our discussion extended on 2 uses-cases that we're going to
explore and find how we can address them:
1) I'm a developer and want to deploy a containerized undercloud with
customized containers (more or less related to the all-in-one
discussions on another thread [1]).
2) I'm submitting a patch in tripleo-common (let's say a workflow) and
need my patch to be tested when the undercloud is containerized (see
[2] for an excellent example).
I'm fairly sure the only use cases for this will be developer or CI
based. I think we need to be strongly encouraging image modifications
for production deployments to go through some kind of image building
pipeline. See Next Steps below for the implications of this.
Yes, this. I would love to see container-check tool improving CI and dev
experience and would not happy to see it as a blessed part of the
product architecture. Containers should be immutable and nothing should
be mutated runtime, like updating packages et al.
Both cases would require additional things:
- The container registry needs to be deployed *before* actually
installing the undercloud.
- We need a tool to update containers from this registry and *before*
deploying them. We already have this tool in place in our CI for the
overcloud (see [3] and [4]). Now we need a similar thing for the
undercloud.
One problem I see is that we use roles and environment files to filter
the images to be pulled/modified/uploaded. Now we would need to assemble
a list of undercloud *and* overcloud environments, and build some kind
of aggregate role data for both. This would need to happen before the
undercloud is even deployed, which is quite a different order from what
quickstart does currently.
Either that or we do no image filtering and just process every image
regardless of whether it will be used.
Next steps:
- Agree that we need to deploy the container-registry before the
undercloud.
- If agreed, we'll create a new Ansible role called
ansible-role-container-registry that for now will deploy exactly what
we have in TripleO, without extra feature.
+1
- Drive the playbook runtime from tripleoclient to bootstrap the
container registry (which of course could be disabled in undercloud.conf).
tripleoclient could switch to using this role instead of puppet-tripleo
to install the registry, however since the only use-cases we have are
dev/CI driven I wonder if quickstart/infrared can just invoke the role
when required, before tripleoclient is involved.
- Create another Ansible role that would re-use container-check tool
but the idea is to provide a role to modify containers when needed,
and we could also control it from tripleoclient. The role would be
using the ContainerImagePrepare parameter, which Steve is working on
right now.
Since the use cases are all upstream CI/dev I do wonder if we should
just have a dedicated container-check
<https://github.com/imain/container-check> role inside
tripleo-quickstart-extras which can continue to use the script[3] or
whatever. Keeping the logic in quickstart will remove the temptation to
use it instead of a proper image build pipeline for production deployments.
Alternatively it could still be a standalone role which quickstart
invokes, just to accommodate development workflows which don't use
quickstart.
Feedback is welcome, thanks.
[1] All-In-One thread:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128900.html
[2] Bug report when undercloud is containeirzed
https://bugs.launchpad.net/tripleo/+bug/1762422
[3] Tool to update containers if needed:
https://github.com/imain/container-check
[4] Container-check running in TripleO CI:
https://review.openstack.org/#/c/558885/ and
https://review.openstack.org/#/c/529399/
--
Emilien Macchi
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
