Open Stack

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.

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180412/264b8bac/attachment.html>