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
