<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Wes,<br>
</p>
<div class="moz-cite-prefix">On 3/21/19 2:36 PM, Wesley Hayutin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOHJT4Jz_jG6ihmr+hAz3SxDMjiBSAhKAcxQShFd9r796tG-tQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 21, 2019 at
12:20 PM Trevor Vardeman <<a
href="mailto:tvardema@redhat.com" moz-do-not-send="true">tvardema@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"><br>
<br>
> On Mar 21, 2019, at 1:12 PM, Wesley Hayutin <<a
href="mailto:whayutin@redhat.com" target="_blank"
moz-do-not-send="true">whayutin@redhat.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Thu, Mar 21, 2019 at 12:03 PM Trevor Vardeman <<a
href="mailto:tvardema@redhat.com" target="_blank"
moz-do-not-send="true">tvardema@redhat.com</a>> wrote:<br>
> I've been working with mjturek and baha on this a bit.
I've responded inline 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 integrated and uploaded. This can be done
with docker manifest list images.<br>
> <br>
> The following link explains in greater detail: <a
href="https://docs.docker.com/registry/spec/manifest-v2-2/"
rel="noreferrer" target="_blank" moz-do-not-send="true">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>
> I think this is implying we upload x86_64, and PPC
containers to the rdo registry together. We specifically do
NOT want to do that. One set of images should not be
blocked by the other at this stage of the testing.<br>
<br>
That's not quite right, the images can be uploaded
separately, but for the manifest list image to function
properly you'd need both images uploaded. Also, as for the
tagging, I wasn't suggesting a change to how images are
tagged save for potentially modifying it such that the
manifest list image is the default tag, versus the x86_64
image.<br>
</blockquote>
<div><br>
</div>
<div>OK.. thanks Trevor for the explanation. Since you are
executing in ci.centos and not via Zuul I can see how you
are having to readdress a lot of the infrastructure bits
like uploading to the registry.</div>
<div><br>
</div>
<div>If we can get you on the zuul platform you won't have to
rework or redo at least some of that work. In zuul we have
some post playbooks that execute after the build job [1]. I
think you'll be able to find just about everything we do w/
containers here [2] now.</div>
</div>
</div>
</blockquote>
<p>This is non-trivial as we do not have access to power hardware in
RDO CI. The reason we are using ci.centos is because it has access
to cico, which has ppc64le hardware to use.<br>
</p>
<blockquote type="cite"
cite="mid:CAOHJT4Jz_jG6ihmr+hAz3SxDMjiBSAhKAcxQShFd9r796tG-tQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Perhaps you can join the tripleo community sync on
Tuesdays directly after the TripleO upstream community
meeting on #tripleo so we can get you introduced to some
folks who may not have met you yet.</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>[1] <a
href="https://github.com/openstack-infra/tripleo-ci/blob/master/playbooks/tripleo-buildcontainers/tag.yaml"
moz-do-not-send="true">https://github.com/openstack-infra/tripleo-ci/blob/master/playbooks/tripleo-buildcontainers/tag.yaml</a></div>
<div>[2] <a
href="https://github.com/openstack-infra/tripleo-ci/tree/master/playbooks/tripleo-buildcontainers"
moz-do-not-send="true">https://github.com/openstack-infra/tripleo-ci/tree/master/playbooks/tripleo-buildcontainers</a></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
> <br>
> I only just read through the manifest doc, so I may be
misunderstanding something.<br>
> Any container built w/ tripleo should be tagged w/ the
dlrn_hash used while building so if we needed some
containers from x86_64 and some from PPC that should be
relatively simple. <br>
> <br>
> <br>
> Step 3 is essentially just pushing a JSON body that has
descriptors and references to the other two images, such
that when someone does a pull request of the manifest list
image, it will gather the appropriate architecture for that
image based on the host's architecture.<br>
> <br>
> -Trevor<br>
> <br>
> PS. If I've missed something important with the overall
concerns here I apologize, but thought it necessary to spell
out the goal as I understand it.<br>
> <br>
> > On Mar 21, 2019, at 12:28 PM, Javier Pena <<a
href="mailto:jpena@redhat.com" target="_blank"
moz-do-not-send="true">jpena@redhat.com</a>> wrote:<br>
> > <br>
> > <br>
> > ----- Original Message -----<br>
> >> Hi all,<br>
> >> <br>
> >> Over the last few weeks, mjturek and baha have
been busy working on a set of<br>
> >> periodic jobs to build TripleO images for the
ppc64le arch [1].<br>
> >> <br>
> >> The current missing step is publishing those
images, and they are proposing<br>
> >> to push those to the RDO Registry instance at
<a href="http://registry.rdoproject.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">registry.rdoproject.org</a>,
just<br>
> >> like we do with our TripleO images. I have
tried to understand the<br>
> >> requirements, and would like to get input on
the following topics:<br>
> >> <br>
> >> - Which namespace would these images use?
Based on some logs [2] it looks<br>
> >> like they use tripleomaster-ppc64le, will they
also push the images to that<br>
> >> namespace?<br>
> <br>
> I have no experience in namespaces inside of a registry
or how that differentiates images from one another, but the
images should be pushed (in my opinion) to the same location
in which the x86 images reside.<br>
> <br>
> >> - Could this create any conflicts with our
current promotion pipeline?<br>
> <br>
> This should not cause conflicts in current promotion
pipeline, as the process should be an extension to existing
functionality.<br>
> <br>
> >> - Is registry.rdo the right place for those
images? I'm not familiar with the<br>
> >> next steps for ppc64le images after that (will
it then go through a<br>
> >> promotion pipeline?), so that might affect.<br>
> <br>
> If the x86 images exist in registry.rdo, then the
ppc64le (and any other architecture image) should exist
there as well. I can't think of a reason to differentiate
between architectures when the desired result is parity and
support of more architectures.<br>
> <br>
> >> <br>
> >> If we decide to upload the images to
images.rdo, we'll need to do the<br>
> > <br>
> > Correction: this should read "registry.rdo"<br>
> > <br>
> >> following:<br>
> >> <br>
> >> - Create the tripleomaster-ppc64le namespace
in registry.rdo, following a<br>
> >> similar pattern to [3].<br>
> >> - Schedule a short registry downtime to
increase its disk space, since it is<br>
> >> currently near its limit.<br>
> <br>
> This is definitely necessary, given the capacity
requirement will double, give or take, to support the
additional architecture.<br>
> <br>
> >> - Update the job at ci.centos to include the
REGISTRY_PASSWORD environment<br>
> >> variable with the right token (see [4]). This
is missing today, and causing<br>
> >> the job failure.<br>
> >> <br>
> >> Once we get input from all interested parties,
we will decide on the next<br>
> >> steps.<br>
> >> <br>
> >> Thanks,<br>
> >> Javier<br>
> >> <br>
> >> <br>
> >> [1] -<br>
> >> <a
href="https://ci.centos.org/job/tripleo-upstream-containers-build-master-ppc64le/"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://ci.centos.org/job/tripleo-upstream-containers-build-master-ppc64le/</a><br>
> >> [2] -<br>
> >> <a
href="https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master-ppc64le/422/logs/logs/000_FAILED_tripleoclient.log"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master-ppc64le/422/logs/logs/000_FAILED_tripleoclient.log</a><br>
> >> [3] - <a
href="https://review.rdoproject.org/r/19063"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://review.rdoproject.org/r/19063</a><br>
> >> [4] -<br>
> >> <a
href="https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/playbooks/tripleo-ci-periodic-base/containers-build.yaml#L12-L20"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/playbooks/tripleo-ci-periodic-base/containers-build.yaml#L12-L20</a><br>
> >>
_______________________________________________<br>
> >> dev mailing list<br>
> >> <a href="mailto:dev@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev@lists.rdoproject.org</a><br>
> >> <a
href="http://lists.rdoproject.org/mailman/listinfo/dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
> >> <br>
> >> To unsubscribe: <a
href="mailto:dev-unsubscribe@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev-unsubscribe@lists.rdoproject.org</a><br>
> >> <br>
> > _______________________________________________<br>
> > dev mailing list<br>
> > <a href="mailto:dev@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev@lists.rdoproject.org</a><br>
> > <a
href="http://lists.rdoproject.org/mailman/listinfo/dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
> > <br>
> > To unsubscribe: <a
href="mailto:dev-unsubscribe@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev-unsubscribe@lists.rdoproject.org</a><br>
> <br>
> _______________________________________________<br>
> dev mailing list<br>
> <a href="mailto:dev@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev@lists.rdoproject.org</a><br>
> <a
href="http://lists.rdoproject.org/mailman/listinfo/dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
> <br>
> To unsubscribe: <a
href="mailto:dev-unsubscribe@lists.rdoproject.org"
target="_blank" moz-do-not-send="true">dev-unsubscribe@lists.rdoproject.org</a><br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.rdoproject.org">dev@lists.rdoproject.org</a>
<a class="moz-txt-link-freetext" href="http://lists.rdoproject.org/mailman/listinfo/dev">http://lists.rdoproject.org/mailman/listinfo/dev</a>
To unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:dev-unsubscribe@lists.rdoproject.org">dev-unsubscribe@lists.rdoproject.org</a>
</pre>
</blockquote>
</body>
</html>