<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 11/04/18 12:50, Emilien Macchi
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>Greetings,</div>
        <div><br>
        </div>
        <div>Steve Baker and I had a quick chat today about the work
          that is being done around containers workflow in Rocky cycle.</div>
        <div><br>
        </div>
        <div>If you're not familiar with the topic, I suggest to first
          read the blueprint to understand the context here:</div>
        <div><a
href="https://blueprints.launchpad.net/tripleo/+spec/container-prepare-workflow"
            moz-do-not-send="true">https://blueprints.launchpad.net/tripleo/+spec/container-prepare-workflow</a></div>
        <div><br>
        </div>
        <div>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.</div>
        <div> </div>
        <div>But today our discussion extended on 2 uses-cases that
          we're going to explore and find how we can address them:</div>
        <div>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]).</div>
        <div>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).</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>Both cases would require additional things:</div>
        <div>- The container registry needs to be deployed *before*
          actually installing the undercloud.</div>
        <div>- 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.</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Either that or we do no image filtering and just process every image
    regardless of whether it will be used.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>Next steps:</div>
        <div>- Agree that we need to deploy the container-registry
          before the undercloud.</div>
        <div>- 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.</div>
      </div>
    </blockquote>
    +1<br>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>- Drive the playbook runtime from tripleoclient to
          bootstrap the container registry (which of course could be
          disabled in undercloud.conf).</div>
      </div>
    </blockquote>
    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.<br>
    <br>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>- 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.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Since the use cases are all upstream CI/dev I do wonder if we should
    just have a dedicated <a
      href="https://github.com/imain/container-check">container-check</a>
    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.<br>
    <br>
    Alternatively it could still be a standalone role which quickstart
    invokes, just to accommodate development workflows which don't use
    quickstart.<br>
    <br>
    <blockquote type="cite"
cite="mid:CACu=hyvdgf8o6DRLL9LfitfZLwCXahdE10Hx4wwSj_atfUEdXg@mail.gmail.com">
      <div dir="ltr">
        <div>Feedback is welcome, thanks.</div>
        <div><br>
        </div>
        <div>[1] All-In-One thread: <a
href="http://lists.openstack.org/pipermail/openstack-dev/2018-March/128900.html"
            moz-do-not-send="true">http://lists.openstack.org/pipermail/openstack-dev/2018-March/128900.html</a><br>
        </div>
        <div>[2] Bug report when undercloud is containeirzed <a
            href="https://bugs.launchpad.net/tripleo/+bug/1762422"
            moz-do-not-send="true">https://bugs.launchpad.net/tripleo/+bug/1762422</a></div>
        <div>[3] Tool to update containers if needed: <a
            href="https://github.com/imain/container-check"
            moz-do-not-send="true">https://github.com/imain/container-check</a></div>
        <div>[4] Container-check running in TripleO CI: <a
            href="https://review.openstack.org/#/c/558885/"
            moz-do-not-send="true">https://review.openstack.org/#/c/558885/</a>
          and <a href="https://review.openstack.org/#/c/529399/"
            moz-do-not-send="true">https://review.openstack.org/#/c/529399/</a></div>
        -- <br>
        <div class="gmail_signature">
          <div dir="ltr">Emilien Macchi<br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>