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 :
> 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"
>  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) :
>> >
>> >
>> > 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 

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

On Oct 15, 2017, at 23:55, 
"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) 
> >:
> >
> >
> > 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 

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

Re: [opnfv-tech-discuss] [docs] Fuel and Armband merged documentation

[Raymond Paik]

Hi Alex,

I think it makes sense for Armband team to have a separate documentation if
you are going have support of other installers (e.g. Apex or JOID) in the
future

I agree that replicating docs is wasteful, but do you think this would
continue beyond Euphrates?

Thanks,

Ray

On Sunday, October 15, 2017, Alexandru Avadanii 
wrote:

> Hi,
> During the E release cycle, Fuel and Armband projects merged their
> documentation(s).
> Currently, the contents of Fuel's 'docs/' dir describe usage for both
> architecture.
> To keep the old behavior unchanged, we duplicated that docs dir in Armband
> for now.
>
> Going forward, I think building the same documentation twice is wasteful
> and unnecessary.
> How do you think we should proceed in this case?
>
> We can agree that Armband project won't publish any docs going further,
> and just remove the docs dir from our repo.
> Or we can add a stub pointing to the Fuel project.
>
> Please let us know what you think.
>
> Thank you,
> Alex
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] voting for new PTL of QTIP project

[Yujun Zhang (ZTE)]

QTIP committers

There have been no further nominations for the QTIP PTL position. Therefore
Zhihui Wu is the sole candidate.

To provide a record of this and acknowledgement from QTIP committers please
vote on gerrit[1] indicating your approval/disapproval (+2, -2) for Zhihui
to take over as PTL effective from the Fraser release.

[1]: https://gerrit.opnfv.org/gerrit/#/c/45157/

On Mon, Oct 9, 2017 at 8:05 PM 吴之惠  wrote:

>  I would like to accept the nomination for QTIP PTL and only hope that I
> can be an excellent PTL like Yujun. :-)
>
>
> Yujun Zhang (ZTE) 于2017年10月9日周一 下午4:32写道：
>
>> All,
>>
>> I'm opening the nomination period for QTIP PTL election. You may nominate
>> yourself or others *before Oct 15th*.
>>
>> I would like to nominate Zhihui WU (wu.zhih...@zte.com.cn) as new PTL
>> for QTIP. She has been active in the project since D release and make a
>> major contribution to it. I believe she will lead the project to a new
>> level.
>>
>> --
>> Yujun
>> --
>> Yujun Zhang
>>
> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Support of new types in TOSCA

[Julien]

Hi Serena,

It's a great news for TOSCA supported in Verigraph. It will make TOSCA
template more useful and enhance Parser ecosystem. Currently Parser is
integrating with ONAP project.

If it is reasonable, we can add it in Parser project. Let's discuss this
issue in email or with a meeting.
Xiaodong, can you hold a team meeting using zoom?

BR/Julien


Serena Spinoso 于2017年10月7日周六 下午10:38写道：

> Hi Shang, All,
>
> we would like to add the support of TOSCA in Verigraph, but we noticed
> that our catalogue of network functions does not exactly match with the
> types of nodes offered by TOSCA. That is the reason why we would kindly
> ask you how we can add new node types in TOSCA and, in turn, in Parser.
>
> Thanks a lots.
>
> Serena
>
> --
> Research Fellow
> Politecnico di Torino
> DAUIN - Dipartimento di Automatica e Informatica
> Email: serena.spin...@polito.it
>
> ___
> 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

Re: [opnfv-tech-discuss] Swift Support

[Julien]

Hi Mark,

It may be widely used in IT such as Image/Video/File storage. In NFV
scenario, Swift may be not a good use case.
Traditional telco products don't produce, transfer and consume these files.
Maybe it is useful in Edge computing.

Julien

Beierl, Mark 于2017年10月11日周三 下午10:21写道：

> Hello,
>
> I was wondering what installers or use cases we have in OPNFV for Swift
> object storage.  One of the planning activities for StorPerf Fraser would
> be Swift profiling, but I am not sure how useful that is to the community.
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> ___
> 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

Re: [opnfv-tech-discuss] [docs] Fuel and Armband merged documentation

[Julien]

I prefer to maintain it in installer project. If the affected content can
be documented in installer project properly, it will be easier for
maintainer, developer and end user.

Julien

Alexandru Avadanii 于2017年10月15日周日 下午11:27写道：

