On 12/04/18 00:58, Wesley Hayutin wrote:


On Tue, 10 Apr 2018 at 20:51 Emilien Macchi <emil...@redhat.com <mailto:emil...@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-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to