[openstack-dev] [tripleo] roadmap on containers workflow

Bogdan Dobrelya bdobreli at redhat.com
Thu Apr 12 08:16:18 UTC 2018


On 4/12/18 10:08 AM, Sergii Golovatiuk wrote:
> Hi,
> 
> Thank you very much for brining up this topic.
> 
> On Wed, Apr 11, 2018 at 2:50 AM, Emilien Macchi <emilien at redhat.com> 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.
> 
> I am trying to think as operator and it's very similar to 'openstack
> container' which is swift. So it might be confusing I guess.
> 
>>
>> 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).
> 
> That's very nice initiative.
> 
>> 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.
> 
> I would use external registry in this case. Quay.io might be a good
> choice to have rock solid simplicity. It might not be good for CI as
> requires very strong connectivity but it should be sufficient for
> developers.
> 
>> 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.
> 
> Deploy own registry as part of UC deployment or use external. For
> instance, for production use I would like to have a cluster of 3-5
> registries with HAProxy in front to speed up 1k nodes deployments.

Note that this implies HA undercloud as well. Although, given that HA 
undercloud is goodness indeed, I would *not* invest time into reliable 
container registry deployment architecture for undercloud as we'll have 
it for free, once kubernetes/openshift control plane for openstack 
becomes adopted. There is a very strong notion of build pipelines, 
reliable containers registries et al.

> 
>> - Drive the playbook runtime from tripleoclient to bootstrap the container
>> registry (which of course could be disabled in undercloud.conf).
>> - 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.
>>
>> 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
>>
> 
> 
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the OpenStack-dev mailing list