> Hi,
> During the E release cycle, Fuel and Armband projects merged their
> documentation(s).
> Currently, the contents of Fuel's 'docs/' dir describe usage for both
> architecture.
> To keep the old behavior unchanged, we duplicated that docs dir in Armband
> for now.
>
> Going forward, I think building the same documentation twice is wasteful
> and unnecessary.
> How do you think we should proceed in this case?
>
> We can agree that Armband project won't publish any docs going further,
> and just remove the docs dir from our repo.
> Or we can add a stub pointing to the Fuel project.
>
> Please let us know what you think.
>
> Thank you,
> Alex
> ___
> 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

Re: [opnfv-tech-discuss] [announce] user support topic for the TSC call

[Julien]

I just want to simplify the tools, one use case with one tool.
If we have multiple choice, I don't know which will be chosen and which
will be supported. For an end user, I care about how long it will take me
to get the feedback for my question. It may have duplicated threads in the
different tools.

Jira is good tools for issues, but I don't think it is suitable for
questions and supports. Title and content search are mostly used in
questions/forum, while it is not strong enough in Jira. From the history of
the website(ask.opnfv.org), we can find that it is not active enough, and
less response. If we agree to use that tool, and make it the only one, I
think it will be more and more useful to us.

BR/Julien



Beierl, Mark 于2017年10月16日周一 上午4:14写道：

