Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

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-

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Beierl, Mark]

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<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
> fo

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[cedric.ollivier]

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

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Alexandru Avadanii]

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 w

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

gt; 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

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

Hello,

I disagree to add variables in FROM instructions simply because it
obliges latest versions and then breaks Docker Automated builds.
It simply useless if we rely on Docker manifests as I have already demonstrated.
Manifest will also help jjobs as it avoids multiplying daily jjobs per arch.

Cédric

2017-10-14 17:29 GMT+02:00 Alexandru Avadanii <alexandru.avada...@enea.com>:
> 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 depe

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Alec Hothan (ahothan)]

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>
 [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 a

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Alexandru Avadanii]

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:
> >  - t

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

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 :
> 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  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 :
>> 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+Releng
>>
>>
>>
>>
>>
>>
>> On 11 Oct 2017, at 09:42, Cristina Pauna  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 

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Fatih Degirmenci]

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  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 :
> 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+Releng
> 
> 
> 
> 
> 
> 
> On 11 Oct 2017, at 09:42, Cristina Pauna  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 ;
> jalaus...@suse.com; Delia Popescu ; Alexandru
> Avadanii ; Cristina Pauna
> ; wangwu...@huawei.com
> Cc: opnfv-tech-discuss 
> 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 

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

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 :
> 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+Releng
>
>
>
>
>
>
> On 11 Oct 2017, at 09:42, Cristina Pauna  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 ;
> jalaus...@suse.com; Delia Popescu ; Alexandru
> Avadanii ; Cristina Pauna
> ; wangwu...@huawei.com
> Cc: opnfv-tech-discuss 
> 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 

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cristina Pauna]

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 ; jalaus...@suse.com; 
Delia Popescu ; Alexandru Avadanii 
; Cristina Pauna ; 
wangwu...@huawei.com
Cc: opnfv-tech-discuss 
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 the architecture 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] [functest] Alpine for arch

[Cristina Pauna]

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 the architecture 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
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss