Hello Mark, Manifest allows pulling the right image according to ARCH (arm64/amd64). Please see the dump of ollivier/functest-core:latest attached to this mail. Here I would like to avoid variables in FROM (by default) mainly to ensure a better compatibility with all toolings and to ease maintenance.
If arm64 images are built on an arm64 PODs, the same Dockerfiles can be shared between these archs for: (all could refer to opnfv/functest-core:latest as parent) - functest-healthcheck - functest-smoke - functest-features - functest-components - ... But it cannot work in case of cross-building as host and target host differ. Then we must precise opnfv/functest-core:arm64-latest in this case. Cédric 2017-10-16 7:04 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>: > Cédric, > > I am curious, how does the manifest help with avoiding FROM? Is it that we > would use that to pull the correct base Alpine image? > > Regards, > Mark > > Mark Beierl > SW System Sr Principal Engineer > Dell EMC | Office of the CTO > mobile +1 613 314 8106 > mark.bei...@dell.com > > On Oct 15, 2017, at 23:55, "cedric.olliv...@orange.com" > <cedric.olliv...@orange.com> wrote: > > Alex, > > Yes. You know I was waiting for tests from your side. As manifest works as > expected, we can remove most of them. > > But I will keep the one to build/publish containers in any repo as it's very > useful. > > My sentence was focused on Functest. > > Cédric > > ---- Alexandru Avadanii a écrit ---- > > Hi, > >> -----Original Message----- >> From: Cedric OLLIVIER [mailto:ollivier.ced...@gmail.com] >> Sent: Sunday, October 15, 2017 8:27 PM >> To: Alec Hothan (ahothan) >> Cc: Alexandru Avadanii; Fatih Degirmenci; cedric.olliv...@orange.com; >> opnfv- >> tech-discuss; Delia Popescu; David McBride; morgan.richo...@orange.com >> Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch >> >> Hello Alec, >> >> Please find several answers inline. >> >> Cédric >> >> 2017-10-14 20:55 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>: >> > >> > >> > Alex: this looks like a good plan and seems to take care of all >> > functest requirements wrt build. >> > >> >> [Cédric] >> Absolutly not as the second point is false from our point of view. >> We prefer Docker manifests to useless variables in FROM instructions what >> would break the current builds. >> I will translate my travis-ci jobs to releng jjobs after E is published. > > [Alex] > For the record, the cost of dismissing FROM ARG is duplicating the > Dockerfile (either with a patch, or with a series of runtime sed, e.g. [1] > vs [2]). > Also, Storperf requires the latest Docker, and has no issues on the current > OPNFV builders, so those are already up to date. > I'm not saying FROM ARG should be enforced, but if some projects want to use > it, they should be allowed to, instead of juggling with FROM using sed or > patches. > > BR, > Alex > > [1] https://gerrit.opnfv.org/gerrit/#/c/44999/1/build.sh > [2] > https://github.com/opnfv/storperf/blob/master/docker/storperf-graphite/Dockerfile#L17-L19 > >> >> > >> > >> > What we need to nail down next is the versioning and how it plays out >> > with Functest CI, Functest XCI and lastly to the release. >> > >> > >> > >> > It is critical to nail down the versioning and branching model first >> > before rushing to modify the releng tools/scripts. The current >> > versioning and branching model is insufficient (as a proof see what >> > functest is doing to overcome the limitations). We need direction and >> > the XCI project is the right place to determine the overall versioning >> > model for all OPNFV projects. >> > >> > >> >> > >> > Cedric: your wiki on releng requirements is a good start. It will be >> > great if it could also have the following information: >> >> [Cédric] >> >> I think it's quite clear how Functest must be improved to implement a real >> Functest Functional gating via XCI. >> I believe releng could have been updated as soon as Functest started >> splitting >> the containers. We have developped build.sh as initially proposed. >> For your information, the wiki page is hugely completed by my previous >> email >> and the travis-ci jobs already published (and running in my private repo): >> https://git.opnfv.org/functest/tree/.travis.yml?h=stable/euphrates >> https://travis-ci.org/collivier/functest/builds/287849046 >> https://travis-ci.org/collivier/functest/builds/287745681 >> >> > >> > Functest CI: what is gating every functest commit? (this is normally >> > the script that gates every gerrit commit on functest master) Functest >> > XCI: how is a new version of Functest gated for XCI use Functest >> > release: how is the right version of Functest picked for release (I >> > think I know how this works based on emails with you/Morgan, but it is >> > good to put this down) >> > >> > >> >> [Cédric] >> It's triggered as soon as a change is merged on github. >> Could you please have a look to the next wiki page which lists the first >> steps to >> implement a real Functional gating. >> Technically speaking, the main difficulties have been done for E release >> (Docker slicing, requirements management...). >> https://wiki.opnfv.org/display/functest/Functional+testing+gating >> >> Of course we require releng jjobs to manage gerrit patchset. It has been >> clear >> for a while. >> I agreed to work on it to go further even. >> >> > >> > If we look at the git tags and the container tags: >> > >> > From a quick look at the git repo, Functest currently only uses the >> > release git tags as imposed by the release (the “danube.1.0.0” and now >> > “opnfv-5.0.0”). So we can say that functest does not have any project >> > specific versioning per se. >> > >> > However it is unclear if the container images built off these git tags >> > are really used because Morgan indicated that functestI almost always >> > recommends the use the following container tags: >> > >> > “latest” which is built from tip of master “euphrates” which is always >> > built off the tip of the functest stable/euphrates branch “stable” >> > which seems to be same as “euphrates >> > >> > Now one would question then what is the real need to have an official >> > release tagged image then? >> > >> > I understand this is done because functest cannot run at the same pace >> > as the release (too slow) and needs additional builds after the release >> > date. >> > Normally this should be done using patch versions: “opnfv-5.0.1”, etc… >> > so using “euphrates” is a bit of a shortcut. The main issue with >> > “euphrates” is the same as “latest” or “stable”: you cannot know for >> > sure which commit was used to build the container (since there will be >> > multiple images with same tag built off different commits). >> > >> >> [Cédric] >> I dont' understand why we require major (5), minor (0) and patch (0) >> numbers. >> Accordig to classical SONAME rules, OPNFV only releases majors and >> patches. I >> would have selected X.Y. >> >> > Now that might not be an issue for the functest team if they do not >> > need a precise tracking of every image used by folks around the world. >> > But it can be a problem for XCI and can cause troubles (e.g. does a >> > given container image “stable” used by customer X have bug fix Y?). >> > >> > >> > >> > The functest case is a bit more complex than the normal project case >> > because functest is actually a set of interdependent containers built >> > off multiple project repos: functest, barometer, sfc, promise… This >> > results in the following artifacts (that is the complete list I got from >> dockerhub): >> > >> > functest-core >> > functest-smoke >> > functest-vnf >> > functest-healthcheck >> > functest-features >> > functest-parser >> > functest-components >> > functest-restapi >> > >> > I am still missing the link between all these artifacts and the >> > dependent project repos, for example where is the barometer code >> > running (there is no functest-barometer)? Is it in functest-core? It >> > would be helpful to document the exact dependency of every artifact. >> > >> > From what I see, external projects included in functest dockerifles >> > are included properly (i.e. the code is pulled in the build using an >> > explicit git hash or a version git tag) but OPNFV projects only use >> > tip of branch (tip of master or top of stable branch). Example fir the >> > functest-smoke >> > dockerfile: >> > >> > >> > >> > ARG FDS_TAG=master >> > >> > >> > >> > git clone --depth 1 -b $FDS_TAG >> > https://gerrit.opnfv.org/gerrit/fds >> > /src/fds && \ >> > >> > >> > >> > This is generally not recommended given the tip of master is not >> > always what the fds team would want functest to use for smoke test >> > (and the fds team has no idea on when functest-smoke is built). Note >> > this is not the fault of functest, the reason is that fds does not >> > version its code on master – and given that very few projects version >> > their code at all, the problem is widespread. >> > >> > >> >> [Cédric] >> Could you please have a look to the stable branch instead? You're reading >> the >> master Dockerfiles. >> Here you are also mixing Project (FDS) and OPNFV gatings. We will publish >> a >> kind of Functest Docker Framework to help creating a docker per project >> based >> on Functest-core. >> But functest-features always makes sense to qualify the release. Then in >> this >> case we should clone stable branches for building the containers, >> shouldn't we? >> >> > >> > We also need to review the versioning of all these artifacts, all >> > contributing OPNFV projects, how they are deployed … And you start to >> > see why tagging all these images with “stable” can become hard to handle >> e.g. >> > what version of functest-core:stable (or which commit on the stable >> > branch) was used to build a given version of functest-parser:stable). >> > >> > >> > >> > I think once we have a better understanding of the above questions >> > (CI/XCI/release) we can come up with a versioning and branching model >> > that satisfies the functest need for generating more frequently >> > artifacts and satisfies the need for XCI and release (to track >> > precisely versions of artifacts to use). >> > >> > >> > >> > And to answer to Cedric’s question on how do other projects like >> > openstack do, it is pretty simple, they all version their project code >> > (i.e they put git tags to mark versions using semver syntax) and their >> > version is independent of the release version ;-) That is the >> > fundamental and necessary condition to do proper versioning. >> > >> > >> > >> > Thanks >> > >> > >> > >> > Alec >> > >> > >> > >> > >> > >> > From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of >> > Alexandru Avadanii <alexandru.avada...@enea.com> >> > Date: Saturday, October 14, 2017 at 8:30 AM >> > To: Cedric OLLIVIER <ollivier.ced...@gmail.com>, Fatih Degirmenci >> > <fde...@gmail.com> >> > Cc: "cedric.olliv...@orange.com" <cedric.olliv...@orange.com>, >> > opnfv-tech-discuss <opnfv-tech-discuss@lists.opnfv.org>, Delia Popescu >> > <delia.pope...@enea.com> >> > >> > >> > Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch >> > >> > >> > >> > Hi, >> > >> > I confirm that the current releng scripts don't support current >> > functest requirements, but that is within our reach. >> > >> > Afaik, we are looking at 2 main issues: >> > >> > 1. functest-core needs to be built first - we can solve this by using >> > multijobs, with an initial step of building functest-core (amd64 & >> > arm64 in parallel), then all other builds in parallel; >> > >> > 2. functest Docker requires support for ARG in FROM - we can solve >> > this by upgrading Docker to a newer version on all amd64 builders >> > (arm64 already has a new enough version); >> > >> > >> > >> > We (armband) offered to take care of #1. Delia can implement the JJB >> > changes next week, we estimate it will take 2-3 days. >> > >> > For #2, we need lab admins with access to the amd64 builder machines >> > to do a simple package upgrade. >> > >> > As part of #2, we might need to install a new package (Docker >> > manifest-tool) too. >> > >> > >> > >> > Imo, we can adapt releng scripts without too much trouble, and we >> > (Armband) are willing to take care of the scripts, if you all agree. >> > >> > >> > >> > As for parallel building (not only amd64 and arm64, but all other >> > containers aside from functest-core) - this will be solved by the >> > design we proposed in #1. >> > >> > There is no need for qemu-user-static and binfmt-misc in OPNFV, as we >> > provide an arm64 native builder (arm-build4). This was required for >> > Travis CI, since they don't have native arm64 builders. >> > >> > >> > >> > BR, >> > >> > Alex >> > >> > >> > >> > >> > >> > -----Original Message----- >> > >> > From: opnfv-tech-discuss-boun...@lists.opnfv.org >> > [mailto:opnfv-tech-discuss- >> > >> > boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER >> > >> > Sent: Saturday, October 14, 2017 2:22 PM >> > >> > To: Fatih Degirmenci >> > >> > Cc: cedric.olliv...@orange.com; Delia Popescu; opnfv-tech-discuss >> > >> > Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch >> > >> > Hello Fatih, >> > >> > My previous mail aims at listing our requirements and again I am >> > convinced >> > >> > that we should select releng instead of external tools for a better >> > control. >> > >> > The travis-ci links illustrate exactly our needs and could help >> > synchronizing >> > >> > Functest and Releng. >> > >> > Here are the related config files: >> > >> > - https://git.opnfv.org/functest/tree/.travis.yml >> > >> > - >> > https://git.opnfv.org/functest/tree/.travis.yml?h=stable%2Feuphrates >> > >> > I had to setup external tools to beta test and share my Alpine >> > containers during >> > >> > the development cycle. >> > >> > The issue was induced by the fact they were copied for OPNFV >> > repositories (I >> > >> > precise during my holidays) instead of updating Releng. >> > >> > I have only fixed the Docker automated builds and complete them to >> > build the >> > >> > remaining containers. >> > >> > I could have forced the sync even if I'm not in charge of that as >> > Functest core >> > >> > dev. >> > >> > But I strongly think it's fine to compare travis-ci and today's releng >> > jjobs simply >> > >> > to impove our CI/CD. >> > >> > Regarding tags, I fully agree that we have taken several quick >> > decisions without >> > >> > analysing what OpenStack, Docker or GNU/Linux distributions do. >> > >> > Bottom up feedbacks may have helped. >> > >> > Cédric >> > >> > 2017-10-14 12:42 GMT+02:00 Fatih Degirmenci <fde...@gmail.com>: >> > >> >> Hi Cedric, >> > >> >> >> > >> >> I see lots of conversations around how to build stuff, test them, >> >> apply tags but >> > >> > it is very hard to follow things. Things are going too fast and with >> > little >> > >> > explanation. Each and every new thing coming up will make it harder >> > for us to >> > >> > understand what you need. >> > >> >> >> > >> >> Also the builds first pushed to docker hub then travis ci now. I am >> >> not sure >> > >> > about this either. I suppose you will try all the external ci services >> > instead of >> > >> > telling us what you need clearly... >> > >> >> >> > >> >> So, before I say if something is possible or not, you need to come up >> >> with >> > >> > clear requirements. We can then fix whatever you need together with you. >> > >> >> >> > >> >> /Fatih >> > >> >> >> > >> >> On 14 Oct 2017, at 12:32, Cedric OLLIVIER <ollivier.ced...@gmail.com> >> > >> > wrote: >> > >> >> >> > >> >> Hello, >> > >> >> >> > >> >> We simply require concurrent jobs properties which can be simplified >> > >> >> here as parallel builds, concurrency control and dependency. >> > >> >> They are mainly required as: >> > >> >> - functest-core must be built before other Functest containers >> > >> >> - other containers should be built in parallel as soon as >> > >> >> functest-core is published >> > >> >> - amd64 containers and arm64 containers should be built in parallel >> > >> >> >> > >> >> I am not directly involved in Releng and I have read in reviews or >> > >> >> mails that today's jjobs don't support that. >> > >> >> All proposals to build Alpine containers haven't conformed with the >> > >> >> concurrency control and the dependencies. >> > >> >> @Fatih could you please confirm that? I'm quite sure that Jenkins >> >> supports >> > >> > them. >> > >> >> >> > >> >> In case of cross building arm64 images on amd64 PODs, we also require >> > >> >> several operations on PODs: >> > >> >> - to install qemu-user-static >> > >> >> - to support binfmt-misc [1] >> > >> >> >> > >> >> The current Docker Automated builds had been fine before we were >> >> asked >> > >> >> to build Alpine arm64 images and to publish stable tags: >> > >> >> - arm64 images can't be built via this CI tool as it requires >> > >> >> qemu-user-static and binfmt_misc [1] support on Docker hosts. >> > >> >> - publishing stable tags triggers useless builds simply because they >> > >> >> are already triggered by euphrates tags. >> > >> >> >> > >> >> I'm currently beta testing travis-ci to meet all requirements: >> > >> >> - https://travis-ci.org/collivier/functest/builds/287849046 >> > >> >> (stable/euphrates) >> > >> >> - https://travis-ci.org/collivier/functest/builds/287745681 (master) >> > >> >> >> > >> >> It works very well and all scripts are ran in parallel for all steps: >> > >> >> - build functest-core images >> > >> >> - publish functest-core manifests >> > >> >> - build all functest images >> > >> >> - publish all manifests >> > >> >> >> > >> >> I am considering we do switch from Docker Automated builds to >> > >> >> travis-ci for official Functest images if releng jjobs are not >> > >> >> updated. >> > >> >> But I think it's too late regarding the deadline for E as we should >> > >> >> multiply CI runs. @David, do you agree? >> > >> >> (Of course I am not allowed to configure travis-ci for OPNFV github >> > >> >> repositories). >> > >> >> >> > >> >> I will deeply update the wiki page "Docker Requirements on Releng" >> >> [2] >> > >> >> >> > >> >> [1] >> >> https://www.kernel.org/doc/html/v4.11/admin-guide/binfmt-misc.html >> > >> >> [2] >> > >> >> https://wiki.opnfv.org/display/functest/Docker+Requirements+on+Releng >> > >> >> >> > >> >> Cédric >> > >> >> >> > >> >> 2017-10-11 9:56 GMT+02:00 Jose Lausuch <jalaus...@suse.com>: >> > >> >>> Maybe late for 5.0, but not late for Euphrates 5.1. >> > >> >>> >> > >> >>> Can we collect a list the requirements we need from Releng in this >> >>> wiki [1]? >> > >> >>> It will facilitate the support and I will help to speed it up. >> > >> >>> Otherwise, nothing will happen as people don’t know what we need. >> > >> >>> >> > >> >>> [1] >> > >> >>> https://wiki.opnfv.org/display/functest/Docker+Requirements+on+Relen >> >>> g >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> On 11 Oct 2017, at 09:42, Cristina Pauna <cristina.pa...@enea.com> >> > >> > wrote: >> > >> >>> >> > >> >>> Hi Cedric, >> > >> >>> >> > >> >>> Which E are you refering to in this email? The one with deadline on >> > >> >>> 15th December? >> > >> >>> >> > >> >>> Cristina >> > >> >>> >> > >> >>> From: cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com] >> > >> >>> Sent: Wednesday, October 11, 2017 7:24 AM >> > >> >>> To: RICHOMME Morgan IMT/OLN <morgan.richo...@orange.com>; >> > >> >>> jalaus...@suse.com; Delia Popescu <delia.pope...@enea.com>; >> >>> Alexandru >> > >> >>> Avadanii <alexandru.avada...@enea.com>; Cristina Pauna >> > >> >>> <cristina.pa...@enea.com>; wangwu...@huawei.com >> > >> >>> Cc: opnfv-tech-discuss <opnfv-tech-discuss@lists.opnfv.org> >> > >> >>> Subject: Re: [functest] Alpine for arch >> > >> >>> >> > >> >>> >> > >> >>> Hello, >> > >> >>> >> > >> >>> I quickly tested to build aarch64 Functest images via Docker >> > >> >>> automated builds what is impossible (several prerequisites are >> > >> >>> unmet). I precise the first published images were built locally. >> > >> >>> >> > >> >>> I'm thinking about an alternative way which will be too much >> > >> >>> disruptive for E release. Again it will be suitable for my own >> > >> >>> repositories. But releng should have been the target to build all >> > >> >>> Docker images (I bet it won't be ready for E). Today's releng can't >> >>> meet >> > >> > functest prerequisites about Docker. >> > >> >>> >> > >> >>> I will inform as soon as my own repositories are ready. >> > >> >>> >> > >> >>> Cédric >> > >> >>> >> > >> >>> ---- Cristina Pauna a écrit ---- >> > >> >>> >> > >> >>> Hi, >> > >> >>> >> > >> >>> There has been a lot of confusion and changes around this topic and >> >>> I >> > >> >>> want to clear things up going forward, so we do not waste any of our >> >>> time. >> > >> >>> What I understand from all the disparate discussions around this >> >>> topic >> >>> is: >> > >> >>> 1. We will not do alpine for E0 release on arm, we are targeting >> >>> E1/E2 >> > >> >>> 2. For the Functest-core image we will have 1 Dockerfile for >> >>> x86, >> >>> and >> > >> >>> a patch for arm that overrides this Dockerfile; from this file we >> > >> >>> will create one Functest-core image and thearchitecture will be >> > >> >>> mentioned in its tag >> > >> >>> 3. The subsequent images (Functest-healthcheck, Functest-smoke, >> >>> etc) >> > >> >>> will be based on the previously built Functest-core image. We will >> >>> do >> > >> >>> a manifest to choose the correct Functest-core image based on its >> > >> >>> tag. These dependent images will also have its arch in the tag. >> > >> >>> 4. The problem we are facing now is how to make sure that for 1 >> >>> build, >> > >> >>> the Functest-core image always get built before the other ones. For >> > >> >>> x86 that is now done with a workaround directly in dockerhub. The >> > >> >>> target is to do it with Jenkins jobs builders, considering image >> >>> dependencies. >> > >> >>> >> > >> >>> Is this the approach we are all agreeing on? >> > >> >>> >> > >> >>> Thanks, >> > >> >>> Cristina >> > >> >>> >> > >> >>> >> > >> > >> ________________________________________________________________ >> > >> > _____ >> > >> >>> ____________________________________________________ >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> Ce message et ses pieces jointes peuvent contenir des informations >> > >> >>> confidentielles ou privilegiees et ne doivent donc >> > >> >>> >> > >> >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> > >> >>> avez recu ce message par erreur, veuillez le signaler >> > >> >>> >> > >> >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> > >> >>> messages electroniques etant susceptibles d'alteration, >> > >> >>> >> > >> >>> Orange decline toute responsabilite si ce message a ete altere, >> > >> >>> deforme ou falsifie. Merci. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> This message and its attachments may contain confidential or >> > >> >>> privileged information that may be protected by law; >> > >> >>> >> > >> >>> they should not be distributed, used or copied without authorisation. >> > >> >>> >> > >> >>> If you have received this email in error, please notify the sender >> > >> >>> and delete this message and its attachments. >> > >> >>> >> > >> >>> As emails may be altered, Orange is not liable for messages that >> >>> have >> > >> >>> been modified, changed or falsified. >> > >> >>> >> > >> >>> Thank you. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> _______________________________________________ >> > >> >>> opnfv-tech-discuss mailing list >> > >> >>> opnfv-tech-discuss@lists.opnfv.org >> > >> >>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> > >> >>> >> > >> >> _______________________________________________ >> > >> >> opnfv-tech-discuss mailing list >> > >> >> opnfv-tech-discuss@lists.opnfv.org >> > >> >> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> > >> > _______________________________________________ >> > >> > opnfv-tech-discuss mailing list >> > >> > opnfv-tech-discuss@lists.opnfv.org >> > >> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> > >> > _______________________________________________ >> > >> > opnfv-tech-discuss mailing list >> > >> > opnfv-tech-discuss@lists.opnfv.org >> > >> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> > >> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > opnfv-tech-discuss mailing list > opnfv-tech-discuss@lists.opnfv.org > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
Name: ollivier/functest-core:latest (Type: application/vnd.docker.distribution.manifest.list.v2+json) Digest: sha256:a11a7832a3cbd36d24111d356593e76cc393c8280f5bb4bca1dd1e9e3255be29 * Contains 2 manifest references: 1 Mfst Type: application/vnd.docker.distribution.manifest.v2+json 1 Digest: sha256:c2ccac6ceeaac8c1e4f918df27c9026638e6dc4291c43cbe008875438814a0ff 1 Mfst Length: 741 1 Platform: 1 - OS: linux 1 - OS Vers: 1 - OS Feat: [] 1 - Arch: amd64 1 - Variant: 1 - Feature: 1 # Layers: 2 layer 1: digest = sha256:88286f41530e93dffd4b964e1db22ce4939fffa4a4c665dab8591fbab03d4926 layer 2: digest = sha256:e4989989496e2baf22cce2351711f00fe9bc9e12ec7286fd1a59280a9caf4395 2 Mfst Type: application/vnd.docker.distribution.manifest.v2+json 2 Digest: sha256:547fcafbe8818cda606972a4079cd3364a8d930d4c57ccb90b2ff5e40266341f 2 Mfst Length: 952 2 Platform: 2 - OS: linux 2 - OS Vers: 2 - OS Feat: [] 2 - Arch: arm64 2 - Variant: 2 - Feature: 2 # Layers: 3 layer 1: digest = sha256:edc6b06527c296cbb6228de7ef6d3a4c068ee33f9e476531e82af55d4a3d613b layer 2: digest = sha256:58188a18e4bb81815adef0cb3a1f7d67769c9d3ab3cc7e1c0ac3e568af961e57 layer 3: digest = sha256:1ad2887d1caa4311ab17f85e898931bf5ce5596a918a39b36e87aee223f647f8
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss