> On Mar 22, 2019, at 8:46 AM, Wesley Hayutin <whayu...@redhat.com> wrote:
>
>
>
> On Fri, Mar 22, 2019 at 3:36 AM Javier Pena <jp...@redhat.com> wrote:
>
>
> ----- Original Message -----
> > 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.
> >
> > 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.
> >
> > The following link explains in greater detail:
> > https://docs.docker.com/registry/spec/manifest-v2-2/
> >
> > The process boils down to the following steps:
> >
> > 1) Upload an image of the first architecture (ex: image1:x86_64_01012019)
> > 2) Upload an image of the second architecture (ex: image1:ppc64le_01012019)
> > 3) Upload manifest list image of the image (ex: image1:01012019)
> >
>
> This is one of the details where I had my doubts. Currently, the images
> uploaded to the registry use the following naming convention:
>
> tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40
>
>
> Where:
>
> - tripleomaster is associated to the release (we have tripleomaster,
> tripleostein, tripleorocky...)
> - centos is associated to the OS (we have centos and fedora)
> - 42a882962919b867c91a182b83acca6d8004096e_ee467b40 refers to the repository
> in trunk.rdoproject.org used to build the image (commit hash and short distro
> hash)
>
> 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.
>
> Regards,
> Javier
>
> Right.. I'm agreeing w/ you..
>
> I'm recommending the following change
> tripleomaster -> tripleomaster_x86_64
> and add
> tripleomaster_ppc64le
I'm not sure if I'm getting the right information here, but from what I
understand, a namespace is just a separate repo inside the same image registry,
is that right? I'm not sure if manifest list images can be created between
images in different namespaces, but if its possible, that's how things *should*
be done. I'm not advocating for it to be done this way immediately (unless the
changes turn out to be relatively trivial), but it should be the end goal of
making this multiarch aware.
To explain: the suggested change to putting specific architecture images in
their own separate namespaces might not be a problem, assuming a manifest list
image can be set up across namespaces. However, if that's not possible, then
we should append (or prepend) the architecture to the tag, and create the
manifest list image with the original name that has no architecture described.
This would extend existing functionality within the registry itself, and allow
for a seamless transition to the consumers of these images.
The final list of images would be as follows:
x86_64 specific image:
-
tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40_x86_64
ppc64le specific image:
-
tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40_ppc64le
manifest list image:
-
tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40
So the consumer would do "docker pull
tripleomaster/centos-binary-neutron-l3-agent:42a882962919b867c91a182b83acca6d8004096e_ee467b40"
and it would automatically retrieve the appropriate architecture image based
on the host machine's architecture.
*IF* manifest list images can span across namespaces, all you'd have to do is
move those architecture tags to the namespace definition, and you could *still*
use the same manifest list image definition above and it would work the same
way.
-Trevor
>
>
>
> > 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.
> >
> > -Trevor
> >
> > 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.
> >
> > > On Mar 21, 2019, at 12:28 PM, Javier Pena <jp...@redhat.com> wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> Hi all,
> > >>
> > >> Over the last few weeks, mjturek and baha have been busy working on a set
> > >> of
> > >> periodic jobs to build TripleO images for the ppc64le arch [1].
> > >>
> > >> The current missing step is publishing those images, and they are
> > >> proposing
> > >> to push those to the RDO Registry instance at registry.rdoproject.org,
> > >> just
> > >> like we do with our TripleO images. I have tried to understand the
> > >> requirements, and would like to get input on the following topics:
> > >>
> > >> - Which namespace would these images use? Based on some logs [2] it looks
> > >> like they use tripleomaster-ppc64le, will they also push the images to
> > >> that
> > >> namespace?
> >
> > 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.
> >
> > >> - Could this create any conflicts with our current promotion pipeline?
> >
> > This should not cause conflicts in current promotion pipeline, as the
> > process
> > should be an extension to existing functionality.
> >
> > >> - Is registry.rdo the right place for those images? I'm not familiar with
> > >> the
> > >> next steps for ppc64le images after that (will it then go through a
> > >> promotion pipeline?), so that might affect.
> >
> > 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.
> >
> > >>
> > >> If we decide to upload the images to images.rdo, we'll need to do the
> > >
> > > Correction: this should read "registry.rdo"
> > >
> > >> following:
> > >>
> > >> - Create the tripleomaster-ppc64le namespace in registry.rdo, following a
> > >> similar pattern to [3].
> > >> - Schedule a short registry downtime to increase its disk space, since it
> > >> is
> > >> currently near its limit.
> >
> > This is definitely necessary, given the capacity requirement will double,
> > give or take, to support the additional architecture.
> >
> > >> - Update the job at ci.centos to include the REGISTRY_PASSWORD
> > >> environment
> > >> variable with the right token (see [4]). This is missing today, and
> > >> causing
> > >> the job failure.
> > >>
> > >> Once we get input from all interested parties, we will decide on the next
> > >> steps.
> > >>
> > >> Thanks,
> > >> Javier
> > >>
> > >>
> > >> [1] -
> > >> https://ci.centos.org/job/tripleo-upstream-containers-build-master-ppc64le/
> > >> [2] -
> > >> https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master-ppc64le/422/logs/logs/000_FAILED_tripleoclient.log
> > >> [3] - https://review.rdoproject.org/r/19063
> > >> [4] -
> > >> https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/playbooks/tripleo-ci-periodic-base/containers-build.yaml#L12-L20
> > >> _______________________________________________
> > >> dev mailing list
> > >> dev@lists.rdoproject.org
> > >> http://lists.rdoproject.org/mailman/listinfo/dev
> > >>
> > >> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
> > >>
> > > _______________________________________________
> > > dev mailing list
> > > dev@lists.rdoproject.org
> > > http://lists.rdoproject.org/mailman/listinfo/dev
> > >
> > > To unsubscribe: dev-unsubscr...@lists.rdoproject.org
> >
> > _______________________________________________
> > dev mailing list
> > dev@lists.rdoproject.org
> > http://lists.rdoproject.org/mailman/listinfo/dev
> >
> > To unsubscribe: dev-unsubscr...@lists.rdoproject.org
> >
> _______________________________________________
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
_______________________________________________
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscr...@lists.rdoproject.org
