On Fri, Mar 22, 2019 at 3:36 AM Javier Pena <[email protected]> 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 > > > > 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 <[email protected]> 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 > > >> [email protected] > > >> http://lists.rdoproject.org/mailman/listinfo/dev > > >> > > >> To unsubscribe: [email protected] > > >> > > > _______________________________________________ > > > dev mailing list > > > [email protected] > > > http://lists.rdoproject.org/mailman/listinfo/dev > > > > > > To unsubscribe: [email protected] > > > > _______________________________________________ > > dev mailing list > > [email protected] > > http://lists.rdoproject.org/mailman/listinfo/dev > > > > To unsubscribe: [email protected] > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.rdoproject.org/mailman/listinfo/dev > > To unsubscribe: [email protected] >
_______________________________________________ dev mailing list [email protected] http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: [email protected]
