Open Stack

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


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando