Open Stack

On 12/04/18 00:58, Wesley Hayutin wrote:
>
>
> On Tue, 10 Apr 2018 at 20:51 Emilien Macchi <emilien at redhat.com 
> <mailto: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.
>     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).
>
>     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.
>
>     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.
>     - 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.
>
>
> This all looks really good Emilien, thanks for sending it out.
> Regarding the update of containers, we would just want to be 100% sure 
> that we can control which yum repositories are in play for the 
> update.  Maybe it will be done by the user prior to running the 
> command, or maybe with some flags to what ever command Steve is 
> working on.

Is it enough to retain the existing container-check 
<https://github.com/imain/container-check> behavior of just mounting in 
the undercloud's /etc/yum.repos.d?

> FYI.. we've noticed in CI that when the base os updates ( not baseos) 
> are included you tend to fail on at least on package download on one 
> of the 50+ containers due to infra/network.  In CI we only enable 
> baseos, dlrn updates and the dependency change [1]
>
It would be interesting to see what speed/reliability change there would 
be if the concurrency of container-check 
<https://github.com/imain/container-check> was disabled and the 
undercloud's /var/cache/yum was mounted in to each container to avoid 
duplicate package download.

> Thanks
>
> [1] 
> https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-containers/templates/overcloud-prep-containers.sh.j2#L104-L109
>
>
>     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://OpenStack-dev-request@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

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