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.
> 
>> 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.

Please let's do that for tripleoclient and only make quickstart and 
other tools to invoke commands. We should keep being close to what users 
would do, which is only issuing client commands.

> 
>> - 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