<div dir="ltr"><div>rebooting this conversation... see inline at the bottom</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 11:29 AM Javier Pena <<a href="mailto:jpena@redhat.com">jpena@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"times new roman","new york",times,serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="gmail-m_2236700867573043821zwchr"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 22, 2019 at 8:35 PM Javier Pena <<a href="mailto:jpena@redhat.com" target="_blank">jpena@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br> ----- Original Message -----<br> > I've been working with mjturek and baha on this a bit. I've responded inline<br> > below, but also want to clarify on the desired workflow.<br> > <br> > TL;DR: The desired workflow is to have ppc64le and x86_64 seamlessly<br> > integrated and uploaded. This can be done with docker manifest list images.<br> > <br> > The following link explains in greater detail:<br> > <a href="https://docs.docker.com/registry/spec/manifest-v2-2/" rel="noreferrer" target="_blank">https://docs.docker.com/registry/spec/manifest-v2-2/</a><br> > <br> > The process boils down to the following steps:<br> > <br> > 1) Upload an image of the first architecture (ex: image1:x86_64_01012019)<br> > 2) Upload an image of the second architecture (ex: image1:ppc64le_01012019)<br> > 3) Upload manifest list image of the image (ex: image1:01012019)<br> > <br><br> This is one of the details where I had my doubts. Currently, the images uploaded to the registry use the following naming convention:<br><br> tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40<br><br><br> Where:<br><br> - tripleomaster is associated to the release (we have tripleomaster, tripleostein, tripleorocky...)<br> - centos is associated to the OS (we have centos and fedora)<br> - 42a882962919b867c91a182b83acca6d8004096e_ee467b40 refers to the repository in <a href="http://trunk.rdoproject.org" rel="noreferrer" target="_blank">trunk.rdoproject.org</a> used to build the image (commit hash and short distro hash)<br><br> If we want to go multi-arch, we need to change that tag to include the architecture, is this correct? Otherwise, we could have conflicts between the x86_64 and ppc64le pipelines trying to upload the same image.<br></blockquote><div><br></div><div>Yup. The idea is that the enpoint URL (tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40) is a container manifest. Where we include the arch would be with an additional tag:</div><div><br></div><div>tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40_$arch but nothing else should change and *explicitly* do not want different orgs per architecture. So the publish pipeline would look like:<br></div><div><br></div><div><ul><li>Each architecture builds and publishes all the containers per branch and OS [1] all the containers and publishes a container image/layer to:<br>'tripleo%(branch)s/%(os)s-%(build_type)s-%(container)s:%(repo)s_%(arch)s'</li><li>Then checks to see if the manifest exists.<br>manifest = 'tripleo%(branch)s/%(os)s-%(build_type)s-%(container)s:%(repo)s'<br>if exists(manifest):<br> add_to_manifest(arch_layer=tripleo%(branch)s/%(os)s-%(build_type)s-%(container)s:%(repo)s_%(arch)s')<br>else:<br> create_manifest(arch_layer=tripleo%(branch)s/%(os)s-%(build_type)s-%(container)s:%(repo)s_%(arch)s')</li></ul></div></div></div></div></div></div></blockquote><div>I have been running some tests to check how this could work, and I've found an issue. It looks like the OpenShift Registry (what we use for our RDO Registry) does not properly support manifest lists, see [2]. It actually failed for me when I tried it, while a plain Docker registry worked (using manifest-tool).<br></div><div><br></div><div>Would the manifest upload be required in the RDO Registry (which is used as an intermediate step), or just in DockerHub (which is used for actual content delivery)? If it's the second case, we're still fine.<br></div><div><br></div><div>Regards,<br></div><div>Javier<br></div><div><br></div><div>[2] - <a href="https://trello.com/c/4EcAIJrd/1303-5-quayregistry-add-support-for-manifest-list-rd" target="_blank">https://trello.com/c/4EcAIJrd/1303-5-quayregistry-add-support-for-manifest-list-rd</a><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div>This shouldn't break existing consumers as docker and podman both do the correct thing when encountering a manifest. and does mean that multi-arch consumers can use the same URL scheme. This is how downstream currently works</div></div><div><br></div><div>It's possible and possibly even desirable, due to resource constraints, for the ppc64le build to be triggered only when updating current-passed-ci. That's exactly what we discussed in Dublin.</div><div><br></div><div>Tony.</div><div><br></div><div>[1] for ppc64le we're starting with centos and master but over time this would need to grow out from master to include stein, u etc etc We haven't looked at Fedora due to using centos CI but if Fedora is going to stick around we can work on that too.<br></div></div></div></div></div></div></blockquote><div><br></div></div></div>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproject.org</a></blockquote><div><br></div><div><br></div><div>OK... so here we are.</div><div>Trevor, myself and Steve hashed out a PPC64LE workflow that works alongside the x86_64 workflow. </div><div>Our notes are here [1] .</div><div><br></div><div>Although x86_64 and PPC64LE should try their best to use the same container build methods and process the workflows are completely independent and can remain that way. The convergence occurs on the tripleo-ci promotion server after reading test results from the dlrn_api ( notes in the etherpad )</div><div><br></div><div>Some additional points.</div><div>* Alan Pevec and I both agree getting the PPC hooked into a zuul workflow would benefit everyone</div><div><br></div><div>OK... comment away and feel free to comment / update the etherpad.</div><div><br></div><div><br></div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/x86_ppc_tripleo_container_promotion">https://etherpad.openstack.org/p/x86_ppc_tripleo_container_promotion</a></div><div><br></div><div> </div></div></div>