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<tel:1-613-314-8106> mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Oct 15, 2017, at 23:55, "cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>" <cedric.olliv...@orange.com<mailto: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<mailto:cedric.olliv...@orange.com>; opnfv- > tech-discuss; Delia Popescu; David McBride; > morgan.richo...@orange.com<mailto: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<mailto: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<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>> > > on behalf of > > Alexandru Avadanii > > <alexandru.avada...@enea.com<mailto:alexandru.avada...@enea.com>> > > Date: Saturday, October 14, 2017 at 8:30 AM > > To: Cedric OLLIVIER > > <ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>, Fatih > > Degirmenci > > <fde...@gmail.com<mailto:fde...@gmail.com>> > > Cc: "cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>" > > <cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>, > > opnfv-tech-discuss > > <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>, > > Delia Popescu > > <delia.pope...@enea.com<mailto: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> > > [mailto:opnfv-tech-discuss- > > > > boun...@lists.opnfv.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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> > >>> [mailto:cedric.olliv...@orange.com] > > > >>> Sent: Wednesday, October 11, 2017 7:24 AM > > > >>> To: RICHOMME Morgan IMT/OLN > >>> <morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>>; > > > >>> jalaus...@suse.com<mailto:jalaus...@suse.com>; Delia Popescu > >>> <delia.pope...@enea.com<mailto:delia.pope...@enea.com>>; > >>> Alexandru > > > >>> Avadanii > >>> <alexandru.avada...@enea.com<mailto:alexandru.avada...@enea.com>>; > >>> Cristina Pauna > > > >>> <cristina.pa...@enea.com<mailto:cristina.pa...@enea.com>>; > >>> wangwu...@huawei.com<mailto:wangwu...@huawei.com> > > > >>> Cc: opnfv-tech-discuss > >>> <opnfv-tech-discuss@lists.opnfv.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