> So far I have had a good experience with users reporting issues via JIRA.
> I must admit the askbot site has not been very useful for me at this time.
>
> Perhaps we need to highlight it more in the user guides?  I know I have
> not done that.
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Oct 15, 2017, at 15:19, Raymond Paik  wrote:
>
> All,
>
> I'd like to propose having a discussion on user support in an upcoming TSC
> call.  We have two primary channels for user support which are opnfv-user
> mailing list plus our Askbot site (https://ask.opnfv.org/questions/).
>
> Over the past several quarters the activity on the Askbot site in
> particular has gone down (see
> https://opnfv.biterg.io:443/goto/5f1aedc882d4c3e33a1e3bab812e353e), and
> I'd like to start a discussion on support channel for OPNFV users plus
> other tools (e.g. documentation, wiki, etc.).
>
> I'll add this as a topic for the TSC call on the 17th, but I think it'd
> also make sense to have follow-up discussions with anyone interested in
> participating following the TSC call.
>
> In the mean time, if you have any suggestions or thoughts on this topic,
> please feel free to chime in
>
> Thanks,
>
> Ray
>
> ___
> 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

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Julien]

Hi Alex,

It's a great news.
2 PODs in our lab reserved for MCP are blocked to deploy in master branch.
Can you give me a PDF/IDF link which are used now, then we will submit
PDF/IDF patches according to your version.

For **net_config**, I personally suggest to move it to IDF and get the
template/format approved ASSP, for it is really important to us.

BR/Julien

Alexandru Avadanii 于2017年10月15日周日 下午9:44写道：

> Hi,
>
> Fuel has been using PDF and IDF for weeks now.
>
> We still rely on net_config, which is out of spec, to map between PDF
> networks and the network role within the installer.
>
> Apart from net_config, we still need to sort out the mapping between
> interfaces indexes in PDF and the interface names inside OS (e.g. iface 0 =
> eno1, iface 2 = enp1s0f1).
>
>
>
> For net_config, Guillermo proposed an alternative as a comment in [1],
> which imo is closer to the hardware view of the setup (especially the
> port_matrix part).
>
> For iface name mapping, we will probably add it to IDF as a Fuel-specific
> section for now (no PoC proposed yet).
>
>
>
> BR,
>
> Alex
>
>
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml
>
>
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Julien
> *Sent:* Sunday, October 15, 2017 12:38 PM
> *To:* Jack Morgan; opnfv-tech-discuss
> *Subject:* Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting
> Minutes - Oct. 9th
>
>
>
> Hi Jack and Infra team:
>
>
>
> This week I have a chance to directly discuss with installer team: Apex
> and Compass. I still can not contact Joid.
>
>
>
> This is the status of PDF in each installer:
>
>
>
> Apex: Not started, won't support in E release, and I have submitted a Jira
> ticket in Apex.
>
> Compass: Not started, and plan to support in F release
>
> Daisy: PDF is supported and used in CI PODs for deployment, while IDF is
> not used for now
>
> Fuel: Started, not finished yet
>
> Joid: No response in email and IRC(#opnfv-joid)
>
>
>
> I would like to suggest to clear PDF/IDF patches in gerrit, let's make an
> acceptable template and update them in the future, then the lab owners can
> submit their PDF/IDF and used for deployment.
>
>
>
> BR/Julien
>
> Jack Morgan 于2017年10月10日周二 上午12:38写道：
>
> October 9th
>
> *Agenda:*
>
> 1.Status update on PDF
>
> · complete discussion from last week as this is a deliverable for
> Euphrates release
>
> 2.LaaS and Dashboard integration Lincoln Lavoie
> 
>
> 3.Infra documentation on RTD - patch 40329
> 
>  merged,
> what else?
>
> a. Discussion of Infra documentation
>
> 4.Zuul v3, Fatih Degirmenci
> 
>
>  .  possibility to start a prototype?
>
> 5.Follow up on security audit job logs  RELENG-272
> 
>  - Ericsson Build 3 not reporting failures to comments *IN PROGRESS*
>
> 6.F Release participation
>
> 7.Review actions items
>
> *Minutes (*link
> 
> *)*
>
> 1.*Status update on PDF *
>
> · David_Orange reports that IDF is mostly complete and haven't
> heard any feedback during the last week on his patch below
>
> · work in progress patch
> https://gerrit.opnfv.org/gerrit/#/c/42233/5/labs/orange/idf-pod1.yaml
> 

Re: [opnfv-tech-discuss] [announce] user support topic for the TSC call

[Beierl, Mark]

So far I have had a good experience with users reporting issues via JIRA. I 
must admit the askbot site has not been very useful for me at this time.

Perhaps we need to highlight it more in the user guides?  I know I have not 
done that.

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 15:19, Raymond Paik 
> wrote:

All,

I'd like to propose having a discussion on user support in an upcoming TSC 
call.  We have two primary channels for user support which are opnfv-user 
mailing list plus our Askbot site (https://ask.opnfv.org/questions/).

Over the past several quarters the activity on the Askbot site in particular 
has gone down (see 
https://opnfv.biterg.io:443/goto/5f1aedc882d4c3e33a1e3bab812e353e), and I'd 
like to start a discussion on support channel for OPNFV users plus other tools 
(e.g. documentation, wiki, etc.).

I'll add this as a topic for the TSC call on the 17th, but I think it'd also 
make sense to have follow-up discussions with anyone interested in 
participating following the TSC call.

In the mean time, if you have any suggestions or thoughts on this topic, please 
feel free to chime in

Thanks,

Ray
___
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

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

[opnfv-tech-discuss] [announce] user support topic for the TSC call

[Raymond Paik]

All,

I'd like to propose having a discussion on user support in an upcoming TSC
call.  We have two primary channels for user support which are opnfv-user
mailing list plus our Askbot site (https://ask.opnfv.org/questions/).

Over the past several quarters the activity on the Askbot site in
particular has gone down (see
https://opnfv.biterg.io:443/goto/5f1aedc882d4c3e33a1e3bab812e353e), and I'd
like to start a discussion on support channel for OPNFV users plus other
tools (e.g. documentation, wiki, etc.).

I'll add this as a topic for the TSC call on the 17th, but I think it'd
also make sense to have follow-up discussions with anyone interested in
participating following the TSC call.

In the mean time, if you have any suggestions or thoughts on this topic,
please feel free to chime in

Thanks,

Ray
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

[Cedric OLLIVIER]

Hello Alec,

Please find several answers inline.

Cédric

2017-10-14 20:55 GMT+02:00 Alec Hothan (ahothan) :
>
>
> 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.

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

[opnfv-tech-discuss] Weekly Technical Discussion #102

[HU, BIN]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="HU, BIN":MAILTO:bh5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:https://global.gotomeeting.com/join/819733085\n+
 1 (312) 757-3126 / Access Code: 819-733-085\n\nHello community:\n\nThis is
  our 102nd  weekly technical discussion at 6am PDT / 9am EDT Thursday Octo
 ber 19th\, 2017\, which is 13:00 UTC.\n\nWe will discuss a new project pro
 posal Clover by Wenjing Chu.\n\nYou can find your local time he
 re http://www.timeanddate.com/worldclock/fixedtime.html?msg=OPNFV-Technica
 l-Discussion=20171019T13=1.\n\nPlease refer to https://wiki.opnfv.o
 rg/display/PROJ/Weekly+Technical+Discussion for details of dialing logisti
 cs and tentative agenda.\n\nPlease let me know if you want to add anything
  to agenda for discussion in the community.\n\nFor your convenience:\n-   
 GoTo Meeting: https://global.gotomeeting.com/join/819733085\n-   Y
 ou can also dial in using your phone:\no   United States (Long distanc
 e): +1 (312) 757-3126 / Access Code: 819-733-085\no   More phone numbe
 rs: https://global.gotomeeting.com/819733085/numbersdisplay.html\n\nThanks
 \nBin\n\n\n
SUMMARY;LANGUAGE=en-US:Weekly Technical Discussion #102
DTSTART;TZID=Pacific Standard Time:20171019T06
DTEND;TZID=Pacific Standard Time:20171019T07
UID:04008200E00074C5B7101A82E00830904B779945D301000
 010003D47F58CA0A48D4E943B996F1CD1D542
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20171015T163915Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US: +1 (312) 757-3126 / Access Code: 819-733-085
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1737512991
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [docs] Fuel and Armband merged documentation

[Alexandru Avadanii]

Hi,
During the E release cycle, Fuel and Armband projects merged their 
documentation(s).
Currently, the contents of Fuel's 'docs/' dir describe usage for both 
architecture.
To keep the old behavior unchanged, we duplicated that docs dir in Armband for 
now.

Going forward, I think building the same documentation twice is wasteful and 
unnecessary.
How do you think we should proceed in this case?

We can agree that Armband project won't publish any docs going further, and 
just remove the docs dir from our repo.
Or we can add a stub pointing to the Fuel project.

Please let us know what you think.

Thank you,
Alex
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [releng][ovsnfv] Disabling RPM builds in ovsnfv

[Thomas F Herbert]

Question about best way to disable RPM builds in ovsnfv

In the August ovsnfv meeting we agreed to disable the building of OVS 
and DPDK RPM artifacts within the ovsnfv project as this effort is 
redundant with OVS RPMs found in downstream Centos repos.


Having received no negative public comments,  we merged a local patch to 
ovsnfv.


However, we are still getting build errors in Euphrates daily builds: 
https://build.opnfv.org/ci/job/ovsnfv-daily-euphrates/11/console


Do we need to cherry-pick that patch to a different patch or should the 
disable of ovsnfv builds be done with a patch releng?


--Tom

--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Alexandru Avadanii]

Hi,
Fuel has been using PDF and IDF for weeks now.
We still rely on net_config, which is out of spec, to map between PDF networks 
and the network role within the installer.
Apart from net_config, we still need to sort out the mapping between interfaces 
indexes in PDF and the interface names inside OS (e.g. iface 0 = eno1, iface 2 
= enp1s0f1).

For net_config, Guillermo proposed an alternative as a comment in [1], which 
imo is closer to the hardware view of the setup (especially the port_matrix 
part).
For iface name mapping, we will probably add it to IDF as a Fuel-specific 
section for now (no PoC proposed yet).

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Julien
Sent: Sunday, October 15, 2017 12:38 PM
To: Jack Morgan; opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

Hi Jack and Infra team:

This week I have a chance to directly discuss with installer team: Apex and 
Compass. I still can not contact Joid.

This is the status of PDF in each installer:

Apex: Not started, won't support in E release, and I have submitted a Jira 
ticket in Apex.
Compass: Not started, and plan to support in F release
Daisy: PDF is supported and used in CI PODs for deployment, while IDF is not 
used for now
Fuel: Started, not finished yet
Joid: No response in email and IRC(#opnfv-joid)

I would like to suggest to clear PDF/IDF patches in gerrit, let's make an 
acceptable template and update them in the future, then the lab owners can 
submit their PDF/IDF and used for deployment.

BR/Julien
Jack Morgan >于2017年10月10日周二 
上午12:38写道：
October 9th

Agenda:
1.Status update on PDF
· complete discussion from last week as this is a deliverable for 
Euphrates release
2.LaaS and Dashboard integration Lincoln 
Lavoie
3.Infra documentation on RTD - patch 
40329
 merged, what else?
a. Discussion of Infra documentation
4.Zuul v3, Fatih 
Degirmenci
 .  possibility to start a prototype?
5.Follow up on security audit job logs  
[https://jira.opnfv.org/secure/viewavatar?size=xsmall=10303=issuetype]
 
RELENG-272
 - Ericsson Build 3 not reporting failures to comments IN PROGRESS
6.F Release participation
7.Review actions items

Minutes 
(link)
1.Status update on PDF
· David_Orange reports that IDF is mostly complete and haven't heard 
any feedback during the last week on his patch below
· work in progress patch  
https://gerrit.opnfv.org/gerrit/#/c/42233/5/labs/orange/idf-pod1.yaml
· current SDF patch 

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Julien]

Hi Jack and Infra team:

This week I have a chance to directly discuss with installer team: Apex and
Compass. I still can not contact Joid.

This is the status of PDF in each installer:

Apex: Not started, won't support in E release, and I have submitted a Jira
ticket in Apex.
Compass: Not started, and plan to support in F release
Daisy: PDF is supported and used in CI PODs for deployment, while IDF is
not used for now
Fuel: Started, not finished yet
Joid: No response in email and IRC(#opnfv-joid)

I would like to suggest to clear PDF/IDF patches in gerrit, let's make an
acceptable template and update them in the future, then the lab owners can
submit their PDF/IDF and used for deployment.

BR/Julien

Jack Morgan 于2017年10月10日周二 上午12:38写道：

> October 9th
>
> *Agenda:*
>
>1. Status update on PDF
>   - complete discussion from last week as this is a deliverable for
>   Euphrates release
>2. LaaS and Dashboard integration Lincoln Lavoie
>
>3. Infra documentation on RTD - patch 40329
> merged, what else?
>   1. Discussion of Infra documentation
>   4. Zuul v3, Fatih Degirmenci
>
>   1. possibility to start a prototype?
>5. Follow up on security audit job logs  RELENG-272
> - Ericsson Build 3 not
>reporting failures to comments IN PROGRESS
>6. F Release participation
>7. Review actions items
>
> *Minutes (*link
> 
> *)*
>
>1. *Status update on PDF *
>   - David_Orange reports that IDF is mostly complete and haven't
>   heard any feedback during the last week on his patch below
>   - work in progress patch
>   https://gerrit.opnfv.org/gerrit/#/c/42233/5/labs/orange/idf-pod1.yaml
>   - current SDF patch https://gerrit.opnfv.org/gerrit/#/c/36977/
>2. *LaaS and Dashboard integration*
>   - lylavoie is working on LF hosting issues with bramwelt but will
>   focus on it after the release
>   - requirements gathering and plan is being tracked via Dashboard
>   Roadmap 
>3. *Infra documentation on RTD*
>   - initial patch 40329  has
>   been merged, what else needs to be migrated
>   - bramwelt has some documentation to post but not sure which
>   project it goes
>4. *AoB*
>   - bryan_att mentioned that the Equifax breach was due to Apache
>   structs vulnerability
>   - bryan_att suggests we need some discussion on potential scanner
>   tools for production deployments
>   - Luke will investigate ODL scanning and bryan_att will bring it up
>   at the TSC
>   - jmorgan1 mentions this is a good Plugfest topic
>5. *Action Items*
>   - contact installer PTLs support of PDF in Euphrates
>   - Fuel/MCP and Daisy4NFV has support for PDF, Compass4NFV will
>  delay working on it until F release
>  - Apex and Joid have not responded to emails
>   - closed and new action items below
>
> *Closed Actions:*
>
>- Contact installer PTLs for support of PDF in Euphrates julien zhang
>
> - Submit patches to add lab owners and others to Pharos repo Aric Gardner
>
>- Reach out to lab owners to collect feedback on including username
>and password in PDF Jack Morgan
>- Reach out to Luke Hinds  to
>security projects input on passwords in PDF Aric Gardner
>
>- Create wiki page to track next steps and features for Laas/dashboard
>effort Lincoln Lavoie 
>- Reach out to Joid, Apex and Compass need to provide a contact for
>PDF effort julien zhang 
>- create POC on encryption option Aric Gardner
>
>-
>
> *New Actions:*
>
>- work on putting infrastructure documentation structure in place Trevor
>Bramwell 
>- work with lylavoie to get CI Pods displayed on labs.opnfv.org Trevor
>Bramwell 
>
> --
> Jack Morgan
> OPNFV Pharos Intel Lab
>
> ___
> 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

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