[opnfv-tech-discuss] OPNFV Packaging CI

[Alexandru Avadanii]

Hi,

I started a very small etherpad for gathering ideas about packaging CI in 
OPNFV, see [1].
I am aware our purpose is upstreaming our changes, but this is not always 
possible or effective, hence the need for some form of our own package 
distribution systems.
Hopefully, this could be a nice addition, and not something encouraging 
spinning distro forks of CentOS/Ubuntu etc.

Looking forward to your thoughts on this one.

BR,
Alex

[1] https://etherpad.openstack.org/p/OPNFV_packaging_CI
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Packaging CI

[Alexandru Avadanii]

Hi, Luke,
My experience so far included mostly DEB packages, which fell in 3 categories 
for Armband:

-  Backported from newer distro (lots of Ubuntu Xenial arm64 DEBs 
backported to Trusty)

-  Patched until upstream pulls our fixes (lshw is a good example, it’s 
broken in all arm64 Ubuntus  - all distros)

-  Divergent functionality (we roll our own grub2, based on an Ubuntu 
pacakge, but with added patches from Fedora and OpenSUSE – it’s hard to fiind a 
grub2 package that satifies all conditions for integrating with our Cobbler 
integration approach)

As for RPMs, we built only 2 custom packages, which I’m sure won’t be 
upstreamed soon:

-  qemu-user-static for CentOS7 (implied building some static libs as 
well, including libc), which is used by Fuel to cross-build images (e.g. arm64 
chroots on a x86 machine);

-  cobbler-grub-aarch64 (contains a single EFI-compatible arm64 binary 
of grub2-efi-arm64 standalone, used by cobbler as the netloader of choice for 
Armband)

In my opinion, handlng the above by hand or using obscure external procedures 
(most Fuel plugins build some DEBs and/or RPMs, each in a different way) is 
prone to error
and code duplication over time.

Also, and maybe I should have started with this, consider the case where the 
ISO build process is tied to x86 (like Fuel currently is), and the artifacts 
are expected to contain
packages for different architectures (AArch64?), which cannot be locally built 
[easily], in which case fetching some precompiled packages from an OPNFV public 
repo would be nice.

BR,
Alex

From: Luke Hinds [mailto:lhi...@redhat.com]
Sent: Sunday, September 25, 2016 11:51 AM
To: Alexandru Avadanii
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI

Hi Alex,

What constitutes CI? If you could give one specific case of what you see as 
needing packaging, that would be useful.

Cheers,

Luke

On Fri, Sep 23, 2016 at 6:07 PM, Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:
Hi,

I started a very small etherpad for gathering ideas about packaging CI in 
OPNFV, see [1].
I am aware our purpose is upstreaming our changes, but this is not always 
possible or effective, hence the need for some form of our own package 
distribution systems.
Hopefully, this could be a nice addition, and not something encouraging 
spinning distro forks of CentOS/Ubuntu etc.

Looking forward to your thoughts on this one.

BR,
Alex

[1] https://etherpad.openstack.org/p/OPNFV_packaging_CI
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss



--
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com<mailto:lhi...@redhat.com> | irc: lhinds @freenode | m: +44 
77 45 63 98 84 | t: +44 12 52 36 2483
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [fuel] Nominating of Alexandru Avadanii

[Alexandru Avadanii]

Thank you, all!


From: Jonas Bjurel [mailto:jonas.bju...@ericsson.com]
Sent: Monday, September 26, 2016 8:14 PM
To: Gregory Elkinbard; Stefan Berg K
Cc: Daniel Smith; opnfv-tech-discuss@lists.opnfv.org; Alexandru Avadanii
Subject: RE: [opnfv-tech-discuss] [fuel] Nominating of Alexandru Avadanii

This means that we have a majority for Alexandru as an Fuel@OPNFV committer.
I will proceed with needed paper works.
Welcome Alexandru.
BR/Jonas

From: Gregory Elkinbard [mailto:gelkinb...@mirantis.com]
Sent: Friday, September 23, 2016 8:24 PM
To: Stefan Berg K 
mailto:stefan.k.b...@ericsson.com>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>; 
Jonas Bjurel mailto:jonas.bju...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>
Subject: Re: [opnfv-tech-discuss] [fuel] Nominating of Alexandru Avadanii

+1

On Fri, Sep 23, 2016 at 3:20 AM, Stefan Berg K 
mailto:stefan.k.b...@ericsson.com>> wrote:

+1


Från: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 för Daniel Smith mailto:daniel.sm...@ericsson.com>>
Skickat: den 23 september 2016 08:52:47
Till: Jonas Bjurel; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Alexandru Avadanii
Ämne: Re: [opnfv-tech-discuss] [fuel] Nominating of Alexandru Avadanii

+1

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:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of Jonas Bjurel
Sent: Thursday, September 22, 2016 2:36 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>
Subject: [opnfv-tech-discuss] [fuel] Nominating of Alexandru Avadanii

I would like to nominate Alexandru Avadanii (ENEA) as a committer in 
Fuel@OPNFV, I have been in contact
with Alexandru and his willing to take on the role.
Alexandru is one of the main architects/committers in Armband which is a port 
of Fuel@OPNFV to the ARM
Architecture, he has also been very active in Fuel@OPNFV.
This month, Alexandru is the OPNFV committer with the most commits.

OPNFV committers, reply to this mail with your vote (-1, 0, +1).

BR/Jonas

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

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

Re: [opnfv-tech-discuss] OPNFV Packaging CI

[Alexandru Avadanii]

Hi, Luke, Leif,

Thank you for your feedback!



I do not have any preferences towards the method we use, if we can use 
something as-is, I'm all for it.

I was not aware of COPR, but I'll try to get up to speed and add it to the 
etherpad.



As for PPA, that is an interesting approach I haven’t thought about … any 
thoughts on using a private PPA for each OPNFV project?

Ideally, end-users should also be able to submit fixes/patches that we can 
easily check into our packaging source tree – not sure PPA fits very well this 
requirement (?).



If you have any other suggestions for a DEB alternative, I really want to hear 
them, so far the most interesting solution would be Perestroika from Mirantis, 
shipped as part of Fuel@OPNFV.

So far, we used git-buildpackage and custom scripts for DEB building, but that 
is neither easy to maintain, nor is it an integrated, ready-to-use solution.



BR,

Alex


From: Luke Hinds [mailto:lhi...@redhat.com]
Sent: Tuesday, September 27, 2016 1:20 PM
To: Leif Madsen
Cc: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI



On Tue, Sep 27, 2016 at 1:55 AM, Leif Madsen 
mailto:lmad...@redhat.com>> wrote:
On Sun, Sep 25, 2016 at 01:19:21PM +, Alexandru Avadanii wrote:
> Hi, Luke,
> My experience so far included mostly DEB packages, which fell in 3 categories 
> for Armband:
>
> -  Backported from newer distro (lots of Ubuntu Xenial arm64 DEBs 
> backported to Trusty)
>
> -  Patched until upstream pulls our fixes (lshw is a good example, 
> it’s broken in all arm64 Ubuntus  - all distros)
>
> -  Divergent functionality (we roll our own grub2, based on an Ubuntu 
> pacakge, but with added patches from Fedora and OpenSUSE – it’s hard to fiind 
> a grub2 package that satifies all conditions for integrating with our Cobbler 
> integration approach)
>
> As for RPMs, we built only 2 custom packages, which I’m sure won’t be 
> upstreamed soon:
>
> -  qemu-user-static for CentOS7 (implied building some static libs as 
> well, including libc), which is used by Fuel to cross-build images (e.g. 
> arm64 chroots on a x86 machine);
>
> -  cobbler-grub-aarch64 (contains a single EFI-compatible arm64 
> binary of grub2-efi-arm64 standalone, used by cobbler as the netloader of 
> choice for Armband)
>
> In my opinion, handlng the above by hand or using obscure external procedures 
> (most Fuel plugins build some DEBs and/or RPMs, each in a different way) is 
> prone to error
> and code duplication over time.
>
> Also, and maybe I should have started with this, consider the case where the 
> ISO build process is tied to x86 (like Fuel currently is), and the artifacts 
> are expected to contain
> packages for different architectures (AArch64?), which cannot be locally 
> built [easily], in which case fetching some precompiled packages from an 
> OPNFV public repo would be nice.

Do you have a particular method in mind here? I think my biggest
issue would be around building yet another system to build packages. For
example, for RPMs, it would be almost trivial to employ the COPR build
system and host any custom packages in that namespace.

What I would hate to see, would be a set of custom scripts or
applications to build packages, and then host them within the OPNFV
namespace, along with having to maintain that whole pipeline.

I assume there is some sort of DEB equivalent of COPR where those
packages could be hosted, and packages build on a remote service?

There is PPA ():

https://help.launchpad.net/Packaging/PPA


--
Leif Madsen | Partner Engineer - NFV & CI
NFV Partner Engineering
Red Hat
GPG: (D670F846) BEE0 336E 5406 42BA 6194 6831 B38A 291E D670 F846


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

[opnfv-tech-discuss] [armband] Nominating Cristina Pauna

[Alexandru Avadanii]

Hi!
I would like to nominate Cristina Pauna (ENEA) as a committer to Armband@OPNFV, 
I have checked with her and she's willing to take on the role.

Cristina has a vast networking background, and has been very active as a 
contributor to Armband and Functest.

OPNFV Armband committers, please reply to this mail with your vote (-1, 0, +1).

I will start:

+1

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

Re: [opnfv-tech-discuss] [FUEL] Danube - OS Support

[Alexandru Avadanii]

Hi, Maryam,
The next Fuel (upcoming in D release) will be Fuel 10, which is intended for 
Ubuntu 16.04 (Xenial LTS).

BR,
Alex

> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-
> discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
> Sent: Wednesday, September 28, 2016 7:42 PM
> To: TECH-DISCUSS OPNFV
> Subject: [opnfv-tech-discuss] [FUEL] Danube - OS Support
> 
> Hi Fuel Team
> 
> I'm just wondering what version of Ubuntu will the upcoming Fuel version
> support? I'd like to be able to validate my features without fuel in a similar
> environment before the fuel plugin integration takes place.
> 
> Thanks in advance
> Maryam
> ___
> 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] [FUEL] Danube - OS Support

[Alexandru Avadanii]

Hi, Greg,
Thank you for explaining the differences between Newton and F10, I was under 
the false impression they are the same.
Mea culpa.

Alex


From: Gregory Elkinbard [mailto:gelkinb...@mirantis.com]
Sent: Wednesday, September 28, 2016 8:51 PM
To: Alexandru Avadanii
Cc: Tahhan, Maryam; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [FUEL] Danube - OS Support

Hi Alexandru,
Technically it will be Fuel/Newton the upstream version of Fuel from the 
openstack community.
F10 the commercial downstream version is going to come in end of March to 
accomodate kubernetes based openstack control plane.
It will be too late for D. The new F10 architecture will come into E.

Greg


On Wed, Sep 28, 2016 at 9:52 AM, Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:
Hi, Maryam,
The next Fuel (upcoming in D release) will be Fuel 10, which is intended for 
Ubuntu 16.04 (Xenial LTS).

BR,
Alex

> -Original Message-
> From: 
> opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
>  [mailto:opnfv-tech-<mailto:opnfv-tech->
> discuss-boun...@lists.opnfv.org<mailto:discuss-boun...@lists.opnfv.org>] On 
> Behalf Of Tahhan, Maryam
> Sent: Wednesday, September 28, 2016 7:42 PM
> To: TECH-DISCUSS OPNFV
> Subject: [opnfv-tech-discuss] [FUEL] Danube - OS Support
>
> Hi Fuel Team
>
> I'm just wondering what version of Ubuntu will the upcoming Fuel version
> support? I'd like to be able to validate my features without fuel in a similar
> environment before the fuel plugin integration takes place.
>
> Thanks in advance
> Maryam
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

Re: [opnfv-tech-discuss] [announce] Upgrade of Gerrit report. (ssh host key changed)

[Alexandru Avadanii]

Hi,
If gerrit web login fails, make sure you also try using the lowercase username, 
even though you used to login with a capitalized username before.

> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-
> discuss-boun...@lists.opnfv.org] On Behalf Of Fatih Degirmenci
> Sent: Monday, October 03, 2016 11:25 AM
> To: SULLIVAN, BRYAN L; Aric Gardner; infra-steer...@lists.opnfv.org; OPNFV
> Tech
> Subject: Re: [opnfv-tech-discuss] [announce] Upgrade of Gerrit report. (ssh
> host key changed)
> 
> Hi,
> 
> I hear people are having issues while logging in to Gerrit via web interface 
> so
> something doesn't look right.
> LF helpdesk should be getting some tickets right now.
> 
> 
> /Fatih
> 
> On 2016-10-03, 4:31 AM ☀️, "SULLIVAN, BRYAN L" 
> wrote:
> 
> The fix was pretty painless. For me it was (on a JOID jumphost)
> ssh-keygen -f "/home/ubuntu/.ssh/known_hosts" -R
> [gerrit.opnfv.org]:29418
> and accept the new key on a reclone.
> 
> Thanks,
> Bryan Sullivan | AT&T
> 
> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-
> discuss-boun...@lists.opnfv.org] On Behalf Of Aric Gardner
> Sent: Sunday, October 02, 2016 4:20 PM
> To: infra-steer...@lists.opnfv.org; OPNFV Tech  disc...@lists.opnfv.org>; Fatih Degirmenci
> 
> Subject: [opnfv-tech-discuss] [announce] Upgrade of Gerrit report. (ssh
> host key changed)
> 
> Hello,
> 
> The upgrade of gerrit to 2.13.1 is complete.
> And jenkins has been restarted to give it more memory.
> 
> There is an unfortunate caveat. I did not consider the rsa keys on the
> old gerrit server would not be compatible with java on the new server
> 
> the old gerrit server has only one key.
> 
> ssh_host_key
> 
> the new gerrit server has
> 
> ssh_host_dsa_key
> ssh_host_dsa_key.pub
> ssh_host_rsa_key
> ssh_host_rsa_key.pub
> 
> I tried to copy over the old ssh_host_key and use it as the rsa key on
> the new server, but it is in MINA SSHD custom format. Both the public
> and private halves are stored in the "ssh_host_key" file using a Java
> serialization format. I searched online, and did not find any
> utilities to convert this.
> 
> Gerrit failed to start like so:
> [2016-10-02 22:32:38,226] [main] WARN
> 
> org.apache.sshd.common.util.SecurityUtils$BouncyCastleFileKeyPairProvider
> : Failed (IOException) to load key
> resource=/opt/gerrit/etc/ssh_host_rsa_key: Failed to read
> /opt/gerrit/etc/ssh_host_rsa_key - unknown result object: null
> 
> 18:56 < AlexAvadanii> aricg-: given the time, we could fix this, but
> it's probably not
>   that easy as converting one file to another
> using a cli tool ...
>   or if there is such a tool, I can't find it
> 
> I agree with Alex, but we can't stop using gerrit while we try to fix
> this unforeseen problem.
> 
> So going forward, everything works excepting the host key change. Any
> machine or developer that clones over ssh will see this warning.
> 
> git clone ssh://jenkins...@gerrit.opnfv.org:29418/releng
> Initialized empty Git repository in /tmp/releng/.git/
> 
> 
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> 
> 
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle
> attack)!
> It is also possible that the RSA host key has just been changed.
> The fingerprint for the RSA key sent by the remote host is
> 46:3a:c5:80:58:7e:24:9e:88:d3:83:29:6c:9a:80:17.
> Please contact your system administrator.
> Add correct host key in /home/agardner/.ssh/known_hosts to get rid of
> this message.
> Offending key in /home/agardner/.ssh/known_hosts:1
> RSA host key for [gerrit.opnfv.org]:29418 has changed and you have
> requested strict checking.
> Host key verification failed.
> 
> you will need to remove the specified line in /home/"Your
> user"/.ssh/known_hosts:"The line number to delete"
> and then re-accept the new key.
> 
> Apologies in advance and best regards,
> -Aric
> ___
> 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] [Fuel] Tuesday's casual meeting

[Alexandru Avadanii]

Hi,
+1 for casual meeting

> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-
> discuss-boun...@lists.opnfv.org] On Behalf Of Michal Skalski
> Sent: Tuesday, October 11, 2016 12:39 PM
> To: Fedor Zhadaev
> Cc: MichalSkalski , yunhong.ji...@linux.intel.com
> , opnfv-tech-discuss@lists.opnfv.org
> Subject: Re: [opnfv-tech-discuss] [Fuel] Tuesday's casual meeting
> 
> Hi,
> 
> I vote for casual meeting.
> 
> Michal
> > On 11 Oct 2016, at 11:17, Stefan Berg K 
> wrote:
> >
> > Hi,
> >
> > I'd vote for a best-effort IRC meeting.
> >
> > Cheers,
> >
> > Stefan
> >
> > Från: opnfv-tech-discuss-boun...@lists.opnfv.org  boun...@lists.opnfv.org> för Fedor Zhadaev 
> > Skickat: den 11 oktober 2016 10:53
> > Till: MichalSkalski ,
> yunhong.ji...@linux.intel.com , opnfv-
> tech-disc...@lists.opnfv.org
> > Ämne: [opnfv-tech-discuss] [Fuel] Tuesday's casual meeting
> >
> > Hello Fuel team.
> > I have question about our Tuesday's meeting. What is your vision of it?
> Should it be formal meeting (i.e. sync-up) or just time-slot when most of
> active people will be available in IRC and ready for discussion?
> > In the first case I'll need to propose to move it for an hour earlier 
> > (before
> TSC meeting) or 1.5 hours later (after Release meeting) to be able to drive 
> it.
> > It the second case I'll be partially available on this meeting due to my
> attending of TSC meeting.
> > Please share your opinion here. By default I'll propose the second solution
> for today.
> > --
> > Kind Regards,
> > Fedor Zhadaev
> >
> > email: fzhad...@mirantis.com
> > skype: zhadaevfm
> > IRC: fzhadaev
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> 
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [fuel] Nominating Michael Polenchuk

[Alexandru Avadanii]

Hi,
I would like to nominate Michael Polenchuk (Mirantis) as a committer in 
Fuel@OPNFV.
I have been in contact with Michael and he is willing to take on the role.

Michael is one of the main contributors in Fuel@OPNFV, as well as numerous 
upstream projects,
and he has been one of the most active and valuable contributors during the 
Danube release cycle.

OPNFV committers, reply to this mail with your vote (-1, 0, +1).
I'll start:
+1

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

[opnfv-tech-discuss] Fuel and Armband Fuel Danube 2.0 ISOs

[Alexandru Avadanii]

Hi,
Fuel and Armband projects are pleased to announce the public release of Danube 
2.0.

1. Fuel artifacts
Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].

2. Armband artifacts
Git tag at [2], ISO build logs [4], ISO [6], documentation [10, 11, 12].

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=danube.2.0
[2] https://git.opnfv.org/armband/tag/?h=danube.2.0
[3] https://build.opnfv.org/ci/view/fuel/job/fuel-build-daily-danube/310/console
[4] 
https://build.opnfv.org/ci/view/armband/job/armband-fuel-build-daily-danube/20/console
[5] http://artifacts.opnfv.org/fuel/danube/opnfv-2017-05-04_18-00-10.iso
[6] http://artifacts.opnfv.org/armband/danube/opnfv-2017-05-04_17-22-32.iso
[7] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/development/overview/build/build.instruction.html
[8] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/release/release-notes/release-notes.html
[9] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/release/installation/installation.instruction.html
[10] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/development/overview/build/build.instruction.html
[11] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/release/release-notes/release-notes.html
[12] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/release/installation/installation.instruction.html
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] FW: Fuel and Armband Fuel Danube 3.0 ISOs

[Alexandru Avadanii]

Hi,
Fuel and Armband projects are pleased to announce the public release of Danube 
3.0.

1. Fuel artifacts
Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].

2. Armband artifacts
Git tag at [2], ISO build logs [4], ISO [6], documentation [10, 11, 12].

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=danube.3.0
[2] https://git.opnfv.org/armband/tag/?h=danube.3.0
[3] https://build.opnfv.org/ci/view/fuel/job/fuel-build-daily-danube/738/console
[4] 
https://build.opnfv.org/ci/view/armband/job/armband-fuel-build-daily-danube/28/console
[5] http://artifacts.opnfv.org/fuel/danube/opnfv-2017-07-14_14-00-12.iso
[6] http://artifacts.opnfv.org/armband/danube/opnfv-2017-07-14_13-43-04.iso
[7] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/development/overview/build/build.instruction.html
[8] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/release/release-notes/release-notes.html
[9] 
http://docs.opnfv.org/en/stable-danube/submodules/fuel/docs/release/installation/installation.instruction.html
[10] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/development/overview/build/build.instruction.html
[11] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/release/release-notes/release-notes.html
[12] 
http://docs.opnfv.org/en/stable-danube/submodules/armband/docs/release/installation/installation.instruction.html
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [armband] Resource for development or testing

[Alexandru Avadanii]

Hi, Mark,
armhf won't work, that is ARMv7, while we target ARMv8 (aarch64). The 
appropiate arch qualifier would be (for a Debian system like Ubuntu):
[arch=arm64]
But unless you are trying to do something extremely specific, that should not 
be needed, stock Ubuntu 16.04 already has a working docker for AArch64.

Btw, we are already building a few AArch64 Docker images, for functest [1], 
dovetail [2], soon yardstick etc.
The releng bit handling AArch64 can be found at [3] and works like this:

-  If DOCKERFILE parameter is passed to build job (in format 
"Dockerfile.aarch64" usually) and the file exists in the git repo, it will be 
used instead of default "Dockerfile";

-  If DOCKERFILE parameter is passed (same "Dockerfile.aarch64"), but 
it doesn't exist, releng will look for "Dockerfile.aarch64.patch", apply that 
on top of "Dockerfile", then use it;

The builder machine handling [2] and [3] is arm-build3 [4], an AArch64 VM on a 
ThunderX node.
It runs Ubuntu Xenial (16.04.2), and docker was installed from Ubuntu repos 
using apt (no custom repository was necessary afaik).

CC'in Alex Nemes from our side, as he recently worked on this and might have 
things fresh in his memory for further queries.

BR,
Alex

[1] 
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-arm-push-master/
[2] https://build.opnfv.org/ci/job/dovetail-docker-build-arm-push-master/
[3] 
https://github.com/opnfv/releng/blob/master/jjb/releng/opnfv-docker.sh#L58-L71
[4] https://build.opnfv.org/ci/computer/arm-build3/builds


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bob Monkman
Sent: Thursday, August 03, 2017 11:11 PM
To: Beierl, Mark
Cc: Måns Söderberg; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Mark,
  I am sorry that am not close to the technical mechanisms by which 
this works. I have directly copied a couple of Armbanders to see if they can 
provide a quick answer. The caveat is that a number of developers may be on 
holiday and the remaining team is pressed trying to create bare metal deploys 
for MCP with the new MS5 just 8 days away. Sorry, bad timing but let's see if 
something can be provided for a pointer.

Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, August 3, 2017 1:03 PM
To: Beierl, Mark mailto:mark.bei...@dell.com>>
Cc: Bob Monkman mailto:bob.monk...@arm.com>>; Måns 
Söderberg mailto:mans.soderb...@enea.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Hello, again, Bob.

Is Armband running Ubuntu on the servers?  How did you get docker on there to 
run Functest?  We have access to a Cavium ARM based server and I want to make 
sure we are running the correct architecture.  I see instructions [1] that say 
to use [arch=armhf].  Will that work?

[1] 
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/#install-using-the-repository

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 Jul 28, 2017, at 09:41, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:

Thanks very much, Bob.

I should not need any cycles for help.  I'm not looking at a test run or 
developing new functionality.  All I really need to do is verify the docker 
build process and that the packages StorPerf depends on are available in the 
Alpine docker base.  So, more of a packaging exercise if that is a good way to 
describe it?

This is not an immediate activity, so no rush :)

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 Jul 27, 2017, at 21:13, Bob Monkman 
mailto:bob.monk...@arm.com>> wrote:

Thanks, Mark,
  I think the Armband team can help here. We have no cycles to help 
too much but we apparently have a small and full pod available (latter for a 
short time only) and we would need to see if we can get some Pharos credentials 
for you.

I have copied Mans who recently provided me with a set of VPN credentials. Or 
maybe Alex has a difference suggestion.

Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, July 27, 2017 6:07 PM
To: Bob Monkman mailto:bob.monk...@arm.com>>
Cc: David McBride 
mailto

Re: [opnfv-tech-discuss] [armband] Resource for development or testing

[Alexandru Avadanii]

Hi,
It looks like 17.06 CE is not officially out for ARMV8 yet, but there is a test 
binary at [1]. To use it with apt:
„deb [arch=arm64] https://download.docker.com/linux/ubuntu/ xenial test”
$ sudo apt-get install docker-ce

You can always try building from sources, but you might run into unexpected 
issues.
Btw, for Alpine/Ubuntu AArch64 docker base images, check out [2].

Alex

[1] https://download.docker.com/linux/ubuntu/dists/xenial/pool/test/arm64/
[2] https://hub.docker.com/u/arm64v8/ (used to be 
https://hub.docker.com/u/aarch64)


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, August 03, 2017 11:43 PM
To: Alexandru Avadanii; Taseer Ahmed
Cc: Bob Monkman; opnfv-tech-discuss@lists.opnfv.org; Alexandru Nemes
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Hello,

I think the docker version is too old for the build and docker-compose that I 
am using in StorPerf.  We currently require docker ce 17.06 to do multi-stage 
builds.

I have looped in Taseer (cc) as he is the one who has access to the Cavium ARM 
server.

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 Aug 3, 2017, at 16:28, Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:

Hi, Mark,
armhf won’t work, that is ARMv7, while we target ARMv8 (aarch64). The 
appropiate arch qualifier would be (for a Debian system like Ubuntu):
[arch=arm64]
But unless you are trying to do something extremely specific, that should not 
be needed, stock Ubuntu 16.04 already has a working docker for AArch64.

Btw, we are already building a few AArch64 Docker images, for functest [1], 
dovetail [2], soon yardstick etc.
The releng bit handling AArch64 can be found at [3] and works like this:
-  If DOCKERFILE parameter is passed to build job (in format 
„Dockerfile.aarch64” usually) and the file exists in the git repo, it will be 
used instead of default „Dockerfile”;
-  If DOCKERFILE parameter is passed (same „Dockerfile.aarch64”), but 
it doesn’t exist, releng will look for „Dockerfile.aarch64.patch”, apply that 
on top of „Dockerfile”, then use it;

The builder machine handling [2] and [3] is arm-build3 [4], an AArch64 VM on a 
ThunderX node.
It runs Ubuntu Xenial (16.04.2), and docker was installed from Ubuntu repos 
using apt (no custom repository was necessary afaik).

CC’in Alex Nemes from our side, as he recently worked on this and might have 
things fresh in his memory for further queries.

BR,
Alex

[1] 
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-arm-push-master/
[2] https://build.opnfv.org/ci/job/dovetail-docker-build-arm-push-master/
[3] 
https://github.com/opnfv/releng/blob/master/jjb/releng/opnfv-docker.sh#L58-L71
[4] https://build.opnfv.org/ci/computer/arm-build3/builds


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bob Monkman
Sent: Thursday, August 03, 2017 11:11 PM
To: Beierl, Mark
Cc: Måns Söderberg; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Mark,
  I am sorry that am not close to the technical mechanisms by which 
this works. I have directly copied a couple of Armbanders to see if they can 
provide a quick answer. The caveat is that a number of developers may be on 
holiday and the remaining team is pressed trying to create bare metal deploys 
for MCP with the new MS5 just 8 days away. Sorry, bad timing but let’s see if 
something can be provided for a pointer.

Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, August 3, 2017 1:03 PM
To: Beierl, Mark mailto:mark.bei...@dell.com>>
Cc: Bob Monkman mailto:bob.monk...@arm.com>>; Måns 
Söderberg mailto:mans.soderb...@enea.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Hello, again, Bob.

Is Armband running Ubuntu on the servers?  How did you get docker on there to 
run Functest?  We have access to a Cavium ARM based server and I want to make 
sure we are running the correct architecture.  I see instructions [1] that say 
to use [arch=armhf].  Will that work?

[1] 
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/#install-using-the-repository

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 Jul 28, 2017, at 09:41, Beierl, Mark 
mailto:mark.bei...@dell.c

Re: [opnfv-tech-discuss] [armband] Resource for development or testing

[Alexandru Avadanii]

Hi, Mark,
If we want to go this route, we will have to get all projects having docker 
builds to agree to this change, and it will require renaming quite a lot of 
tags.
I support the idea, but I wonder what the rest of the community thinks about it.

BR,
Alex


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Friday, August 04, 2017 5:43 PM
To: Alexandru Avadanii
Cc: Taseer Ahmed; Bob Monkman; opnfv-tech-discuss@lists.opnfv.org; Alexandru 
Nemes; Cristina Pauna; Charalampos Kominos
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Hello,

I also see there is discrepancy in the naming conventions used.  For example, 
the multiarch Alpine image puts the architecture into the tag like so [1]:

multiarch/alpine:x86-latest-stable
multiarch/alpine:aarch64-latest-stable

Vs. in OPNFV we use the image name to specify the architecture [2], [3]:

opnfv/functest:latest
opnfv/functest_aarch64:latest

I think the way multiarch/alpine does it is preferable so that there is only 
one repository name, but I think we need to discuss this across the different 
projects and releng to make these changes.

[1] https://hub.docker.com/r/multiarch/alpine/tags/
[2] https://hub.docker.com/r/opnfv/functest/
[3] https://hub.docker.com/r/opnfv/functest_aarch64/tags/

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 Aug 3, 2017, at 16:59, Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:

Hi,
It looks like 17.06 CE is not officially out for ARMV8 yet, but there is a test 
binary at [1]. To use it with apt:
„deb [arch=arm64] https://download.docker.com/linux/ubuntu/ xenial test”
$ sudo apt-get install docker-ce

You can always try building from sources, but you might run into unexpected 
issues.
Btw, for Alpine/Ubuntu AArch64 docker base images, check out [2].

Alex

[1] https://download.docker.com/linux/ubuntu/dists/xenial/pool/test/arm64/
[2] https://hub.docker.com/u/arm64v8/ (used to be 
https://hub.docker.com/u/aarch64)


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, August 03, 2017 11:43 PM
To: Alexandru Avadanii; Taseer Ahmed
Cc: Bob Monkman; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Alexandru Nemes
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Hello,

I think the docker version is too old for the build and docker-compose that I 
am using in StorPerf.  We currently require docker ce 17.06 to do multi-stage 
builds.

I have looped in Taseer (cc) as he is the one who has access to the Cavium ARM 
server.

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 Aug 3, 2017, at 16:28, Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:

Hi, Mark,
armhf won’t work, that is ARMv7, while we target ARMv8 (aarch64). The 
appropiate arch qualifier would be (for a Debian system like Ubuntu):
[arch=arm64]
But unless you are trying to do something extremely specific, that should not 
be needed, stock Ubuntu 16.04 already has a working docker for AArch64.

Btw, we are already building a few AArch64 Docker images, for functest [1], 
dovetail [2], soon yardstick etc.
The releng bit handling AArch64 can be found at [3] and works like this:
-  If DOCKERFILE parameter is passed to build job (in format 
„Dockerfile.aarch64” usually) and the file exists in the git repo, it will be 
used instead of default „Dockerfile”;
-  If DOCKERFILE parameter is passed (same „Dockerfile.aarch64”), but 
it doesn’t exist, releng will look for „Dockerfile.aarch64.patch”, apply that 
on top of „Dockerfile”, then use it;

The builder machine handling [2] and [3] is arm-build3 [4], an AArch64 VM on a 
ThunderX node.
It runs Ubuntu Xenial (16.04.2), and docker was installed from Ubuntu repos 
using apt (no custom repository was necessary afaik).

CC’in Alex Nemes from our side, as he recently worked on this and might have 
things fresh in his memory for further queries.

BR,
Alex

[1] 
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-arm-push-master/
[2] https://build.opnfv.org/ci/job/dovetail-docker-build-arm-push-master/
[3] 
https://github.com/opnfv/releng/blob/master/jjb/releng/opnfv-docker.sh#L58-L71
[4] https://build.opnfv.org/ci/computer/arm-build3/builds


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bob Monkman
Sent: Thursday, August 03, 2017 11:11 PM
To: Beierl, Mark
Cc: Måns Söderberg; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [armband] Resource for development or testing

Mark,
  I am sorry that am not close 

[opnfv-tech-discuss] Jump server common configuration for PXE/admin network - questions

[Alexandru Avadanii]

Hi,
I am looking at integrating Fuel@OPNFV/MCP with our OPNFV baremetal PODs (both 
x86_64 and aarch64).
Right now I am playing with MaaS and its network configuration.

The old Fuel@OPNFV was relying on the jump server's "pxebr" bridge interface, 
which is supposed to reach all baremetal nodes, for PXE-booting purposes.
If we want to reuse this interface as-is, we need to make sure "pxebr" will 
also have internet access, one way or another, on all PODs supporting 
Fuel@OPNFV deploys.

Afaik, each POD is configured differently, the customizations ranging from 
different IP/subnets to totally different layouts.
E.g. Armband used to have 2 network attached to its old Fuel Master node:
- 1 x PXE/admin - no external configuration, TFTP/DNS/DHCP was provided by Fuel 
Master node - hooked up to a port in our dumb version of "pxebr";
- 1 x public - external gateway, no external DHCP - hooked up to jump server's 
"public" bridge;
However, x86 PODs running Fuel were configured to use only:
- 1 x PXE/admin interface, hooked to "pxebr", which also had external internet 
access (NAT-ed?), but no external DHCP/DNS in order not to conflict with the 
ones provided by Fuel Master;

Going forward, I would like to align the new network requirements between our 
PODs and the rest of the OPNFV pool, so here are some questions:
- is PXE/admin interface (connected to "pxebr") supposed to always have 
internet access? If so, how? NAT on the jump server? Or external gateway? Can 
we assume this is going to happen for all PODs, or should we support different 
configurations as well?
- is LOM (the network used to access baremetal nodes IPMI interfaces) routed to 
PXE/admin or public, or is it a separate, independent network? This seems to 
vary from POD to POD.
- is LOM expected to have external DNS/DHCP, or is this up to the team 
responsible for POD config?

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

Re: [opnfv-tech-discuss] [yardstick] yardstick env prepare - chroot error

[Alexandru Avadanii]

Hi,
On the host machine (where you run docker), you probably don’t have the binfmt 
configuration for executing AArch64 binaries inside the docker container 
chroots with qemu-user-static.
The fix should be as simple as (on the host machine):
$ apt-get install qemu-user-static

BR,
Alex


From: chenjiankun [mailto:chenjiank...@huawei.com]
Sent: Thursday, August 24, 2017 12:24 PM
To: vven...@codeaurora.org
Cc: opnfv-tech-discuss@lists.opnfv.org; Alexandru Avadanii
Subject: RE: [opnfv-tech-discuss] [yardstick] yardstick env prepare - chroot 
error

Hi

Is there yardstick-image in /home/opnfv/images?

Anyway, if you are compiling for arm pod, yardstick-image should be rebuild.
Since I am not familiar with arm, maybe you can check with Alexandru Avadanii.

Regards,
Jack Chan

发件人: vven...@codeaurora.org<mailto:vven...@codeaurora.org> 
[mailto:vven...@codeaurora.org]
发送时间: 2017年8月24日 16:48
收件人: chenjiankun; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [yardstick] yardstick env prepare - chroot error

Hi Jack,
Thanks for the reply. I see below images in /home/opnfv/images directory. I am 
compiling for arm pod. Please suggest.

root@57db44f0c4b5:/home/opnfv/images# ls
cirros-0.3.5-x86_64-disk.img  xenial-server-cloudimg-amd64-disk1.img
root@57db44f0c4b5:/home/opnfv/images#

But I followed the steps you suggested, still I see the same issue…’Image build 
failed with 126’ because of chroot error

Thanks
-Venkat


From: chenjiankun [mailto:chenjiank...@huawei.com]
Sent: Thursday, August 24, 2017 12:04 PM
To: vven...@codeaurora.org<mailto:vven...@codeaurora.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: RE: [opnfv-tech-discuss] [yardstick] yardstick env prepare - chroot 
error

Hi,

It seems there are something wrong when you build yardstick-image.
Maybe you can download yardstick-image directly:
 cd /home/opnfv/images
 wget http://artifacts.opnfv.org/yardstick/images/yardstick-image.img

Then execute yardstick env prepare again.
Hope that would work for you.

Regards,
Jack Chan

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 
vven...@codeaurora.org<mailto:vven...@codeaurora.org>
发送时间: 2017年8月24日 13:26
收件人: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: [opnfv-tech-discuss] [yardstick] yardstick env prepare - chroot error


Hi,

I am setting up yardstick using docker on Danube 3.0 and followed the 
instructions as per 
http://docs.opnfv.org/en/stable-danube/submodules/yardstick/docs/testing/user/userguide/04-installation.html
Setup the env variables in /etc/yardstick/openstack.creds inside docker with 
the below mentioned parameters.
Next when I setup “yardstick env prepare” though it says [Finished] without 
prompting any error, I see the error as below in /var/log/yardstick/uwsgi.log 
(Also attached ). Request someone to help on this.

+ chroot /mnt/yardstick /ubuntu-server-cloudimg-modify.sh 10.222.196.22
chroot: failed to run command '/ubuntu-server-cloudimg-modify.sh': Exec format 
error
+ error_trap
+ local rc=126



#!/bin/sh
export OS_NO_CACHE='true'
export OS_TENANT_NAME='admin'
export OS_PROJECT_NAME='admin'
export OS_USERNAME='admin'
export OS_PASSWORD='admin'
export OS_AUTH_URL='http://192.168.0.2:5000/v3'
export OS_IDENTITY_API_VERSION=3
export OS_DEFAULT_DOMAIN='default'
export OS_USER_DOMAIN_NAME='Default'
export OS_PROJECT_DOMAIN_NAME='Default'
export OS_AUTH_STRATEGY='keystone'
export OS_REGION_NAME='RegionOne'
export CINDER_ENDPOINT_TYPE='internalURL'
export GLANCE_ENDPOINT_TYPE='internalURL'
export KEYSTONE_ENDPOINT_TYPE='internalURL'
export NOVA_ENDPOINT_TYPE='internalURL'
export NEUTRON_ENDPOINT_TYPE='internalURL'
export OS_ENDPOINT_TYPE='internalURL'
export MURANO_REPO_URL='http://storage.apps.openstack.org/'
export MURANO_PACKAGES_SERVICE='glance'
export EXTERNAL_NETWORK=’admin_floating_net’

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

Re: [opnfv-tech-discuss] OPNFV Danube - Fuel Deployment failing

[Alexandru Avadanii]

Hi,
Since only one of the two nodes is failing this check, this does not look like 
an infra issue (internet access to the nodes), but rather a configuration issue.
Is the node with MAC ending in "e8:00" the compute by any chance? Does the 
compute have the public network assigned and properly configured? There should 
be a checkbox somewhere in env settings for assigning the public network to all 
nodes.

BR,
Alex


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
Lingala
Sent: Wednesday, August 30, 2017 8:48 AM
To: opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opnfv.org
Subject: [opnfv-tech-discuss] OPNFV Danube - Fuel Deployment failing

Hi,
I am using OPNFV Danube release. I downloaded Fuel ISO from the below location:
http://artifacts.opnfv.org/fuel/danube/opnfv-danube.3.0.iso

And, I am trying to deploy OpenStack deployment with One OpenStack Controller 
and OpenStack Compute.
In the 'Connectivity Check' of Fuel Network Settings, I am getting the 
following error:

Verification failed.
Repo availability verification using public network failed on following nodes 
Untitled (e8:00).
Following repos are not available - 
http://archive.ubuntu.com/ubuntu/.
Check your public network settings and availability of the repositories from 
public network. Please examine nailgun and astute logs for additional details.

But, both the Controller and Compute nodes, are able to connect to internet.
When I check the nailgun logs, I found the following:

2017-08-30 05:33:51

INFO

[1576] Casting message to Nailgun: 
{"method"=>"check_repositories_with_setup_resp", "args"=> 
{"task_uuid"=>"97a9f809-2142-4338-9621-f3417defebc6", "status"=>"ready", 
"progress"=>100, "nodes"=> 
[{:out=>{"failed_urls"=>["http://archive.ubuntu.com/ubuntu/"]},
 :err=> "Unexpected failure.\nTraceback (most recent call last):\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/network.py\", line 218, 
in manage_network\n yield\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 76, 
in take_action\n CheckUrlsWithSetup, self).take_action(pa)\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 57, 
in take_action\n raise e\nUrlNotAvailable: {\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n2017-08-30
 05:33:50 ERROR (network) Unexpected failure.\nTraceback (most recent call 
last):\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/network.py\", line 218, 
in manage_network\n yield\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 76, 
in take_action\n CheckUrlsWithSetup, self).take_action(pa)\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 57, 
in take_action\n raise e\nUrlNotAvailable: {\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n{\"failed_urls\":
 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n2017-08-30
 05:33:50 ERROR (app) {\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/

Re: [opnfv-tech-discuss] StorPerf multi-arch verify includes ARM

[Alexandru Avadanii]

Hi,
Great work, Mark and Fatih, I really like the way you built the verify jobs!
I would like to propose this design for other multiarch projects as well (e.g. 
functest, yardstick, dovetail, doctor etc.). We will try to submit some patches 
soon.

Congrats to the Storperf team for one of the swiftest multiarch transitions so 
far (the AArch64 build worked with just one argument change).

BR,
Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Beierl, Mark
Sent: Friday, September 01, 2017 11:44 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] StorPerf multi-arch verify includes ARM

Hello,

I would like to extend a big thank you to Alex Avadanii and Fatih Degirmenci 
(and probably others too!) for their help in reaching this important milestone 
in StorPerf.  New patches now go through 3 verification jobs prior to Jenkins 
giving a +1:

1) Unit tests, python formatting and code coverage are run
2) Docker containers are built locally, started and checked for basic health on 
x86_64
3) Docker containers are built locally, started and checked for basic health on 
ARM aarch64!

Is it this last step that I am most excited about.  It validates that the 
docker containers build and can start successfully on ARM, and this will be 
done automatically for each Gerrit patchset going forward.  Note: this does not 
yet mean that docker images for StorPerf are built and published to Dockerhub 
for ARM.  That is for another day...

[1] 
https://build.opnfv.org/ci/job/storperf-verify-master/

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +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

Re: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Alexandru Avadanii]

Hi, Srikanth,
I'm glad to hear about new AArch64 hardware joining OPNFV.

First, note that Pharos specs require 5 nodes, which depending on the scenario 
can be used as 3 controllers + 2 computes, or 1 controller + computes.
This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore, this 
is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but it is out 
of our current scope.
To add some complexity to that, we have the additional jump server host, which 
used to be x86 up to and including the Danube release cycle; starting with the 
E release, Armband only support all-AArch64 PODs, including the jump host.

Also note that the old Fuel (used up to and including Danube) was replaced by 
the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own means a 
lot of changes in the way we build and provision the OS images (bootstrap and 
final image) on the AArch64 nodes.
Starting with the E release, there is no more bootstrap building, all images 
(Ubuntu Xenial) are fetched from official Ubuntu Cloud Archive (UCA) repos and 
used as-is.

As for old bootstrap building, x86 instructions still apply [1], with only one 
extra arg required (--target_arch=arm64).

To summarize, I recommend looking into the current Armband/Fuel codebase 
(master branch) and prepare for using MCP-based Fuel instead of the old Danube 
codebase.
To add a lab in OPNFV, you will need 6 x AArch64 nodes (5 for the cluster and 
one for the jump host).

BR,
Alex

[1] 
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
Lingala
Sent: Thursday, September 07, 2017 8:35 PM
To: opnfv-us...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

Hi,
We want to setup Pharos lab for ARM band machines. For that, I am using OPNFV 
Danube 3.0 release (Fuel ISO).
Is it possible to deploy an OpenStack setup with x86 machine as OS Controller 
and ARM machine as OS Compute node?
And also, can anyone give me some reference links to build a bootstrap image 
(for Fuel deployment) for baremetal ARM machines?

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

Re: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Alexandru Avadanii]

Hi,
That is correct, everything is now AArch64 in our PODs.

BR,
Alex


From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, September 08, 2017 11:48 AM
To: Alexandru Avadanii; opnfv-us...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi; 
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

Hi Alex,
Thanks for the details.
I viewed the following link for reference:
https://wiki.opnfv.org/display/pharos/Enea+Hosting<https://url10.mailanyone.net/v1/?m=1dqExj-0005uE-41&i=57e1b682&c=2_90BZQ1-RysgNt1AmHMojKH2LHu4JvrSPemJS6YkprgFmG8q-jJlEMYA4CZikrc8-R03obAumDs803BItktKdmDIr3C55G2KVSIp_QGTTHWTA1S4Vmt7WW_Wt4-85FzF9FhIOGOnJhGAYMKmfMkJQcvEi-WMB2SRG5EgU0mktznhy_1bVqcjJdS7vnkfeqilYivXeMCcCUFvI8dqUMVXEnwBEhNp13pdCNYfv7j0SdWJUxpJyWjFSnUzj-BIW8GPXN4uCWspaUrKqm12rIBwA>

So, in the current ENEA Pharos lab, you are using ARM based machines as OS 
Controller nodes, Compute nodes and even Jump Host node. Not using any hybrid 
POD (with combination of x86 and ARM machines as nodes). Right?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 12:49 AM
To: Srikanth Lingala 
mailto:srikanth.ling...@nxp.com>>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband mailto:svc-armb...@enea.com>>; Bob 
Monkman mailto:bob.monk...@arm.com>>; Shai Tsur 
mailto:shai.t...@arm.com>>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi, Srikanth,
I'm glad to hear about new AArch64 hardware joining OPNFV.

First, note that Pharos specs require 5 nodes, which depending on the scenario 
can be used as 3 controllers + 2 computes, or 1 controller + computes.
This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore, this 
is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but it is out 
of our current scope.
To add some complexity to that, we have the additional jump server host, which 
used to be x86 up to and including the Danube release cycle; starting with the 
E release, Armband only support all-AArch64 PODs, including the jump host.

Also note that the old Fuel (used up to and including Danube) was replaced by 
the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own means a 
lot of changes in the way we build and provision the OS images (bootstrap and 
final image) on the AArch64 nodes.
Starting with the E release, there is no more bootstrap building, all images 
(Ubuntu Xenial) are fetched from official Ubuntu Cloud Archive (UCA) repos and 
used as-is.

As for old bootstrap building, x86 instructions still apply [1], with only one 
extra arg required (--target_arch=arm64).

To summarize, I recommend looking into the current Armband/Fuel codebase 
(master branch) and prepare for using MCP-based Fuel instead of the old Danube 
codebase.
To add a lab in OPNFV, you will need 6 x AArch64 nodes (5 for the cluster and 
one for the jump host).

BR,
Alex

[1] 
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html<https://url10.mailanyone.net/v1/?m=1dqExj-0005uE-41&i=57e1b682&c=QqYvZQC5560IPDtsPgdMeQQDvqEpjhyR0UZGIV7tunq-se0YCPSP6xxlDi9wG8__VazhOirYCoOetNpYw1zYeVUU37jndntzaFMWxDK0HxyAEOvTwQl303qQJvW6LiI8hQo73oBlWlaey0VdRgzt7zED7ggGAfYlAsO5lMGp6UZ5CsDVKOIeaGKcbe1PnBDPosO4fGpAlbKl6cmGI1CprYwKNm_6AYpz6bmcm_MH4EKvW1XJaTuuS38IKy1jzAmK8WOxuBjAGH_cWNfuJ3wQEUFMbstHAMFo2n_rquR2YBeNiJrobkN_nfbhospqyjqXdMTXG6-Lr2oVJhzFw-DnLg>


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
Lingala
Sent: Thursday, September 07, 2017 8:35 PM
To: opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

Hi,
We want to setup Pharos lab for ARM band machines. For that, I am using OPNFV 
Danube 3.0 release (Fuel ISO).
Is it possible to deploy an OpenStack setup with x86 machine as OS Controller 
and ARM machine as OS Compute node?
And also, can anyone give me some reference links to build a bootstrap image 
(for Fuel deployment) for baremetal ARM machines?

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

Re: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Alexandru Avadanii]

Hi,
We don't have such patches, nor do we plan to support old Fuel any more.
We actually don't intend to mix architectures for the new Fuel either, at least 
not in the near future.

If you want to support this use-case, you will have to implement it yourself.
I do think the new Fuel is friendlier to this scenario, but again, we never 
looked into it.

BR,
Alex


From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, September 08, 2017 4:21 PM
To: Alexandru Avadanii; opnfv-us...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi; 
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

OK...So, If I apply some patches to Fuel and rebuild Fuel ISO, can I deploy 
with mixed (x86 and aarch64) targets in Pharos POD?
If so, can you please point me to those patches?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 5:54 PM
To: Srikanth Lingala 
mailto:srikanth.ling...@nxp.com>>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband mailto:svc-armb...@enea.com>>; Bob 
Monkman mailto:bob.monk...@arm.com>>; Shai Tsur 
mailto:shai.t...@arm.com>>; Gorja Gorja 
mailto:prasad.go...@nxp.com>>; Trinath Somanchi 
mailto:trinath.soman...@nxp.com>>; Veera.reddy B 
mailto:veer...@nxp.com>>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi,
That is correct, everything is now AArch64 in our PODs.

BR,
Alex


From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, September 08, 2017 11:48 AM
To: Alexandru Avadanii; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi; 
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

Hi Alex,
Thanks for the details.
I viewed the following link for reference:
https://wiki.opnfv.org/display/pharos/Enea+Hosting<https://url10.mailanyone.net/v1/?m=1dqExj-0005uE-41&i=57e1b682&c=2_90BZQ1-RysgNt1AmHMojKH2LHu4JvrSPemJS6YkprgFmG8q-jJlEMYA4CZikrc8-R03obAumDs803BItktKdmDIr3C55G2KVSIp_QGTTHWTA1S4Vmt7WW_Wt4-85FzF9FhIOGOnJhGAYMKmfMkJQcvEi-WMB2SRG5EgU0mktznhy_1bVqcjJdS7vnkfeqilYivXeMCcCUFvI8dqUMVXEnwBEhNp13pdCNYfv7j0SdWJUxpJyWjFSnUzj-BIW8GPXN4uCWspaUrKqm12rIBwA>

So, in the current ENEA Pharos lab, you are using ARM based machines as OS 
Controller nodes, Compute nodes and even Jump Host node. Not using any hybrid 
POD (with combination of x86 and ARM machines as nodes). Right?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 12:49 AM
To: Srikanth Lingala 
mailto:srikanth.ling...@nxp.com>>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband mailto:svc-armb...@enea.com>>; Bob 
Monkman mailto:bob.monk...@arm.com>>; Shai Tsur 
mailto:shai.t...@arm.com>>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi, Srikanth,
I'm glad to hear about new AArch64 hardware joining OPNFV.

First, note that Pharos specs require 5 nodes, which depending on the scenario 
can be used as 3 controllers + 2 computes, or 1 controller + computes.
This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore, this 
is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but it is out 
of our current scope.
To add some complexity to that, we have the additional jump server host, which 
used to be x86 up to and including the Danube release cycle; starting with the 
E release, Armband only support all-AArch64 PODs, including the jump host.

Also note that the old Fuel (used up to and including Danube) was replaced by 
the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own means a 
lot of changes in the way we build and provision the OS images (bootstrap and 
final image) on the AArch64 nodes.
Starting with the E release, there is no more bootstrap building, all images 
(Ubuntu Xenial) are fetched from official Ubuntu Cloud Archive (UCA) repos and 
used as-is.

As for old bootstrap building, x86 instructions still apply [1], with only one 
extra arg required (--target_arch=arm64).

To summarize, I recommend looking into the current Armband/Fuel codebase 
(master branch) and prepare for using MCP-based Fuel instead of the old Danube 
codebase.
To add a lab in OPNFV, you will need 6 x AArch64 nodes (5 for the cluster and 
one for the jump host).

BR,
Alex

[1] 
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/bootstrap/boots

Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion

[Alexandru Avadanii]

Hi, Julien,
Afaik, both Armband Fuel@OPNFV and the soon-to-be-supported Apex on AArch64 
require an AArch64 jump host, at least with the current code base.
There is nothing stopping us from using a dual-jumphost (e.g. AArch64 for 
deploying, x86_64 for running test suites), but it adds complexity to the lab 
setup, and resource access control is harder (blocking access to the AArch64 
deploy while tests are runnning on x86_64 jumphost).

Added Bob and Shai to to-list.

BR,
Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Julien
Sent: Sunday, September 10, 2017 12:45 PM
To: Alec Hothan (ahothan); Cooper, Trevor; Beierl, Mark
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion

Hi Bob,

We are considering to setup a new ARM POD in our lab, and I plan only 5 blade 
servers with ARM CPU. I wonder I can still use a x86_64 server as the jumphost 
for this ARM POD. I don't expect it will be blocked by another arm server.

BR/Julien


Alec Hothan (ahothan) mailto:ahot...@cisco.com>>于2017年9月8日周五 
上午6:31写道：
Hi Trevor,

Thanks for getting back on this. I agree there is not much incentive to run 
TRex on ARM at this point.
ARM pods that want to do data plane benchmarking can use a HW traffic generator 
or run Trex on an Intel jump host.

Thanks

  Alec



From: "Cooper, Trevor" mailto:trevor.coo...@intel.com>>
Date: Thursday, September 7, 2017 at 2:37 PM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisco.com>>, 
"Beierl, Mark" mailto:mark.bei...@dell.com>>

Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>,
 "HU, BIN" mailto:bh5...@att.com>>, Raymond Paik 
mailto:rp...@linuxfoundation.org>>
Subject: RE: [opnfv-tech-discuss] Topics for Weekly Technical Discussion

Hi Alec …

VSPERF does not currently plan to support TREX on ARM … it’s not clear what the 
benefit of this work would be given that there are multiple traffic generator 
options. The Pharos POD specification doesn’t have any bearing on components 
such as traffic generators.  We have found that software traffic generators 
have a wide variety of capabilities.

/Trevor




From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Thursday, August 17, 2017 7:47 AM
To: Beierl, Mark mailto:mark.bei...@dell.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org; 
HU, BIN mailto:bh5...@att.com>>; Raymond Paik 
mailto:rp...@linuxfoundation.org>>; Cooper, Trevor 
mailto:trevor.coo...@intel.com>>
Subject: Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion

[+Trevor to get vsperf point of view]

Mark,

Adding ARM artifacts is probably not that much work for python apps, for C/C++ 
apps that use DPDK it can be a lot more work.
I just checked with the Trex team and as I suspected Trex is not available on 
ARM today. Somebody will have to try it out on an ARM server - meaning, it will 
take some work to compile Trex, link to DPDK and test it thoroughly to be on 
par with its x86 version – and a whole lot more people will have to maintain 
one more arch. The port might work right away or it might be pretty messy. I 
wonder if Trevor has a plan for TRex on ARM…
From what I can see, to run data plane performance test with TRex on ARM pod 
will require an x86 server until Trex is validated on ARM.

Thanks

Alec


From: "Beierl, Mark" mailto:mark.bei...@dell.com>>
Date: Thursday, August 17, 2017 at 6:21 AM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>,
 "HU, BIN" mailto:bh5...@att.com>>, Raymond Paik 
mailto:rp...@linuxfoundation.org>>
Subject: Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion

Alec,

It is completely up to you how you want to structure your project and your 
deliverables.  If you don't want the extra hassle of supporting ARM, then don't.

As for my project and the other ones that happen to support ARM, we will 
continue this discussion to see what makes sense.

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 Aug 16, 2017, at 21:02, HU, BIN mailto:bh5...@att.com>> 
wrote:

Alec,

Thank you for your input, and letting know you won’t be able to make the 
meeting tomorrow.

Mark,

Do you still want to discuss in the meeting tomorrow? (my only concern is the 
attendance, which  may not warrant an effective live discussion.

Or do you think the discussion on mailing list should be good enough?

If we all think the discussion on mailing list is good enough, we don’t need to 
discuss it in the meeting tomorrow.

Thanks
Bin

From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Wednesday, August 16, 2017 5:47 PM
To

Re: [opnfv-tech-discuss] [release][euphrates] stable branch window

[Alexandru Avadanii]

Hi,
How about tagging releng, without branching it?

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: Monday, September 11, 2017 7:51 AM
> To: David McBride
> Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
> Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window
> 
> Hello,
> 
> Could you please confirm that no stable/euphrates branch will be created for
> releng again?
> Else we are obliged to select a specific git commit id to build our Functest
> stable containers which is not the best way.
> I precise Functest depends on the opnfv python package which is hosted by
> releng (https://git.opnfv.org/releng/tree/modules).
> 
> Cédric
> 
> 2017-09-09 1:24 GMT+02:00 David McBride :
> > Reminder...
> >
> > The stable branch window closes as of MS7, one week from today, on
> > September
> > 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready
> > to branch.  Aric will branch any projects that have not already been
> > branched on Sept 15.
> >
> > Let me know if you have any questions.
> >
> > David
> >
> > On Tue, Aug 29, 2017 at 3:23 PM, David McBride
> >  wrote:
> >>
> >> Team,
> >>
> >> As you know, MS6 was this past Friday, Aug 25.  In addition to the
> >> requirements associated with MS6, this milestone also marks the
> >> opening of the stable branch window, which subsequently ends with MS7 on
> Sept 15.
> >>
> >> This means that PTLs may request to branch their project any time
> >> before Sept 15.  Note that I erroneously told the release meeting
> >> this morning that PTLs may create their own branch.  That's not the
> >> case.  Instead, please contact Aric (copied) and request that he create the
> branch for you.
> >>
> >> Also, as a reminder, we have changed the version number format as of
> >> the Euphrates release.
> >>
> >> 5.0.0 - Euphrates initial release version
> >> 5.1.0 - Euphrates SR1
> >> 5.2.0 - Euphrates SR2
> >>
> >> Let me know if you have any questions.
> >>
> >> David
> >>
> >> --
> >> David McBride
> >> Release Manager, OPNFV
> >> Mobile: +1.805.276.8018
> >> Email/Google Talk: dmcbr...@linuxfoundation.org
> >> Skype: davidjmcbride1
> >> IRC: dmcbride
> >
> >
> >
> >
> > --
> > David McBride
> > Release Manager, OPNFV
> > Mobile: +1.805.276.8018
> > Email/Google Talk: dmcbr...@linuxfoundation.org
> > Skype: davidjmcbride1
> > IRC: dmcbride
> >
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> >
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest test results dashboard

[Alexandru Avadanii]

Hi,
Fuel and Armband projects renamed the ODL-L3 scenario to simply ODL, and 
dropped the ODL-L2 scenarios, as described in [1].
I noticed that the Functest results dashboard pages [2, 3] still use the old 
naming scheme, although the new scenario is also listed.
Would it be possible to cleanup obsolete scenarios?

Thank you,
Alex

[1] https://jira.opnfv.org/browse/FUEL-279
[2] http://testresults.opnfv.org/reporting/master/functest/status-f...@x86.html
[3] 
http://testresults.opnfv.org/reporting/master/functest/status-f...@aarch64.html

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

Re: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest test results dashboard

[Alexandru Avadanii]

Hi, Venkat,
It depends on what installer branch you are using.
If you use Fuel Danube, the old naming should be used.
For Fuel master, the new naming should be used, but as Kubi pointed out, this 
might still need some work.

BR,
Alex

> -Original Message-
> From: Gaoliang (kubi) [mailto:jean.gaoli...@huawei.com]
> Sent: Wednesday, September 13, 2017 9:59 AM
> To: Ross Brattain
> Cc: opnfv-tech-discuss@lists.opnfv.org; vven...@codeaurora.org; Alexandru
> Avadanii; 'RICHOMME Morgan IMT/OLN'
> Subject: Re: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in
> Functest test results dashboard
> 
> Hi Ross,
> 
> Venkat's email reminder me that there are still some work for ODL scenario
> rename.
> 
> I saw you have upload a patch which is "add opnfv_os-odl-nofeature-
> noha_daily.yaml [1] for odl_l3 to odl rename"
> 
> And It seems that we also need to add opnfv_os-odl-nofeature-ha_daily.yaml to
> Yardstick repo for odl_l3 to odl rename .
> 
> [1] https://gerrit.opnfv.org/gerrit/#/c/40895/
> 
> Regards,
> 
> Kubi
> 
> -邮件原件-
> 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
> boun...@lists.opnfv.org] 代表 vven...@codeaurora.org
> 发送时间: 2017年9月13日 13:52
> 收件人: 'Alexandru Avadanii' ; 'RICHOMME
> Morgan IMT/OLN' 
> 抄送: opnfv-tech-discuss@lists.opnfv.org
> 主题: Re: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest
> test results dashboard
> 
> Hi Alex,
> While your question is answered,
> Request you to clarify :  This is also exported to Yardstick, Functest 
> accordingly.
> I should feed there as os-odl-nofeature-ha say as an example or still 
> os-odl_l3-
> nofeature-ha ??
> 
> Thanks
> -Venkat
> 
> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alexandru
> Avadanii
> Sent: Wednesday, September 13, 2017 4:50 AM
> To: RICHOMME Morgan IMT/OLN 
> Cc: opnfv-tech-discuss@lists.opnfv.org
> Subject: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest
> test results dashboard
> 
> Hi,
> Fuel and Armband projects renamed the ODL-L3 scenario to simply ODL, and
> dropped the ODL-L2 scenarios, as described in [1].
> I noticed that the Functest results dashboard pages [2, 3] still use the old
> naming scheme, although the new scenario is also listed.
> Would it be possible to cleanup obsolete scenarios?
> 
> Thank you,
> Alex
> 
> [1] https://jira.opnfv.org/browse/FUEL-279
> [2]
> http://testresults.opnfv.org/reporting/master/functest/status-f...@x86.html
> [3]
> http://testresults.opnfv.org/reporting/master/functest/status-fuel@aarch64.h
> tml
> 
> ___
> 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] StorPerf ARM images available

[Alexandru Avadanii]

Hi, Mark,
Thank you for the kind words :) and congratulations to all the people involved 
for proposing a clean multiarch design!

We will try to slowly propose this design choice (single repo, multiarch tags) 
to other test projects as well.

Looking forward to adding storperf to our daily jobs.

BR,
Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Beierl, Mark
Sent: Friday, September 15, 2017 6:39 PM
To: opnfv-tech-discuss@lists.opnfv.org
Cc: trevor Bramwell
Subject: [opnfv-tech-discuss] StorPerf ARM images available

Hello,

It is with immense pleasure that I would like to announce that with a great 
community effort, StorPerf now has published its Docker images for aarch64 as 
well as x86_64.  This is done using the same docker file, and passing the 
Architecture in as a build argument.  I want to thank the following people for 
their help:

Alex Avadanii for his tireless and flexible hours collaborating on how to 
change the Releng JJBs and scripts so that we don't interfere with the existing 
docker jobs.
Fatih Degirmenci, Trevor Bramwell and Aric Gardener for being so responsive 
when a Releng merge did have an unintended side effect and helping out.
Shrenik Jain for laying the groundwork in StorPerf container breakdown and 
migration to Alpine that made this change possible.

I am sure there are others who I forgot to mention, as this was truly a cross 
project, community effort.  To the whole OPNFV community, I extend my thanks.  
This was a significant accomplishment and I am grateful to all!  My next goal 
is to get StorPerf daily running on ARM/Fuel :)

https://hub.docker.com/r/opnfv/storperf-master/tags/
https://hub.docker.com/r/opnfv/storperf-httpfrontend/tags/
https://hub.docker.com/r/opnfv/storperf-graphite/tags/
https://hub.docker.com/r/opnfv/storperf-swaggerui/tags/
https://hub.docker.com/r/opnfv/storperf-reporting/tags/

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +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

Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi,
Fuel and Armband teams are working on the final bits for switching to PDF.
We proposed a minor improvement to the parsing mechanism [1]; a PDF file for 
our arm-pod5 is already in place [2]; lf-pod2 PDF will land shortly (we have an 
internal draft we are currently revising), and of course an installer adapter 
that is still being tested before the final switch [3] (will be moved to 
securedlab when ready).

Overall, I think the PDF is a great idea, and we should switch to it as soon as 
possible.
There are still some minor implemention issues on the installer side (e.g. 
trying to determine the jump host bridge names in case they already exist), but 
I will bring that up after I try a few more things, as I think the current PDF 
format is enough to handle all of this, with some minor installer-specific 
parsing.

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/42075/
[2] https://gerrit.opnfv.org/gerrit/#/c/41005/
[3] 
https://gerrit.opnfv.org/gerrit/#/c/41855/8/mcp/reclass/classes/cluster/all-mcp-ocata-common/opnfv/pdf/pod-config.yml.j2


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Julien
Sent: Thursday, September 14, 2017 7:21 PM
To: hu.zhiji...@zte.com.cn; chig...@huawei.com; bob.monk...@arm.com; 
mpolenc...@mirantis.com; tro...@redhat.com; narinder.gu...@canonical.com; 
jack.mor...@intel.com; agard...@linuxfoundation.org; 
fatih.degirme...@ericsson.com; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?

Hi, dear installer PTLs,

In this week's infra WG meeting, we discuss whether PDF(Pod Description File) 
can be released or not. We want to know current status of each installer 
project. As I can find in the wiki, all the installer projects  in OPNFV, 
including Apex, Compass, Daisy, Fuel/MCP and Joid will attend Euphrates 
release[1].

Currently, some PDF files have been submitted by pharos lab owners including 
Ericsson, Intel, LF and ZTE. Several labs' PDF files including ARM, BII, Huawei 
and Nokia are in review[2]. Aric has finished some installer transfer script in 
scuredlab repo[3] using jinja template.

This feature is planned to released in Euphrates. If it is not supported yet, 
can you share us current status and your plan.

[1]: 
https://wiki.opnfv.org/display/SWREL/Euphrates+Scenario+Status
[2]: 
https://gerrit.opnfv.org/gerrit/#/q/project:+securedlab+status:open
[3]: 
https://gerrit.opnfv.org/gerrit/#/admin/projects/securedlab

BR/Julien

___
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][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi,
In today’s Infra meeting, we had very little time to discuss the specifics of 
using PDF in real-life use-cases, so I am continuing the discussion here.
Afaik, there are at least 2 installer projects actively working on using PDF:

1.   Fuel/Armband based on MCP – Guillermo H. and I have submitted some 
patches covering PDFs for our PODs, as well as minor improvements to PDF 
parsing, and an installer adapter (draft);

2.   Openstack Ansible (OSA) – David B. has submitted a few patches, 
touching the PDF design and possible extensions;

Both installers work well with PDF as an input, but we hit a few design quirks 
that I want to elaborate on:

1.   PDF tooling and installer adapters should be publicly available, which 
we decided today to move to pharos git repo (see [1]), eventually split that 
repo into smaller repos;

2.   PDF alone is not enough to describe installer-specific configuration 
that is scenario-indepedent, e.g.:

a.   Both David and I noticed there is no sane way to map POD networks to 
bridge names on the jump host;

b.  David proposed a new section should be added to describe this mapping; 
I found a way around it for Fuel, but it requires each bridge to have an IP 
addr in each subnet it covers [2];

c.   For OSA, there are other things that can’t be described by PDF, like 
possible node roles (controller, compute, network etc.) which Fuel solves by 
assuming all nodes are the same, and the first 3 nodes in PDF should be 
controllers – this works, but it’s not the best approach for PODs with 
different blades;

Since SDF is not yet available, we want to propose a mechanism that allows 
describing this installer-specific configuration.
David proposed in [3] a set of changes on top of PDF: removing some useless 
entries from PDF, as well as adding a new companion file, the IDF (Installer 
Descriptor File).

My understanding is that changing the PDF to include the IDF in its 
specification is not a good long-term action, or at least that’s what I got 
from today’s meeting.
Although I agree on mixing installer data with PDF is not a good long-term 
solution, we would like to fiind an acceptable solution for the short term 
(until SDF lands).

So, my proposal is to make IDF a separate thing. Design-wise, everything in PDF 
is good to go as it is right now. Fuel (MCP) and Armband projects can easily 
consume the PDF without and IDF (provided we have an IP in the right subnet for 
each jump host bridge, but even that is optional and can be overriden via 
 via Jenkins slave parameters / env vars).
Implementation-wise, David’s patch should be taken as-in. The IDF file (when 
required) will be in the same location the PDF is, with a derived name like 
„podX-idf.yaml”. The syntax and structure will be installer-specific, so 
there’s no need to cover this in Pharos; installers should be responsible for 
describing their own format.
The IDF would be optional, of course. If your installer does not require 
setting this kind of data, just ignore it and go with a plain PDF, according to 
current specs.

Please let me know what you think about this, we want to support PDF asap. Fuel 
documentation will heavily rely on PDF as an input (actually most of the input 
required for the deploy will be in the PDF), so we need to agree on this to 
move forward.

BR,
Alex

[1] 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2017/opnfv-meeting.2017-09-18-15.02.html
[2] https://gerrit.opnfv.org/gerrit/#/c/42017/
[3] https://gerrit.opnfv.org/gerrit/#/c/42233/


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alexandru 
Avadanii
Sent: Friday, September 15, 2017 9:03 PM
To: Julien; hu.zhiji...@zte.com.cn; chig...@huawei.com; bob.monk...@arm.com; 
mpolenc...@mirantis.com; tro...@redhat.com; narinder.gu...@canonical.com; 
jack.mor...@intel.com; agard...@linuxfoundation.org; 
fatih.degirme...@ericsson.com; opnfv-tech-discuss@lists.opnfv.org
Cc: Charalampos Kominos; Guillermo Herrero
Subject: Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?

Hi,
Fuel and Armband teams are working on the final bits for switching to PDF.
We proposed a minor improvement to the parsing mechanism [1]; a PDF file for 
our arm-pod5 is already in place [2]; lf-pod2 PDF will land shortly (we have an 
internal draft we are currently revising), and of course an installer adapter 
that is still being tested before the final switch [3] (will be moved to 
securedlab when ready).

Overall, I think the PDF is a great idea, and we should switch to it as soon as 
possible.
There are still some minor implemention issues on the installer side (e.g. 
trying to determine the jump host bridge names in case they already exist), but 
I will bring that up after I try a few more things, as I think the current PDF 
format is enough to handle all of this, with some minor installer-specific 
parsing.

BR,
Alex

[1

Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi,
I submitted some changes that:

-  Copy PDF generate_config.py and installer adapters to pharos git 
repo [1];

-  Use Pharos git submodule in securedlab to validate PDFs via releng 
verify job [2];

Note that actual PDF files remain in securedlab, only tools are being 
relocated. Old tools will still be available in securedlab until it’s safe to 
remove.
If this affects your project, please review.

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/q/topic:copy-pdf-from-securedlab
[2] https://gerrit.opnfv.org/gerrit/#/q/topic:use-pharos-pdf


From: Alexandru Avadanii
Sent: Monday, September 18, 2017 8:00 PM
To: Julien; hu.zhiji...@zte.com.cn; chig...@huawei.com; bob.monk...@arm.com; 
mpolenc...@mirantis.com; tro...@redhat.com; narinder.gu...@canonical.com; 
jack.mor...@intel.com; agard...@linuxfoundation.org; 
fatih.degirme...@ericsson.com; opnfv-tech-discuss@lists.opnfv.org
Cc: Charalampos Kominos; Guillermo Herrero; BLAISONNEAU David RD-CORE-LAN
Subject: RE: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?

Hi,
In today’s Infra meeting, we had very little time to discuss the specifics of 
using PDF in real-life use-cases, so I am continuing the discussion here.
Afaik, there are at least 2 installer projects actively working on using PDF:

1.   Fuel/Armband based on MCP – Guillermo H. and I have submitted some 
patches covering PDFs for our PODs, as well as minor improvements to PDF 
parsing, and an installer adapter (draft);

2.   Openstack Ansible (OSA) – David B. has submitted a few patches, 
touching the PDF design and possible extensions;

Both installers work well with PDF as an input, but we hit a few design quirks 
that I want to elaborate on:

1.   PDF tooling and installer adapters should be publicly available, which 
we decided today to move to pharos git repo (see [1]), eventually split that 
repo into smaller repos;

2.   PDF alone is not enough to describe installer-specific configuration 
that is scenario-indepedent, e.g.:

a.   Both David and I noticed there is no sane way to map POD networks to 
bridge names on the jump host;

b.  David proposed a new section should be added to describe this mapping; 
I found a way around it for Fuel, but it requires each bridge to have an IP 
addr in each subnet it covers [2];

c.   For OSA, there are other things that can’t be described by PDF, like 
possible node roles (controller, compute, network etc.) which Fuel solves by 
assuming all nodes are the same, and the first 3 nodes in PDF should be 
controllers – this works, but it’s not the best approach for PODs with 
different blades;

Since SDF is not yet available, we want to propose a mechanism that allows 
describing this installer-specific configuration.
David proposed in [3] a set of changes on top of PDF: removing some useless 
entries from PDF, as well as adding a new companion file, the IDF (Installer 
Descriptor File).

My understanding is that changing the PDF to include the IDF in its 
specification is not a good long-term action, or at least that’s what I got 
from today’s meeting.
Although I agree on mixing installer data with PDF is not a good long-term 
solution, we would like to fiind an acceptable solution for the short term 
(until SDF lands).

So, my proposal is to make IDF a separate thing. Design-wise, everything in PDF 
is good to go as it is right now. Fuel (MCP) and Armband projects can easily 
consume the PDF without and IDF (provided we have an IP in the right subnet for 
each jump host bridge, but even that is optional and can be overriden via 
 via Jenkins slave parameters / env vars).
Implementation-wise, David’s patch should be taken as-in. The IDF file (when 
required) will be in the same location the PDF is, with a derived name like 
„podX-idf.yaml”. The syntax and structure will be installer-specific, so 
there’s no need to cover this in Pharos; installers should be responsible for 
describing their own format.
The IDF would be optional, of course. If your installer does not require 
setting this kind of data, just ignore it and go with a plain PDF, according to 
current specs.

Please let me know what you think about this, we want to support PDF asap. Fuel 
documentation will heavily rely on PDF as an input (actually most of the input 
required for the deploy will be in the PDF), so we need to agree on this to 
move forward.

BR,
Alex

[1] 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2017/opnfv-meeting.2017-09-18-15.02.html
[2] https://gerrit.opnfv.org/gerrit/#/c/42017/
[3] https://gerrit.opnfv.org/gerrit/#/c/42233/


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alexandru 
Avadanii
Sent: Friday, September 15, 2017 9:03 PM
To: Julien; hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; 
chig...@huawei.com<mailto:chig...@huawei.

Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi, again,
Sorry for spamming, but after I closer look at the current state of PDF in 
securedlab, I had to point a few more things out.
I am cc’ing the whole list because there is no contact information for 
installer adapters, like we have for the PDF files (see #3 below).



1.   Out of date PDFs – lab owners, please update the PDF files you own:

a.   ./labs/intel/pod18.yaml:  pod owner: Jack Morgan

b.  ./labs/ericsson/pod1.yaml:  pod owner: Jose Lausuch (I assume the 
contact is outdated too);

c.   ./labs/ericsson/pod2.yaml:  pod owner: Jose Lausuch

d.  ./labs/zte/pod3.yaml:  pod owner: Alex Yang

e.  ./labs/zte/pod1.yaml:  pod owner: Alex Yang

f../labs/zte/pod2.yaml:  pod owner: Alex Yang

Notes:

-  lf-pod4.yaml is the reference;

-  arm-pod5.yaml was created last, so it’s up to date;

-  orange-pod1.yaml is under active development by David;


2.   Out of date installer adapters – those who ran against lf-pod4 won’t 
output the expected config due to changes in the PDF:

a.   Apex – almost ok, by far the best PDF support due to its simplicity - 
IPMI credentials are empty;

b.  Compass4nfv – at least eth MAC addresses are empty (tested with 
os-nosdn-nofeature-ha.yml.j2);

c.   Daisy – at least MAC addresses are empty;

d.  Joid – at least MAC addresses are empty;



3.   Proposed minor improvement – I suggest adding contact information to 
installer adapters, similar to PDF – a simple comment w/ an e-mail at the 
beggining should be enough;

BR,
Alex


From: Alexandru Avadanii
Sent: Tuesday, September 19, 2017 12:29 AM
To: 'Julien'; 'hu.zhiji...@zte.com.cn'; 'chig...@huawei.com'; 
'bob.monk...@arm.com'; 'mpolenc...@mirantis.com'; 'tro...@redhat.com'; 
'narinder.gu...@canonical.com'; 'jack.mor...@intel.com'; 
'agard...@linuxfoundation.org'; 'fatih.degirme...@ericsson.com'; 
'opnfv-tech-discuss@lists.opnfv.org'
Cc: Charalampos Kominos; Guillermo Herrero; 'BLAISONNEAU David RD-CORE-LAN'
Subject: RE: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?

Hi,
I submitted some changes that:

-  Copy PDF generate_config.py and installer adapters to pharos git 
repo [1];

-  Use Pharos git submodule in securedlab to validate PDFs via releng 
verify job [2];

Note that actual PDF files remain in securedlab, only tools are being 
relocated. Old tools will still be available in securedlab until it’s safe to 
remove.
If this affects your project, please review.

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/q/topic:copy-pdf-from-securedlab
[2] https://gerrit.opnfv.org/gerrit/#/q/topic:use-pharos-pdf


From: Alexandru Avadanii
Sent: Monday, September 18, 2017 8:00 PM
To: Julien; hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; 
chig...@huawei.com<mailto:chig...@huawei.com>; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; 
mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com>; 
tro...@redhat.com<mailto:tro...@redhat.com>; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 
jack.mor...@intel.com<mailto:jack.mor...@intel.com>; 
agard...@linuxfoundation.org<mailto:agard...@linuxfoundation.org>; 
fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Charalampos Kominos; Guillermo Herrero; BLAISONNEAU David RD-CORE-LAN
Subject: RE: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?

Hi,
In today’s Infra meeting, we had very little time to discuss the specifics of 
using PDF in real-life use-cases, so I am continuing the discussion here.
Afaik, there are at least 2 installer projects actively working on using PDF:

1.   Fuel/Armband based on MCP – Guillermo H. and I have submitted some 
patches covering PDFs for our PODs, as well as minor improvements to PDF 
parsing, and an installer adapter (draft);

2.   Openstack Ansible (OSA) – David B. has submitted a few patches, 
touching the PDF design and possible extensions;

Both installers work well with PDF as an input, but we hit a few design quirks 
that I want to elaborate on:

1.   PDF tooling and installer adapters should be publicly available, which 
we decided today to move to pharos git repo (see [1]), eventually split that 
repo into smaller repos;

2.   PDF alone is not enough to describe installer-specific configuration 
that is scenario-indepedent, e.g.:

a.   Both David and I noticed there is no sane way to map POD networks to 
bridge names on the jump host;

b.  David proposed a new section should be added to describe this mapping; 
I found a way around it for Fuel, but it requires each bridge to have an IP 
addr in each subnet it covers [2];

c.   For OSA,

Re: [opnfv-tech-discuss] Fwd: [infra][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi, Alex,
I understand. The combination of daisy installer adapter + PDF for zte-pod2 
works fine right now.
But we have 2 conflicting PDF formats in securedlab – the new one (used by 
lf-pod4, arm-pod5, orange-pod1, soon lf-pod2 and ericsson-pod1) and the old one 
used by the rest of the PODs.
Since zte-pod2 PDF is not up to date with the reference (lf-pod4), adding a new 
installer adapter (e.g. for Fuel) will lead to failures in all verify jobs in 
securedlab, since we plan to support the up-to-date PDF format, and not the old 
format zte-pod2 uses.

e.g.:
securedlab$ utils/generate_config.py -y labs/lf/pod4.yaml -j 
installers/daisy/pod_config.yaml.j2
[…]
  mac_addresses:
-
[…]

My previous mail is a heads-up that the standard evolved and we should try to 
follow the new reference, if possible.
The changes between the old format and the new one are not that radical, so it 
should be easy to apply the update; the bigger problem is coordinating all 
installers/pod owners to handle this in the tight timeframe we have before the 
release.

BR,
Alex


From: yangya...@zte.com.cn [mailto:yangya...@zte.com.cn]
Sent: Tuesday, September 19, 2017 4:24 AM
To: julien...@gmail.com; hu.zhiji...@zte.com.cn; 
opnfv-tech-discuss@lists.opnfv.org; Alexandru Avadanii; chig...@huawei.com; 
bob.monk...@arm.com; mpolenc...@mirantis.com; tro...@redhat.com; 
narinder.gu...@canonical.com; jack.mor...@intel.com; 
agard...@linuxfoundation.org; fatih.degirme...@ericsson.com; 
huzhiji...@gmail.com; yangy2...@gmail.com
Subject: 答复: Fwd: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported 
by installer project now?


Hi,

PDF is supported by Daisy on zte-pod2 with os-odl-nofeature-ha / 
os-odl-nofeature-ha scenarios.

Daisy will add more pods and scenarios in the future.



Alex Yang

Virtualization Shanghai System Dept
[cid:image001.gif@01D33101.4AD2BE90]

[cid:image002.gif@01D33101.4AD2BE90]

B502-B5047, ZTE Corporation, No.889 Bibo Road,

PuDong District, Shanghai, P.R.China, 201203
T: +86 21 68896517 M: +86 13816276736
E: yangya...@zte.com.cn<mailto:yangya...@zte.com.cn>
www.zte.com.cn<https://url10.mailanyone.net/v1/?m=1du7Lo-0006mP-3T&i=57e1b682&c=yh0Ia5945x_9R-MRI1CWBfH3QWNhne1xH1oujhdn2zCO4jeCAj5pzyRG97OcSZTjDGTLhoDFkKEVQ-UjuvbN4swNP18nTDuvn1PA-1gcHABkdGsmHI6_-K2rJwTqq59wl6H5cYxg-Nt6x0qOiRhd6iANq__xNI0PPXa7h-STKAbLyq_U16D9Jg6YX2nYldTQN60obkOdXdy6gwm-Vo9QmesDgViXzCEAwcVOrhaXSww>

原始邮件
发件人： mailto:julien...@gmail.com>>;
收件人： mailto:huzhiji...@gmail.com>>;杨阳10014842;
日 期 ：2017年09月18日 21:09
主 题 ：Fwd: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported 
byinstaller project now?



-- Forwarded message -----
From: Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>
Date: 2017年9月16日周六 上午2:03
Subject: RE: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?
To: Julien mailto:julien...@gmail.com>>, 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn> 
mailto:hu.zhiji...@zte.com.cn>>, 
chig...@huawei.com<mailto:chig...@huawei.com> 
mailto:chig...@huawei.com>>, 
bob.monk...@arm.com<mailto:bob.monk...@arm.com> 
mailto:bob.monk...@arm.com>>, 
mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com> 
mailto:mpolenc...@mirantis.com>>, 
tro...@redhat.com<mailto:tro...@redhat.com> 
mailto:tro...@redhat.com>>, 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com> 
mailto:narinder.gu...@canonical.com>>, 
jack.mor...@intel.com<mailto:jack.mor...@intel.com> 
mailto:jack.mor...@intel.com>>, 
agard...@linuxfoundation.org<mailto:agard...@linuxfoundation.org> 
mailto:agard...@linuxfoundation.org>>, 
fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com> 
mailto:fatih.degirme...@ericsson.com>>, 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Cc: Guillermo Herrero 
mailto:guillermo.herr...@enea.com>>, Charalampos 
Kominos mailto:charalampos.komi...@enea.com>>



Hi,
Fuel and Armband teams are working on the final bits for switching to PDF.
We proposed a minor improvement to the parsing mechanism [1]; a PDF file for 
our arm-pod5 is already in place [2]; lf-pod2 PDF will  land shortly (we have 
an internal draft we are currently revising), and of course an installer 
adapter that is still being tested before the final switch [3] (will be moved 
to securedlab when ready).

Overall, I think the PDF is a great idea, and we should switch to it as soon as 
possible.
There are still some minor implemention issues on the installer side (e.g. 
trying to determine the jump host bridge names in case  they already exist), 
but I will bring that up after I try a few more things, as I think the current 
PDF format is enough to handle all of this, with some minor i

Re: [opnfv-tech-discuss] Fwd: [infra][pharos]Is PDF feature supportedby installer project now?

[Alexandru Avadanii]

Hi, Alex,
As Jack pointed out, we should wait for him to validate my statement, as I 
might be in the wrong here, and lf-pod4/arm-pod5 be the wrong PDFs.
Let’s give Jack some time to sort this out first.

Sorry for the long and (maybe) wrong e-mails in this thread.
I sincerely apologize for not double-checking this with Jack and the Pharos 
team before reaching the whole list.

And a big thanks to Jack for catching this in time!

BR,
Alex


From: yangya...@zte.com.cn [mailto:yangya...@zte.com.cn]
Sent: Tuesday, September 19, 2017 5:08 AM
To: Alexandru Avadanii
Cc: julien...@gmail.com; hu.zhiji...@zte.com.cn; 
opnfv-tech-discuss@lists.opnfv.org; chig...@huawei.com; bob.monk...@arm.com; 
mpolenc...@mirantis.com; tro...@redhat.com; narinder.gu...@canonical.com; 
jack.mor...@intel.com; agard...@linuxfoundation.org; 
fatih.degirme...@ericsson.com; huzhiji...@gmail.com; yangy2...@gmail.com
Subject: 答复: RE: Fwd: [opnfv-tech-discuss] [infra][pharos]Is PDF feature 
supportedby installer project now?


Hi Alexandru,

Thanks for your reminder. We have noticed that issue.

I will post patch in securedlab to update our PDF and template soon.





Alex Yang

Virtualization Shanghai System Dept
[cid:image001.gif@01D33108.23579C80]

[cid:image002.gif@01D33108.23579C80]

B502-B5047, ZTE Corporation, No.889 Bibo Road,

PuDong District, Shanghai, P.R.China, 201203
T: +86 21 68896517 M: +86 13816276736
E: yangya...@zte.com.cn<mailto:yangya...@zte.com.cn>
www.zte.com.cn<https://url10.mailanyone.net/v1/?m=1du7xi-0002Pz-4G&i=57e1b682&c=L8yinDmbolMRHXNwLR13OzMKssf9odmsZc9esD302x7ihE9Ch5VkHOdoYb1ZqZyub3r3DDeVjQXRGFlPiIAEkKeACDPZMq8eV3OOVogDLztYvkIsyWeIi-Pi7pnh2GprMG9Rn7huioKZcXUz7hCdzAXa-PjD0uPjmEJVxqefUMrEkGt9c5xi9dD0Oon4ucw-8GEHhAWtMW96P14Cl-OKKzKVgl3xUOePDWIWZEjT_yg>

原始邮件
发件人： mailto:alexandru.avada...@enea.com>>;
收件人：杨阳10014842; mailto:julien...@gmail.com>>;胡智江10080967; 
mailto:opnfv-tech-discuss@lists.opnfv.org>>;
 mailto:chig...@huawei.com>>; 
mailto:bob.monk...@arm.com>>; 
mailto:mpolenc...@mirantis.com>>; 
mailto:tro...@redhat.com>>; 
mailto:narinder.gu...@canonical.com>>; 
mailto:jack.mor...@intel.com>>; 
mailto:agard...@linuxfoundation.org>>; 
mailto:fatih.degirme...@ericsson.com>>; 
mailto:huzhiji...@gmail.com>>; 
mailto:yangy2...@gmail.com>>;
日 期 ：2017年09月19日 09:40
主 题 ：RE: Fwd: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supportedby 
installer project now?


Hi, Alex,
I understand. The combination of daisy installer adapter + PDF for zte-pod2 
works fine right now.
But we have 2 conflicting PDF formats in securedlab – the new one (used by 
lf-pod4, arm-pod5, orange-pod1, soon lf-pod2 and ericsson-pod1)  and the old 
one used by the rest of the PODs.
Since zte-pod2 PDF is not up to date with the reference (lf-pod4), adding a new 
installer adapter (e.g. for Fuel) will lead to failures  in all verify jobs in 
securedlab, since we plan to support the up-to-date PDF format, and not the old 
format zte-pod2 uses.

e.g.:
securedlab$ utils/generate_config.py -y labs/lf/pod4.yaml -j 
installers/daisy/pod_config.yaml.j2
[…]
  mac_addresses:
-
[…]

My previous mail is a heads-up that the standard evolved and we should try to 
follow the new reference, if possible.
The changes between the old format and the new one are not that radical, so it 
should be easy to apply the update; the bigger problem  is coordinating all 
installers/pod owners to handle this in the tight timeframe we have before the 
release.

BR,
Alex


From: yangya...@zte.com.cn<mailto:yangya...@zte.com.cn> 
[mailto:yangya...@zte.com.cn]
Sent: Tuesday, September 19, 2017 4:24 AM
To: julien...@gmail.com<mailto:julien...@gmail.com>; 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Alexandru Avadanii; chig...@huawei.com<mailto:chig...@huawei.com>; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; 
mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com>; 
tro...@redhat.com<mailto:tro...@redhat.com>; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 
jack.mor...@intel.com<mailto:jack.mor...@intel.com>; 
agard...@linuxfoundation.org<mailto:agard...@linuxfoundation.org>;  
fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>; 
huzhiji...@gmail.com<mailto:huzhiji...@gmail.com>; 
yangy2...@gmail.com<mailto:yangy2...@gmail.com>
Subject: 答复: Fwd: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported 
by installer  project now?


Hi,

PDF is supported by Daisy on zte-pod2 with os-odl-nofeature-ha / 
os-odl-nofeature-ha scenarios.

Daisy will add more pods and scenarios in the future.



Alex Yang

Virtualization Shanghai System Dept
[cid:image001.gif@01D33108.23579C80]

[cid:image002.gif@01D33108.23579C80]

B502-B5047, ZTE Corporation, No.889 Bibo Road,

PuD

Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by installer project now?

[Alexandru Avadanii]

Hi, Uli, David,
Thank you for the feedback, I will do my best to look into SDF and review the 
new (temporary?) installer extension.
I hope SDF will be adopted soon, as PDF is a great input mechanism for us, so I 
assume SDF will improve the end-user experience even more.

BR,
Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
david.blaisonn...@orange.com
Sent: Tuesday, September 19, 2017 12:46 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [infra][pharos]Is PDF feature supported by 
installer project now?


Hi,

Thanks Alexandru, you clearly resume the discussion.

I wrote that IDF for baremetal xci with the need to bring more flexibility to 
PDF (and then SDF) that are quite rigid by design (but must stay as it, as they 
are reference for every one). It seems that we are several to have the same 
need, so if we came to a consensus on that extra file, i would propose several 
rules:

  1.  this file is an optional extension of the PDF, linked to a pod, and 
contains only informations required by installers for a specific pod
  2.  No overlap with PDF and SDF
  3.  this file is managed by installers, to avoid pod relative configurations 
in the installer itself.
  4.  Use a generic section if several installers agree on the same data (that 
may be moved to PDF or SDF if a consensus is reached)
  5.  the smaller, the better

In my opinion, this file would bring not only flexibility for installers, but 
could also be used as an incubator for new needs to be pushed in PDF and SDF.

I will split the associated patch [3] to only talk about the IDF. Please feel 
free to review it.

BR,

David



[3] 
https://gerrit.opnfv.org/gerrit/#/c/42233/<https://url10.mailanyone.net/v1/?m=1duF6C-00010b-4P&i=57e1b682&c=XfXA8CTu21bYARZ5Pcs4SNXCZg1xd8TvD7FIl6m9fWmpcAoof2iE3mKPcRJUftX4GzwnXIbdxWF1pyuBZ6Hb2_sNn10-eJvRsVKz_iEI3tT8ytB5Fi1r0UbgHlvLzRcgkYxLthknqWt_q_FSjzOaik-vJgSkfahPGGtH-9iiBfoP4BEK_XNxV_T51R3r8tjaIvpzmlNv4hBNeyyQJZQRvxwjiPOE7fMyD_miSIEneWkB3xSaoUJPq9S5bducUba5>

--

David BLAISONNEAU

NFV platforms DevOPS - OPNFV contributor

Orange - IMT / OLN / CNC / NCA / SINA



tel: +33 (0)2 96 07 27 93

email: david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>

2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le 19/09/2017 à 10:21, Ulrich Kleber a écrit :
Hi,
Thanks, Alexandru, I think you solved my action from yesterday’s Infra call :-).

I think the idf as you proposed it is a good thing.
Just make sure, we don’t need to duplicate information too often (e.g. where 
there is identical information for all pods in a lab).

The sdf template exists since a few months, but I didn’t get enough feedback 
from the installer teams.
We have to make sure that not only the sdf can be easily consumed by the 
installers, but also provides all data the installers need in an independent way
and there is no gap then between the pdf&idf and the sdf.

The sdf template is available since June. Please have a look and let me know if 
there are things missing.
At that time I couldn’t check against MCP, only against Fuel configuration 
files.
(see 
https://git.opnfv.org/octopus/tree/scenarios/templates/sdf-template.yaml<https://url10.mailanyone.net/v1/?m=1duF6C-00010b-4P&i=57e1b682&c=GEVMeJ6UY_ptGAhUdVilFuXsSx-Pe__hCY_V2p5_PNbs5i4exzQtUMT1nJPJ76T5qolNawAgRcA_CA5Y-aKG9I--isvQmvD3Uooyvxw-epSh2M0u1b-Q4G6N-9-q9UR0rZADgjoYS4sPPG_oEzqLahk-QHv5izTkV1sfGt6pw22owmnpfXUIaS_7c7geS3qMwaaIQ-ZK5kXBlCddg7ImcR8ARSxsnEFFxfiCTckkGvtajygNKvDmEsL9s-yrqxHWpF3ZCM9Zfy00AzPiNtIZINABgFF_CyqqA-esExs>
 )
Please other installer teams, also let me know about missing or wrong things.
Also feel free to propose patches ;-).
The scenario lifecycle document is also available in octopus repo (or 
http://artifacts.opnfv.org/octopus/docs/scenario-lifecycle/index.html<https://url10.mailanyone.net/v1/?m=1duF6C-00010b-4P&i=57e1b682&c=AqbrFGmpJ3Nb93LJC23hBfR0n5tZp5Ff8BeOFkxs4ttZ_qJtsygcrQ5fwy4gd6t2VTAEHIK7TuWwRgi1kqXoJ7fHmJA_siieJlUPeWSWf7SbB9EzlYuqXXWWZJeop_A3gIRc2Fme1vPoO5fbIbT316zq35In9nb_uA-BEABT3TJ3qBRXMFlF_PMIcj5qiR5aSYJDHZZzygIhpCcgjVOL-CwXHHafXK5Hkexu8uzMjDtQUxGi9AoqIIFyDb1jj6WId6die-a5sFo42CZUUvrg9aA_VUHbSMN4RMKSEtYv_6E>
 ) and
awaiting more feedback.

Cheers,
Uli




From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alexandru 
Avadanii
Sent: Monday, 18 September, 2017 19:00
To: Julien; hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; Chigang 
(Justin); bob.monk...@arm.com<mailto:bob.monk...@arm.com>; 
mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com>; 
tro...@redhat.com<mailto:tro...@redhat.com>; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 
jack.mor...@intel.com<mailto:jack.mor...@intel.com>; 
aga

Re: [opnfv-tech-discuss] status of functest and yardstick on stable/euphrates

[Alexandru Avadanii]

Hi, David,
Most (if not all) installers are blocked by the lack of „stable/euphrates” 
branch in securedlab repo.
This has been discussed during the Infra WG meeting and will be probably be 
fixed soon, but until then we won’t have any test project runs.

BR,
Alex


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Thursday, September 21, 2017 3:15 AM
To: Tim Rozet; Narinder Gupta; Chigang (Justin); huzhj_zte; jason; Michail 
Polenchuk; Alexandru Avadanii; Cristina Pauna; Jose Lausuch; Brattain, Ross B; 
Fatih Degirmenci; Beierl, Mark
Cc: TECH-DISCUSS OPNFV; Raymond Paik; Tapio Tallgren
Subject: status of functest and yardstick on stable/euphrates

Team,

At the release meeting on Tuesday, it sounded like we were within a day or two 
of having functest and yardstick running on stable/euphrates.  Please report on 
the following:

Docker YAML update (Mark B):

Dashboard update (Jose/Ross):

Installer status:



FuncTest

Yardstick

Apex





Compass





Daisy





Fuel (x86)





Fuel (ARM)





Joid







--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___
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] [pharos] Splitting up the Pharos Repo

[Alexandru Avadanii]

Hi, Trevor,
I think the new repo should have a stable/euphrates branch, but I might be 
wrong.

BR,
Alex

> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
> boun...@lists.opnfv.org] On Behalf Of Trevor Bramwell
> Sent: Friday, September 22, 2017 11:07 PM
> To: Jack Morgan
> Cc: opnfv-tech-discuss@lists.opnfv.org
> Subject: Re: [opnfv-tech-discuss] [infra] [pharos] Splitting up the Pharos 
> Repo
> 
> Hi Jack, et al.
> 
> I've finished splitting up the Pharos repo. Sorry for the slight delay as I 
> was at a
> conference last week.
> 
> If you have time, please review the three patchsets for completing this
> transition:
> 
>  * pharos: https://gerrit.opnfv.org/gerrit/#/c/42809/
>  * pharos-tools: https://gerrit.opnfv.org/gerrit/#/c/42815/
>  * releng: https://gerrit.opnfv.org/gerrit/#/c/42811/
> 
> I couldn't find any jobs specifically using pharos-dashboard or 
> pharos-validator,
> but if anyone see/knows-of a reference I overlooked, please submit a patch to
> change it.
> 
> Regards,
> Trevor Bramwell
> 
> On Thu, Sep 21, 2017 at 11:00:28AM -0700, Jack Morgan wrote:
> >Trevor,
> >
> >Go ahead with Pharos repo slit per the following structure. thanks
> >
> > pharos
> >  - INFO
> >  - config
> >  - pdf/pod1.yaml
> >  - installers
> >  - utils
> >
> >pharos-tools
> >  - lass-fog
> >  - dashboard
> >  - validator
> >
> >On 09/21/2017 01:09 AM, Julien wrote:
> >
> >  +1, PDF is better than template.
> >  in the future, this file will be evolved into a pdf yaml schema file. 
> > It
> >  can be directly used to verify the content in PDF.
> >  Jack Morgan 于2017年9月20日周三 下午9:17
> 写道：
> >
> >Thanks Julien for feedback. I made one small suggestions below, what
> >do you think? thanks
> >
> >On 09/19/2017 10:52 PM, Julien wrote:
> >
> >  Hi Trevor,
> >  Thanks for following these changes in pharos.
> >  Agree to merge LaaS and PDF changes.
> >  some comments:
> >   pharos
> >    - INFO
> >    - config
> >      - pod1.yaml           ==> /template/pod1.yaml
> >
> >can we use pdf instead of template? config/pdf/pod1.yaml
> >
> >      - installers
> >      - utils
> >
> >   pharos-tools
> >    - lass-fog                  ==> laas
> >    - pharos-dashboard ==> dashboard
> >    - pharos-validator    ==> validator
> >  BR/Julien
> >  Trevor Bramwell 于2017年9月20日
> 周三
> >  上午6:37写道：
> >
> >Hi All,
> >
> >Yesterday in the Infra-WG we discussed[1] splitting up the Pharos
> >repository due to it's growing size. Jack and I discussed further
> >how
> >he'd like the repo split up and I wanted to share with you our
> >plans,
> >most of which will start tomorrow:
> >
> > * Merging Peter's[2] patchsets for LaaS
> >
> > * Merging Alex patchsets to move the PDF generator[3] work out 
> > of
> >    securedlab and add pharos as a submodule of securedlab[4].
> >
> > * Splitting out the pharos tools directory into it's own repo
> >    pharos-tools using git-filter-branch:
> >
> >      git filter-branch -d pharos --tag-name-filter cat
> >--subdirectory-filter tools -- --all
> >
> > * Updating the pharos git repository to remove the tools
> >directory and
> >    gitobjects created by those commits.
> >
> > * Updating any related Jenkins jobs.
> >
> >The new structure of the repos would look like this:
> >
> > pharos
> >  - INFO
> >  - config
> >    - pod1.yaml
> >    - installers
> >    - utils
> >
> > pharos-tools
> >  - lass-fog
> >  - pharos-dashboard
> >  - pharos-validator
> >
> >If anything doesn't line up with what we talked about Jack, 
> > please
> >correct me!
> >
> >Regards,
> >Trevor bramwell
> >
> >[1]
> >http://ircbot.wl.linuxfoundation.org/meetings/opnfv-
> meeting/2017/opnfv-meeting.2017-09-18-15.02.html
> >[2]
> >
> https://gerrit.opnfv.org/gerrit/#/q/owner:%22Parker+Berberian%22+status:ope
> n
> >[3]
> >
> https://gerrit.opnfv.org/gerrit/#/q/status:open+project:pharos+branch:master+
> topic:copy-pdf-from-securedlab
> >[4]
> >
> https://gerrit.opnfv.org/gerrit/#/q/status:open+project:securedlab+branch:mas
> ter+topic:use-pharos-pdf
> >___
> >
> >  --
> >  Jack Morgan
> >  OPNFV Pharos Intel Lab
> 
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https:/

[opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[Alexandru Avadanii]

Hi,

A. Current Fuel PDF integration status

Fuel and Armband teams have been working on moving to the new PDF as a single 
input configuration file.
We have proposed a new installer adapter template for Fuel in Pharos [1], as 
well as new PDFs in securedlab for the PODs Fuel uses:
- lf-pod2 [2];
- arm-pod5 has been around for a while;
- ericsson-pod1 and zte-pod1 already have PDFs, but might require smalls 
updates to work with the Fuel installer adapter;

While working on the PDFs, we proposed some patches that should improve/extend 
the verify job for securedlab, use the Pharos git repo for PDF parsing, 
respectively some minor cleanup/code folding:
- securedlab verify job should switch to using Pharos installer adapters and 
generate_config [3];
- yamllint fixes and code folding for existing PDFs [4];
- add verify job summary, run the whole test matrix instead of bailing on the 
first error [5];
- extend verify with yamllint runs for PDF files, as well as output yaml 
file(s) generated by check_jinja2 [6];
- fix missing IPMI credentials for lf-pod4 (caught by linting the output yaml 
described above) [7];
- (unrelated to PDF, Fuel cleanup) remove old Fuel configuration files we no 
longer use [8];

B. PDF specification limitations for Fuel

Tbh, I have a hard time summarizing this, but I'll try.
Currently, we have some PDFs that define a 'net_config' section (global per 
PDF), while the spec and most PDFs don't.
This resulted from:
- the need to support multiple VLANs over the same physical interface;
- installers expecting a network-centric mapping between existing/to-be-created 
networks and available interfaces;

Looking at what Fuel expects as input, we'd like to be able to easily map IPs 
in a certain network (e.g. admin, mgmt, private, public) to a particular 
interface name.
But the PDF does not allow specifying interface names directly, as those depend 
not only on target OS, but also on OS config (e.g. net.ifnames=0 biosdevname=1 
vs net.ifnames=1 biosdevname=0).
Indexing interfaces is also fragile, as a bios upgrade might change PCI layout 
and therefore the NIC ordering (quite rare, but still).
What happens if we add a new interface that ends up at index 1, between 
existing interfaces 0 and 2?
The 'net_config' section is a compromise that solves part of the problem, but 
still does not provide a solid solution for the physical interface name 
mapping, as it also relies on interface index.
What if the controller nodes have a different set of interfaces than the 
compute nodes have?
Adding 'net_config' to PODs aligned with the current spec is also problematic, 
as it'd duplicate the VLAN information, making the whole thing even more 
fragile.

Tl;dr I submited a proof of concept refactor of net_config, which triesto align 
more with the current PDF spec, although it is not 100% compatible (we can't 
model multiple VLANs on the same physical interface with the current spec) [9].
Observations wrt this change:
- network-centric approach, installer-friendly;
- physical interface to virtual interface mapping is NOT 1:1 (multiple VLANs on 
same physical NIC);
- virtual inteface to network mapping is 1:1;
- network to IP mapping is 1:1;
- networks are global for the POD (including network to virtual network);
- network to physical inteface mapping is NOT global per POD, and should be 
overrideable on a per-node basis;
- features and speed params were silently discarded during net_config addition, 
bring them back for the physical intefaces;
- converting from current spec-compatible PDF to this proposed format should be 
trivial for PDF files, and should require very little work on the installer 
adapters;
Etc.

Please take some time to review this and let's come up with a better solution 
if we can find one, or at least align our current PDFs to one format or another.
The PoC does not solve the interface indexing issue, but at least it provides a 
mechanism that makes it per-node configurable.

C. PDF current implementation issues

This section covers some divergent aspects in the current PDFs in securedlab. 
The PDF spec is quite clear on some of these, so I don't understand why there 
are so many mutations in the wild.
If parsing the PDF is hard / does not align with the installer-expected input, 
we can define some new custom filters in generate_config.py, although most of 
these should be fixable within the current tool set.

1. 'vlan: 0' vs 'vlan: native'
The spec uses 'native' to differentiate from '0', which might have a 
special/reserved meaning on some network equipments.
We currently have both formats in securedlab.

2. 'disk_rotation: ssd' or 'disk_rotation: 15000' for SSD drives
Here, the spec does not provide a special value for SSDs. Afaik, no installer 
adapter consumes this yet, but we should extend the PDF spec and then adhere to 
the new value.
We currently have a mix of both formats in securedlab, and both are wrong imo 
:).

3. 'features: dpdk|sriov' vs 'features: dpdk, sriov'
Ag

Re: [opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[Alexandru Avadanii]

Hi,
The part about net_config was confusing because it was not (yet) part of the 
official PDF spec.
After today’s infra meeting, and some more discussion on IRC, it looks like 
net_config will become part of the spec, but we need to sort out some network 
naming issues first.

However, ‚admin’, ‚mgmt’ & co network names are not inline with the PDF idea of 
describing strictly the hardware, so they will most likely need to be mapped 
using the installer descriptor file companion for now.
I updated [9] to reflect this decision. It makes things a little bit more 
complicated for the installer adapters, but I think keeping PDF clean (with no 
higher-level specifics) is a good idea overall.

Sections C and D in my first mail still need to be sorted out, but they are 
mostly minor quirks or deviations from the spec, so they are not blocking the 
release of PDF.

BR,
Alex


From: david.blaisonn...@orange.com [mailto:david.blaisonn...@orange.com]
Sent: Monday, September 25, 2017 12:11 PM
To: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org
Cc: jack.mor...@intel.com; Guillermo Herrero
Subject: Re: PDF feedback and questions from our experience with Fuel


Hi Alexandru,

thanks for this big set of patches and a sum up of our last pdf discussions.

The part about net_config is quite confuse, specially because you sum up many 
problems already solved by net_config, but talking about PDF not having it, 
then talking about what add net_config... but it is a hard job to summerize 
those evolution and point that we would better understand each one by using PDF 
version id, and work on a reference model.

Generally it will be +1 :)

BR

David



--

David BLAISONNEAU

NFV platforms DevOPS - OPNFV contributor

Orange - IMT / OLN / CNC / NCA / SINA



tel: +33 (0)2 96 07 27 93

email: david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>

2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le 25/09/2017 à 00:21, Alexandru Avadanii a écrit :

Hi,



A. Current Fuel PDF integration status



Fuel and Armband teams have been working on moving to the new PDF as a single 
input configuration file.

We have proposed a new installer adapter template for Fuel in Pharos [1], as 
well as new PDFs in securedlab for the PODs Fuel uses:

- lf-pod2 [2];

- arm-pod5 has been around for a while;

- ericsson-pod1 and zte-pod1 already have PDFs, but might require smalls 
updates to work with the Fuel installer adapter;



While working on the PDFs, we proposed some patches that should improve/extend 
the verify job for securedlab, use the Pharos git repo for PDF parsing, 
respectively some minor cleanup/code folding:

- securedlab verify job should switch to using Pharos installer adapters and 
generate_config [3];

- yamllint fixes and code folding for existing PDFs [4];

- add verify job summary, run the whole test matrix instead of bailing on the 
first error [5];

- extend verify with yamllint runs for PDF files, as well as output yaml 
file(s) generated by check_jinja2 [6];

- fix missing IPMI credentials for lf-pod4 (caught by linting the output yaml 
described above) [7];

- (unrelated to PDF, Fuel cleanup) remove old Fuel configuration files we no 
longer use [8];



B. PDF specification limitations for Fuel



Tbh, I have a hard time summarizing this, but I'll try.

Currently, we have some PDFs that define a 'net_config' section (global per 
PDF), while the spec and most PDFs don't.

This resulted from:

- the need to support multiple VLANs over the same physical interface;

- installers expecting a network-centric mapping between existing/to-be-created 
networks and available interfaces;

Looking at what Fuel expects as input, we'd like to be able to easily map IPs 
in a certain network (e.g. admin, mgmt, private, public) to a particular 
interface name.

But the PDF does not allow specifying interface names directly, as those depend 
not only on target OS, but also on OS config (e.g. net.ifnames=0 biosdevname=1 
vs net.ifnames=1 biosdevname=0).

Indexing interfaces is also fragile, as a bios upgrade might change PCI layout 
and therefore the NIC ordering (quite rare, but still).

What happens if we add a new interface that ends up at index 1, between 
existing interfaces 0 and 2?

The 'net_config' section is a compromise that solves part of the problem, but 
still does not provide a solid solution for the physical interface name 
mapping, as it also relies on interface index.

What if the controller nodes have a different set of interfaces than the 
compute nodes have?

Adding 'net_config' to PODs aligned with the current spec is also problematic, 
as it'd duplicate the VLAN information, making the whole thing even more 
fragile.





Tl;dr I submited a proof of concept refactor of net_config, which triesto align 
more with the current PDF spec, although it is not 100% compatible (we can't 
model multiple VLANs on the same physical interface with

Re: [opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[Alexandru Avadanii]

Hi,
See inline.

BR,
Alex


From: david.blaisonn...@orange.com [mailto:david.blaisonn...@orange.com]
Sent: Tuesday, September 26, 2017 11:54 AM
To: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org
Cc: jack.mor...@intel.com; Guillermo Herrero
Subject: Re: PDF feedback and questions from our experience with Fuel


Hi,

I hope I don't offend you about net_config, it is an hard subject, not easy to 
summarize, and born during summer holidays without everyone around the gerrit 
pit.

[ Alex ] Don’t worry about offending anyone, we are here to create a good 
design, not to enforce one or the other’s preferences.

About network naming, I understand the need of anonymize the networks parts to 
not over specify the installer level, but by calling them 'networkX' we will 
lost a precious information: 'how this network is prepared' by ops in network 
and security aspects. You may had already talk about that yesterday (sorry for 
missing it, job and child schedules collision), but simple networking questions 
must be answered when preparing a network mapping: Is this network NATed to 
outside ? does this network can talk to one other ? are some ip/ports opened at 
firewall level ? In Orange side, and for security aspects, we isolate some 
networks: Public can not talk to admin, storage is isolated and is not NATed to 
outside... Using 'admin', 'storage', 'public' naming give a part of the 
information, but 'networkX' don't, except if we are adding a description in the 
PDF like flow matrix, or we add external source, like the wiki. How do you 
think to handle that part ?

[ Alex ] The argument for renaming the networks was that the PDF should only 
describe the hardware setup, leaving out any software aspects, like the usage 
of those networks by each installer.

This, of course, makes things like describing NAT / isolation harder, but then 
again, I don’t think those belong in the PDF either.

I have no strong opinion towards ‚admin’ vs ‚vlan0’ naming, the Fuel adapter 
can work very well with any implementation.

I also proposed we let the PDF maintainer choose the network names, but this 
idea was rejected since we want to keep the PDF strict. If others have any 
input on this, I would invite them to propose a naming that solves as many of 
the problems above as possible, or at least defend one solution in favor of the 
other.

This raise a more general question, is there recommendations about network 
topology and security rules in OPNFV pods or each lab is follow its own rules ?

For C section, here are my answers:
1. 'vlan: 0' vs 'vlan: native': OK for native if 0 have a special meaning
2. 'disk_rotation: ssd' or 'disk_rotation: 15000' for SSD drives. Is 
disk_rotation enough to specify a disk performances? don't we also need the 
size of the cache ? we would better talk about bandwidth if we want also use it 
for ssd ? Maybe Bottlenecks project can help us.
3. 'features: dpdk|sriov' vs 'features: dpdk, sriov': it seems to be a 
collision between PDF specs and the yaml one. If it is a list we should 
simplify the installer parsing by using a yaml list: [ x, y, z] or a dashed list
4. 'features: null' vs 'features: ' vs omitting it altogether: 'features: []' 
or omitting; the first is yaml compliant with a list, the second is to simplify 
the pdf.
5. inconsistent node naming: in my opinion, this part shall be reserved for the 
ops, it is the only way for them to map a node with a physical server in the DC 
(except the ipmi address that is not the simple way to find a node). All values 
shall be authorized, but recommandation can be made on 'pod-')
6. Address/netmask: isn't netmask information in address overlaping with 
net_config netmasks ?
7. 'os' in POD nodes: Only in jumphost
8. IPMI interface MAC on the 'interfaces' list: no, it overlaps with 
remote_management/mac_address and is not seen from the os.
Thanks again for this huge work of listing all pending points.

BR

David



--

David BLAISONNEAU

NFV platforms DevOPS - OPNFV contributor

Orange - IMT / OLN / CNC / NCA / SINA



tel: +33 (0)2 96 07 27 93

email: david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>

2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le 25/09/2017 à 20:02, Alexandru Avadanii a écrit :
Hi,
The part about net_config was confusing because it was not (yet) part of the 
official PDF spec.
After today’s infra meeting, and some more discussion on IRC, it looks like 
net_config will become part of the spec, but we need to sort out some network 
naming issues first.

However, ‚admin’, ‚mgmt’ & co network names are not inline with the PDF idea of 
describing strictly the hardware, so they will most likely need to be mapped 
using the installer descriptor file companion for now.
I updated [9] to reflect th

Re: [opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[Alexandru Avadanii]

Hi, Julien,
I agree on all the items below.
Thank you for the feedback!

BR,
ALex


From: Julien [mailto:julien...@gmail.com]
Sent: Tuesday, September 26, 2017 5:52 PM
To: david.blaisonn...@orange.com; Alexandru Avadanii; 
opnfv-tech-discuss@lists.opnfv.org
Cc: Guillermo Herrero
Subject: Re: [opnfv-tech-discuss] PDF feedback and questions from our 
experience with Fuel

Hi Alex,

Thanks for the conclusions of current working items in PDF.

Some response from my side:
1. 'vlan: 0' vs 'vlan: native':
'vlan: native' is easier for understanding. it is not fixed and a specific 
vlan id will be required, while vlan 0 has some special meaning.
2. 'disk_rotation: ssd' or 'disk_rotation: 15000' for SSD drives.
disk_rotation is not valid for ssd.
3. 'features: dpdk|sriov' vs 'features: dpdk, sriov':
agree with David, yaml list is better
4. 'features: null' vs 'features: ' vs omitting it altogether: 'features: []' 
or omitting;
same as #3
5. inconsistent node naming:
the lab/pod can be identified by the full directory path. suggest to use a 
clean and simple name without pod name in it. such as : pod1-node1
6. Address/netmask:
   when we use ifconfig, it is the simplest method to describe address/netmask. 
It is "address" and "netmask" in interfaces(Ubuntu). How about to support both 
of them.
7. 'os' in POD nodes:
Only in jumphost, for installer will be deployed in a VM in the jumphost. 
It is meaningful for the installers.
8. IPMI interface MAC on the 'interfaces' list:
MAC address is not valid for IPMI access, we can cancel it.

About yamllint, I think when we finish the template, we can add a schema for 
the PDF file and use it to verify the content.
About the interface names, I prefer to keep the original and easy 
understandable names, such as: admin, management, public, etc.

BR/Julien


mailto:david.blaisonn...@orange.com>>于2017年9月26日周二
 下午4:54写道：

Hi,

I hope I don't offend you about net_config, it is an hard subject, not easy to 
summarize, and born during summer holidays without everyone around the gerrit 
pit.

About network naming, I understand the need of anonymize the networks parts to 
not over specify the installer level, but by calling them 'networkX' we will 
lost a precious information: 'how this network is prepared' by ops in network 
and security aspects. You may had already talk about that yesterday (sorry for 
missing it, job and child schedules collision), but simple networking questions 
must be answered when preparing a network mapping: Is this network NATed to 
outside ? does this network can talk to one other ? are some ip/ports opened at 
firewall level ? In Orange side, and for security aspects, we isolate some 
networks: Public can not talk to admin, storage is isolated and is not NATed to 
outside... Using 'admin', 'storage', 'public' naming give a part of the 
information, but 'networkX' don't, except if we are adding a description in the 
PDF like flow matrix, or we add external source, like the wiki. How do you 
think to handle that part ?

This raise a more general question, is there recommendations about network 
topology and security rules in OPNFV pods or each lab is follow its own rules ?

For C section, here are my answers:
1. 'vlan: 0' vs 'vlan: native': OK for native if 0 have a special meaning
2. 'disk_rotation: ssd' or 'disk_rotation: 15000' for SSD drives. Is 
disk_rotation enough to specify a disk performances? don't we also need the 
size of the cache ? we would better talk about bandwidth if we want also use it 
for ssd ? Maybe Bottlenecks project can help us.
3. 'features: dpdk|sriov' vs 'features: dpdk, sriov': it seems to be a 
collision between PDF specs and the yaml one. If it is a list we should 
simplify the installer parsing by using a yaml list: [ x, y, z] or a dashed list
4. 'features: null' vs 'features: ' vs omitting it altogether: 'features: []' 
or omitting; the first is yaml compliant with a list, the second is to simplify 
the pdf.
5. inconsistent node naming: in my opinion, this part shall be reserved for the 
ops, it is the only way for them to map a node with a physical server in the DC 
(except the ipmi address that is not the simple way to find a node). All values 
shall be authorized, but recommandation can be made on 'pod-')
6. Address/netmask: isn't netmask information in address overlaping with 
net_config netmasks ?
7. 'os' in POD nodes: Only in jumphost
8. IPMI interface MAC on the 'interfaces' list: no, it overlaps with 
remote_management/mac_address and is not seen from the os.
Thanks again for this huge work of listing all pending points.


BR

David



--

David BLAISON

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

[Alexandru Avadanii]

+1 for the tag prefix.

How about adding the architecture to that prefix?
e.g. opnfv/functest:x86_64-release-5.0.0


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alec Hothan 
(ahothan)
Sent: Wednesday, September 27, 2017 11:01 PM
To: Jose Lausuch; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

Jose,

I am fine with using the “release-” prefix instead. Any prefix can work. If we 
want something shorter: rel-5.0.0. We can leave that decision to David.

Note that what you call “none release” can actually be as important for project 
owners than those with the prefix ;-)
Looking at the bigger picture, the official releases are just a culmination of 
a flurry of non-release images in the CI/CD day to day work and chances are 
that some of those non-prefixed releases will end up being used by other 
projects than OPNFV releases.

Thanks for all that have voted so far!

   Alec




From: Jose Lausuch mailto:jalaus...@suse.com>>
Date: Wednesday, September 27, 2017 at 12:17 PM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisco.com>>, 
"opnfv-tech-discuss@lists.opnfv.org" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Cc: "MORTON, ALFRED C (AL)" mailto:acmor...@att.com>>, 
Raymond Paik mailto:rp...@linuxfoundation.org>>
Subject: Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

+1

What about using tag "release-x.y.z" instead of "opnfv-x.y.z" since the name 
“opnfv” is already included in the image name? e.g. opnfv/functest:release-5.0.0
This way we differentiate between an official OPNFV release artifact from a 
none released.

- Jose -




On 27 Sep 2017, at 20:00, Raymond Paik 
mailto:rp...@linuxfoundation.org>> wrote:

All,

Please let Alec know if you have any other questions/feedback on the proposal.  
The plan is to have a quick vote on the TSC call next week (October 3rd).

Thanks,

Ray

On Tue, Sep 26, 2017 at 5:38 AM, MORTON, ALFRED C (AL) 
mailto:acmor...@att.com>> wrote:
+1 and thanks for the proposal, Alex!

Al

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Frank Brockners (fbrockne)
Sent: Tuesday, September 26, 2017 4:44 AM
To: Alec Hothan (ahothan); 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

+1 – per what Alec mentioned below, the new tagging scheme is only a small 
change incremental change from the earlier plans, but offers a lot of 
flexibility moving forward.
Frank

From: Alec Hothan (ahothan)
Sent: Montag, 25. September 2017 21:34
To: 
opnfv-tech-discuss@lists.opnfv.org
Cc: David McBride 
mailto:dmcbr...@linuxfoundation.org>>; Fatih 
Degirmenci 
mailto:fatih.degirme...@ericsson.com>>; Frank 
Brockners (fbrockne) mailto:fbroc...@cisco.com>>; Tallgren, 
Tapio (Nokia - FI/Espoo) 
mailto:tapio.tallg...@nokia.com>>
Subject: [opnfv-tech-discuss] urgent euphrates git tags vote needed


I would like to get a quick vote from any person that works directly or 
indirectly with code in OPNFV

Please reply with -1, 0 +1

For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”

This is a slight change to the plan on record (which was to use “5.0.0”). This 
does NOT impact euphrates deliverables for participating OPNFV projects (git 
tags on stable/euphrates are applied by releng).
The only externally visible effect is the naming of container tags for 
Euphrates official images in DockerHub will be named accordingly (e.g. 
“opnfv/functest:opnfv-5.0.0”).
Everything else remains the same.

If you’d like to know more, the rationale is described here: 
https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
 (thanks for Fatih, David, Frank, Tapio for reviewing)
In a nutshell, this adjustment is needed to prepare the path for proper 
continuous delivery support by projects.
Any clarification/questions/discussion can be done over email or at the TSC or 
release meetings tomorrow.

Thank You.

  Alec



__

Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[Alexandru Avadanii]

Hi, David,
Fuel now pushes Yardstick results too [1]. The results are not filtered by arch 
yet.

BR,
Alex

[1] http://testresults.opnfv.org/reporting/euphrates/yardstick/status-fuel.html


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Tuesday, October 03, 2017 3:33 AM
To: TSC OPNFV
Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Updated installer and scenario data after the weekend:

Installer Summary (changes in red)



DEPLOY ON EUPHRATES

FUNCTEST DASHBOARD ON EUPHRATES

YARDSTICK DASHBOARD ON EUPHRATES

APEX

yes

yes

yes

COMPASS

yes

yes

yes

DAISY

yes

yes

n/a

FUEL (X86)

yes

yes

no

FUEL (AARCH64)

yes

yes

no

JOID

yes

yes

yes

Scenario Summary

Total (listed on scenario status page and found in Jenkins)

45

Pass Deploy

58%

Fail Deploy

36%

Not Running

9%


Functest results

58%

YardStick results

42%



On Fri, Sep 29, 2017 at 7:50 PM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
TSC Members,

As you know, the Euphrates release is scheduled for Oct 6.  In advance of the 
next TSC meeting, here is the status of the release. Let me know if you have 
questions or comments.

Installer Summary



deploy on euphrates

Functest dashboard on euphrates

yardstick dashboard on euphrates

Apex

yes

yes

yes

Compass

yes

no

no

daisy

yes

yes

n/a

fuel (x86)

yes

yes

no

fuel (aarch64)

yes

no

no

Joid

yes

yes

yes



Scenario Summary

Total (listed on scenario status page and found in Jenkins)

45

Pass Deploy

47%

Fail Deploy

42%

Not Running

11%


Functest results

49%

YardStick results

38%


Major Issues

  1.  Chinese National Holiday.  There is a Chinese holiday from Oct 1 - 8.  
During this period, there will be power maintenance in the building where the 
Huawei lab is located and the pods will be offline.  
(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-September/018333.html)
 This will impact the Compass and JOID installers, as well as all of the 
projects that depend on those installers. The Yardstick project will also be 
impacted by the Huawei lab outage.
  2.  Intel lab firewall reconfiguration.  The status remains unchanged.  In 
the mean time, the LF release engineering team has identified a workaround 
which could be in place by Monday or Tuesday.  The main impact has been that 
the Apex, Compass, and JOID installers have had to shift builds to an alternate 
POD, thereby reducing capacity.  In addition, the VSPerf and KVM4NFV projects 
are without CI support.
  3.  Docker builds.  See 
RELENG-315.
  With the increase of the number of docker jobs in Euphrates, there have been 
a lot of failures due to timeouts.  This has been partially resolved with 
additional capacity and improvements to the script, but remains an open issue.  
This affects any project that requires docker builds, such as StorPerf.

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[Alexandru Avadanii]

Hi, David,
Michael is currently on vacation.
The results were looking good yesterday, but meanwhile the history seems to 
have been cleared, probably by a recent change in the script.
I will try to identify the rootcause and ping the proper audience.

BR,
Alex


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Thursday, October 12, 2017 7:01 PM
To: chenjiankun
Cc: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Alexandru Avadanii; 
Michail Polenchuk
Subject: Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

+Michail

Thanks, Jack.

I see the test results pages, but no results.  When do you think that we'll see 
results populating the pages?

Also, the deploy results for fuel@x86 do not look very good:

os-nosdn-nofeature-noha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=qoM4u3Nklz6CopZyL4WNlD0atBXabbInclTGDbhnGpTolUJCO45XEhuFgb0tIpEiFd4tfX6rHC0f4GZ5d2TAQfZAfYWppyV6c6UPpMOELctJOG6YsSxzWx5a-Rf2N5V5N2HRvTBOJfTb2AOXPr3Huq_uzjmKvXLyZzxLAAgKozGhkhYm0C0cB9xYnM5Rtf4DhV_tlrn2pAdt3_f-M0xBC2jb3VHhf7_8oxPNUEjI5dx5EdAWPUNSvshhauRddLf0P4ajoGVHX2WWk9FZRQWB2Hq6qNTT1G25RT6a62p50RMDC3mbpV0jVhteeYCOkrcT>

not running

os-nosdn-nofeature-ha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=_pHw3RCs9YJCmuMBdmSY6AxAxj82FK1p-5kWohZASMKXjKBpk5AqKXZ5ggxFQnB0czm5ref7xnWs8ziuHTM9p3wxGT0LYzE-4Wy7EOE6OiX-pRCIPAUX_cGSDJfvb_HsbcWJmJrmCAzAjsWSkkWQmrNRsfnOFLtP4O5_HdaEMNFHbf6XU0Ava8fuSktRgXnsqHxxgjC7-Zo_1pP9221PBDzGNu0Q9DZ_wbv13BirIPTbIZnd83zdgLJJmtVMU3gUO5KXlg2mB4Y7TsseTSXDlpnlobMAjUbUu_WH93r4aQ0>

fail

os-nosdn-ovs-noha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=0ppagEQFQ3-X1YTGUEkQgwc1CtFBEKjlNjZBu_mXCAj8sbp30rhmS6dqCa8RxJgg-GTnvpDdD59HoKz3d8mJl_9qzPB6gp5XOeufRACdvDNfXfJHuTSwS6koNKR-KeYF2TpksAElbVsBJdKTYQMUGvjCJPwEYciKQRinqNeIi6ixm9U3w-RUnJ40f2W4kqgA280khD-js5gQPXDS9XyI1hFJzLhjF-KnSX8eUmtNHgTYtaIbvRhwzZ7Fhqh7uRIDXAuMVUBo7jCrQsBDZ26hO0ldpvivhAuSQ9OmHRTP22Y>

not running

os-nosdn-ovs-ha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=Nvdjoh_7CuVh_ClB1vgASPngOTcaMWUnyQVtiJOF9HSJnezKzAiD2WRGhaSvmcHj3W-rS_Qbz4O6boPnxbEbK4c-SsqVOSY9A6SyFx0mLCCHSVNvUka0B18xYIuDiQWqehkpEMAkDSLKiBthkFb-opjZA4aDWHbKYGx1VjEreMfbP7mMw4nBjBiTwfHPdDcEOvD6yEEJa-aj61qDJU7Uou54QkFW6lOdmS4MvI73bCwLS52CAKPesHzRU1x5juHsJqgD38vH-6W6aDlOpDHGTr5RjbpG_8extACn2jsR9H0>

pass

os-odl-nofeature-noha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=XyPdH4_8po7LVJGdjI7LCLXlq7XSp1RoGh9niFKXdzkKDcRP9ZBX6nFuPlDlfqRGY4mAZYRqSk-jbOhIh0Xkz3YF56A_8Rkh9PrfPNUT6tcMEI4YjhxJIeEqhPNMt--ZS9jAIJXfsxL7KSohbT5M4DL-_wi40EkqFwUoa6ui_-24lYZzWL2Aa8MIS23VUrOAaO8xUC4LlQC_yOQIwnUKr6gvDWvZfjP_wMJMc6407oIP8EoicQzkeBoM02lF3joOqQRkkqiPf3lemj61Ft9TdNuJ5x789YcS-i8TEuqRKqE>

not running

os-odl-nofeature-ha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=eaGvkmvcE3DruK_CYIbQiWq9xrQcTPNxWJ2thOUn8sVwD9wSLzvYEBx4qqd9_jsATQwYnXNkbMAPIjR_bPMmTw6FXcEINdYsxef9t7PisKbEjCDWRvpBEm74K86SLdj0e4oHvxt19GDg1Xw7i8V1mru5PAAW2iqEoEy9KiVewRcL-AJY7rWWWcveEdUY9E-717NbRL6xjACmelkFZFPFfQpdNFw7qvwKhCSOmPTPZKBhVvZW7Ir7Z0voCVwJjTd37vfF93UIxusTs7D7ovc-5Xd8isoUJxh2qImD4zJ-h-k>

pass


On Wed, Oct 11, 2017 at 6:32 PM, chenjiankun 
mailto:chenjiank...@huawei.com>> wrote:
Hi David,

Fuel x86 and Fuel arrch64 page are available now.

See:

1.   
http://testresults.opnfv.org/reporting/euphrates/yardstick/status-f...@x86.html<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=cyOCbT5lyHS-_MxGtuWwc075qKkNuh8kJEkQW2_dzQmAej6ZxFNDegF4ZL9y8XlIliakrDuJNDggS1Qaca3h5b9QgHUtkmX6OJ7C_ZPKfyHxU76iB65Q4rW6nWQamZbLt5BkM6BJralwELoHlnd-WtSpcmXr8YLGdM0GGp5k2Nn4LsrYvXujdeSS63QjkKGZlnWFeSKMYJTWPrJ2PUwqhX21d49T6wjwnTBL-GIRtxI4HQLHX8PfZ6U5FLku749B4km9BvG1jv3YqI9VTanqf6-cC7ODkoVXAwdrUTcJ9N0>

2.   
http://testresults.opnfv.org/reporting/euphrates/yardstick/status-f...@aarch64.html<https://url10.mailanyone.net/v1/?m=1e2fw2-0002hR-47&i=57e1b682&c=K03oVT4HbPtuETAftZiBQjQx2rHpUwJrlat8XnGr5J-uQULSkunzuE6lMvb70pj082jsZMcHAKO3lNrDkuQ7fUSeEqMyGgqNrp3jo0DgSGi-a-UQtIb6XHWtxWbyIkz4UhwcNyIWftNxUy5ti2IslNp4_4bM9-NSCzzqTT4ujic4h8GcYFl-9sUwnYnD99GYKSXWPAZOXvUt5S19UTGIoCEY5YI_Z7xz2b4gnOoBphjK58WDs4X-OJnIBgRoqdb3tDIrveF3sAJaLSiswff-6bbMeynJYkHqk4lg9GnDcUQ>

BR,
Jack Chan

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 代表 David McBride
发送时间: 2017年10月12日 2:59
收件人: Alexandru Avadanii
抄送: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV
主题: Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Alex - thanks for the 

Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[Alexandru Avadanii]

Hi, Jack,
No problem, thank you very much for fixing it so fast!

BR,
Alex

From: chenjiankun [mailto:chenjiank...@huawei.com]
Sent: Friday, October 13, 2017 4:40 AM
To: Alexandru Avadanii
Cc: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Michail Polenchuk; 
David McBride
Subject: RE: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Hi, Alex,

Sorry for causing trouble, since the criteria field in DB has been changed 
yesterday , so the result is not accurate.
And I have done a quick fix in testresults.opnfv.org, see:
 
http://testresults.opnfv.org/reporting/euphrates/yardstick/status-f...@x86.html<https://url10.mailanyone.net/v1/?m=1e2oxW-0007An-3Y&i=57e1b682&c=Cx7mdRsHezHdqoAhGPHFaW9grB90U_NMWwef5yov7VJmofeglsZGDoslYHNkwCdNSzQ5FOKa4BVi_JgRZVpVVrKpPRSl554RmfKddaWTRKqK-59pju7QNmr-x-iNcGVf2sjvkE1KSmQgbL_yYhL-6NFVeveQttUBg-jnyYd_58VAVoZdV3PokSerKemcZ-uA2h4iqTEgnklXqmRecOdwVKOTwicIFdIAsy3QSMfFmfz1oBnoeMRz5TW0jKyu-z3zZoyQbwSXAkcDv36mKuWuw-yH17StRIBNGMTBgCys9Cw>

For the history data, we still need more days to see the trend.

BR,
Jack Chan

发件人: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
发送时间: 2017年10月13日 3:42
收件人: David McBride; chenjiankun
抄送: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Michail Polenchuk
主题: RE: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Hi, David,
Michael is currently on vacation.
The results were looking good yesterday, but meanwhile the history seems to 
have been cleared, probably by a recent change in the script.
I will try to identify the rootcause and ping the proper audience.

BR,
Alex


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Thursday, October 12, 2017 7:01 PM
To: chenjiankun
Cc: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Alexandru Avadanii; 
Michail Polenchuk
Subject: Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

+Michail

Thanks, Jack.

I see the test results pages, but no results.  When do you think that we'll see 
results populating the pages?

Also, the deploy results for fuel@x86 do not look very good:

os-nosdn-nofeature-noha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2oxW-0007An-3Y&i=57e1b682&c=nVioiuGqOnjaGFkgK9INN_1IxwtwgfZGYvQJ01S_aX1_qFHw7yPKX3Z95q2z4KRmmb1CioYRQLUihzT2bJeaO7dmt18DIE5POYZkAZD6GEmmNBX6moRd3WSBjTybeZjj5bVm8sTlK0tKWefDmNOha_hvU8XmNNsAxEymWo7g8bGuBINALSqVEu1cSPYxyCfEry1ghtOYjM7sPmu-gkFzKdUViw9lA85835KKJtxHKp7HtQAPGtmTcDnSWhiha_2tAkiDOZ8cLxNL6230OMsnmiXridtE1-8zgw8-XPlaNVzWWnZIjHP7aFpuY7uDly0KfFObPLuv0e2rwuXIsJIDfkJ9obD9J2c3ggHMGiFHy_NezVeLcVCP2qeT8YTnRYCVH0nF6WEDXDBjMbmwzaQmLczKjCKgBISUmxDK_wtnWwht6BrqyKFVCn_1qXjzVql5RidefwrmcTAyLv4yyucOuHWXl-FPucK_LfT7SCzrsiEUqmSdkZWB6FVGSy0dzDIBlunkXKzODY1zkz3TfWdEsFJaCjRw2T_jnS261BhLDxw969k-wFlTo4TlBJqx0Cj2Pd58P3EDfXyd0c1yr1DcAbcIh8t-9ZLFALGfSCEP8yJIk6doYZsG7iZ3uhc8e3HUthz-6JCbcoN5kCtW790t7CTnMA_CTFnCLPMRTSkmGluucVs1nMqFrYqnGTxl0K86>

not running

os-nosdn-nofeature-ha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2oxW-0007An-3Y&i=57e1b682&c=0OqJLsVsrnvEVFwdNb2xMr1DIO_KcDQob-wmbBE3l768EzbUw8V5EC5dT1AgxK_vU1lNo7zJaGG6evIrktNzsgWhdcwVgh93jb-b2015TZOn_GQQ12x-O8wbADuzLrYnsbhaSifR9L7Yzw4SZ8YJ9cE4OO9U_MbyAmVhJcg3RmcFYINlainzJDUj_Nn-3wXTOkG7aNU5S6xL3RBkYimuXNDz-HrCV9HrMDWth5NHAOzkWgrWC-39jEHFQ25pehaORRxv7OIkLSC6_e9u29vtio-h3aajC2yEKQ1fzjMwYsp8l-hqirjv5tUO8Kh82B2RCWEZSFPtO2Nw8avta2RaEvY0oLWwx_tqKI8Fyqse3D4-7MwkuHRKtzRRoXuXGjDBNXiLvUtM_Y4y3P_8le_sHaZEBR6vgI6Fl1Ddb1_GYYf96nAx1Xc58RtHbzKtA0TanidMWMXzlNSSyCrlTmgDE2s2LpcANJYv1namA_-dIoU5siCwEE49q_5OH1mrp28iXJzWBqqG6nZKyjer_h6xsKZWK4DjkuKmkVT7kXden0-yC_VzhyceXlt3hX06bwmFLUshDbiv_Oh433YzH93aWIuP6gEJA4Cm50qFXgjEm96YkPlOuplMba51092A50YAD-sHFFAShiY2EjK_fzUIGb0wnofxoc_-WUl0vwMzVoo>

fail

os-nosdn-ovs-noha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2oxW-0007An-3Y&i=57e1b682&c=rt_wnFk-fgzfQ8ZuMeY_JSZUmuBXEWNO18w3_W3AX5PLqTqIfu3LPoSzkmosg189RoNIwajmRljPpGanZcFfWq9em5jUKc3KHotj4J9c7vKh-VIq79S5EYwhM-uTHnF8M7BEFemVoQMGmnXBxRBvYhbwJCjl6vX6CiOUxC9XqEXyN3edZXBWiYI0B7kK29FFgdssG_3QSa1psduuoTOANZSY2t69nHG4teYgg3SdAeeMJq9OEfYKCOA4cMwF88gwLbxhNte29XY7vPBbPsGN4tW-AI2po-f4X2DUYYhLufA16aD2I_hB2oVaYzvaWh2IK2sZLGcCWGLkVgKYehQlGvlzt7pau2s3qbFdNcKYzr2DvzMR7n4kmzJXV8j3THN8IkFWzTT0jLowVjRrweQROJ_syi1C8_DCNxLvTYzWaj7e9Ou3wbv8toICiPNrH0g3Tzmdm4F3BAOv0XH039WkH_octcHajcR2tJ2FmiwbEgW026QyaRrmbv3Ckybi6KquUGmseOJC8u6qZqbH_uJ0p-hu7640QLO2M6T7rSUVcxMRiEJ_Q-2tSYjBcybZrss5l4UsBv6p6OiJirwNAM5vHdG7iK9w2LuxTrid5FDX3427rrGKgWt60HfI8L_sUkPZlzjLUb60a3hEuGpX0o_GTnWK7bd_MkojXe9XZgs8MsA>

not running

os-nosdn-ovs-ha

Fuel/MCP

Michael Polenchuk

link<https://url10.mailanyone.net/v1/?m=1e2oxW-0007An-3Y&i=57e1b682&c=YzTk6fGU4VfHIe9ngEXRz8bo4-9oM_ct9FRujMXani6Vmq4aRPHTNIWQHYLilhKAXabJODHG-qOI-PiTlHO2kzhRFLiTO2bPQIMryYSO2Rx0O1RpxrBs2xYCQCT2p5lBMII_OnicLin4V_NeF4S4l5fvwwYGT2nr4XBJQgCIPVjTq3d55swsbyK63Ee1-vvpLMy-z9oycUoGEHr3Y8sKsz9JqASK4N4ixqLqxFn_fiKP-BjqT1Zyu-f7

[opnfv-tech-discuss] Arch-specific Docker tags

[Alexandru Avadanii]

Hi,
Cédric pointed out that Docker uses DEB/kernel format for describing the 
architecture of a Docker container.
To align with this, the Functest Docker tags were updated from 
"x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".

Although the arch-naming convention is not enforced to this format (as long as 
the manifest points for a specific architecture to a specific tag, that tag can 
be named however we want), we agreed that aligning with the Docker internal 
format would be a good idea.

My personal preference would be to duplicate the tags, and have both 
"x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" 
point to the same image.

Anyway, I think we should agree on a format at the OPNFV-project level, and try 
to use it for all our projects.

So, for multiarch projects that push Docker images, we have at least 3 options:
1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used 
by Functest);
2. "amd64" + "x86_64" / "arm64" + "aarch64";
3. "x86_64" / "aarch64" (currently used by Storperf);

Note that if the project provides a manifest, arch-specific tags are more or 
less hidden from the end-user, and a simple `docker pull 
opnfv/functest-core:latest' (or without a tag) will fetch the image for the 
current system arch automatically (amd64-latest or arm64-latest for Functest).

Thank you, Cédric, for handling this for Functest on such short notice!

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

Re: [opnfv-tech-discuss] Arch-specific Docker tags

[Alexandru Avadanii]

Hi, Alec,
Thanks for the vote ☺
That is exactly what Cédric implemented for Functest, using manifests.

If we are not to duplicate tags (i.e. choose between #1 and #3), I will vote 
for #1 too.

From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Friday, October 13, 2017 9:57 PM
To: Alexandru Avadanii; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] Arch-specific Docker tags


I would prefer limiting the number of container images because we’re going to 
have a lot more image versions for some projects (to tackle versioned XCI/CD)
So option 2 does not look great for me.
I’d vote for option 1.

Have you guys looked at support for multi-arch docker images?
I find it really interesting and removes the need for an arch specific tag.

http://container-solutions.com/multi-arch-docker-images/<https://url10.mailanyone.net/v1/?m=1e358n-0004uA-3x&i=57e1b682&c=v3NqsmA4oOaPES_DLL6t7dyxSrm7d5AULjcFb_OIPvl_3SZaZrk66SO1eqppDx7CWAT_GtmEPROYGzJdyOQrNOCORSlFqm8Iry0MjKu-tWcLNKady4rxdEay9pP3uJt46D9jTSOf0b9ayuhbj1m6X4PIlFQh-LyULrxVQiHoey84NH2vBcuRT9GhXjUyv31BqfS01owB-5bpGcDmOfYsemcguMbvFUWP1ohHVeypxPKgAm_EqxY3rVYkf5GY1OUb0OxNJ0_YfjpFrr1G85b-Jg>

If we could implement this, that would be even better.

   Alec


From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>
Date: Friday, October 13, 2017 at 10:04 AM
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] Arch-specific Docker tags

Hi,
Cédric pointed out that Docker uses DEB/kernel format for describing the 
architecture of a Docker container.
To align with this, the Functest Docker tags were updated from 
"x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".

Although the arch-naming convention is not enforced to this format (as long as 
the manifest points for a specific architecture to a specific tag, that tag can 
be named however we want), we agreed that aligning with the Docker internal 
format would be a good idea.

My personal preference would be to duplicate the tags, and have both 
"x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" 
point to the same image.

Anyway, I think we should agree on a format at the OPNFV-project level, and try 
to use it for all our projects.

So, for multiarch projects that push Docker images, we have at least 3 options:
1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used 
by Functest);
2. "amd64" + "x86_64" / "arm64" + "aarch64";
3. "x86_64" / "aarch64" (currently used by Storperf);

Note that if the project provides a manifest, arch-specific tags are more or 
less hidden from the end-user, and a simple `docker pull 
opnfv/functest-core:latest' (or without a tag) will fetch the image for the 
current system arch automatically (amd64-latest or arm64-latest for Functest).

Thank you, Cédric, for handling this for Functest on such short notice!

BR,
Alex
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss<https://url10.mailanyone.net/v1/?m=1e358n-0004uA-3x&i=57e1b682&c=UY3TAM5bKeqyCCv7HHLPmDnamGl4N6rgGT00k5zrg--WErVwEdC55nSbLF1gDLFJw8xSI6p36Rc-XFzz1DtAq266_cZdPdAB5ghBhVYeJ3DTf2kn4asauyOKCOYMiV1tG-uOfO6e5MleVBfzLSZFTfnSUdBF3tWBQaMQiNtxRWrOBZXb92Pel4hrwvP1qVMiUIlJ5XgJ5_xh6aHB4ZxH4YTSxwifJWbyeUzXPT_aWLsyyAgBLUPv_L2URIpYLmzTrev4QzkSP-aMNHiZ7JoTCA>

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

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

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 mailto:jack.mor...@intel.com>>于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&avatarId=10303&avatarType=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 
https://gerrit.opnfv.org/gerrit/#/c/36977/

[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

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 n

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

[Alexandru Avadanii]

Hi, Julien,
We have 2 PODs that rely on PDF (+IDF) currently:

-  lf-pod2 (main Fuel x86_64 baremetal CI POD);

-  arm-pod5 (main Armband Fuel AArch64 baremetal CI POD);
The current securedlab contents are up to date (both master and stable/E 
branches).

However, note that this is *not* enough to unblock MCP on those PODs because 
interface names are not yet described by PDF or IDF, so they are hardcoded to 
lf-pod2/arm-pod5 defaults in the reclass model. This is something I want to fix 
asap, but it requires agreeing on the PDF/IDF mechanism to describe the mapping 
between interface index defined in PDF and the OS interface name.

I will announce it here once we have a PoC for the network interface name 
mapping.

BR,
Alex


From: Julien [mailto:julien...@gmail.com]
Sent: Monday, October 16, 2017 3:26 AM
To: Alexandru Avadanii; Jack Morgan; opnfv-tech-discuss
Cc: Guillermo Herrero
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

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 
mailto:alexandru.avada...@enea.com>>于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<https://url10.mailanyone.net/v1/?m=1e3tEM-0002Oz-53&i=57e1b682&c=JNWyTHJG6tCUjaHK3S8C-tI6CECSrF9Ycp6zCu-iTdolUeo9zaskEzCVe4UTOIVUJHrRZM_JIikcJUsPu4j7-Cwbqbk_RMG5N08mw21_KL-WHqd-WbnJ10Fllqpdgc-HrLvxXlcVkhCRH2wICI6M9WAhVY5KtvcUWT8A5GvhdzYsw-_BPDj5S8LQWy0NbrJpQmHfiy0j9iqASwTvfKXuXvDwEQP5quc-KyJkCS-j9Ogl7Gddi-tYYful4XKD5_JZ4Tq4xHkzjZt8G_WUYxAL9Q>


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: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 mailto:jack.mor...@intel.com>>于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<https://url10.mailanyone.net/v1/?m=1e3tEM-0002Oz-53&i=57e1b682&c=d-S2Ejp3NYpn6oPLD-w-Q59JMRUwkMfg0UvKM09d_cJDEgCaDjiC_RBmMk9GoEWPHjKg7ufUtlPSUi49ZeN0UyM1OJ59HPrM9nWVM6ZbsWR5MNlU_hKfvo8CijFBqxvehRzQdU6eWZeOsJY1ZT7bwh3M2WcMmWooetayacU2pR4B0RuSTfedmVLByJGRmGuVZBmVr5TJliIFM7PtNWrnp0ferlvb4VI4Pgq2gMTF_Gl_0e9hne0pu8wRqfPLQrs5hH9ULn4_K5i2TVRBwTRHN09GrqMg7z2eEjfHhMxMUWUHkuz-7IM5Lmd8-3XJ2fJ2sRbmCQWr2BwzEF8dsRAOb6We0sUv4H2qZAnuCJ1P-KERNpn5GlHUgo6XDG9uSf1J24YQg-g97RBwdntBSGDoFa5-ixMQ0zD-ymONN8nEo8x15kIe2W7CLAewMlyEURnuj5CBsV9B-fzEdN6B-pAm9fY8iYd6jSbzFkohFOs2UBqrwSYAjBWMqGBEW5COROioVu1xZlZ4FhxT8B1MeGrY2cxsaVc1lgnnMt46UAyJvbHZ4RfNfjYwIa4JBwbmEAYy3viodAbW1gqJAaOfd5OWgb3MQD23nn-Alg3TupO5Kio>
3.Infra documentation on RTD - patch 
40329<https://url10.mailanyone.net/v1/?m=1e3tEM-0002Oz-53&i=57e1b682&c=J4m98YtaRuHdcev2MhdWTZRPd9S4C7RJsmzs8SAciSoXMPAnKCkVv-UjVGXNJpIFPgoEJJm7NANnG_ldwxCOYmdDG

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

[Alexandru Avadanii]

Hi, Ray,
It’s hard to say whether this will continue beyond E release.
Meanwhile, we will keep the docs dir in Armband, like we did in previous 
releases.

BR,
Alex


From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Monday, October 16, 2017 6:26 AM
To: Alexandru Avadanii
Cc: Sofia Wallin; David McBride; opnfv-tech-discuss; Cristina Pauna; Bob Monkman
Subject: Re: [docs] Fuel and Armband merged documentation

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 
mailto:alexandru.avada...@enea.com>> 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] [fuel] [armband] Full network parameterization using PDF/IDF

[Alexandru Avadanii]

Hi,
I am happy to announce we finally submitted the final changes for PDF/IDF 
support in Fuel.
We have been using PDF for a few weeks to describe most of the hardware 
parameters (IPMI credentials for cluster nodes, network VLANs etc.),
but we were lacking support for dynamic configuration of interface allocation 
(e.g. mgmt VLAN was always assigned to the Xth NIC, tagged; public was always 
assigned to Yth NIC etc.).

For those of you who have securedlab access, the IDF change, adding some new 
Fuel-specific params for lf-pod2/arm-pod5 is at [1].
For those who don't, we also provide a sample IDF in Fuel@OPNFV, which is 
basically a copy of lf-pod2's IDF.

The Fuel code consuming the new data is at [2]. We can now model any 
arrangement of tagged/untagged, vlan or physical interface configuration.

This means that soon after the release, we can start re-enabling all Fuel PODs 
that did not align with the lf-pod2/arm-pod5 hardcoded setups (ericsson-pod1, 
zte-pod1 etc.).

To summarize, here are the PDF/IDF requirements for Fuel:
- PDF (as per Pharos specification), including net_config section (which is not 
part of the spec yet, but it doesn't collide with it either - see sample [3], 
which is basically lf-pod2's PDF);
- IDF - we don't depend on the shared section (yet), and the Fuel-specific 
section is quite lightweight and self-explanatory - see sample [4];

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/45587
[2] https://gerrit.opnfv.org/gerrit/#/c/45427
[3] https://github.com/opnfv/fuel/blob/master/mcp/config/labs/local/pod1.yaml
[4] 
https://gerrit.opnfv.org/gerrit/#/c/45427/4/mcp/config/labs/local/idf-pod1.yaml
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Alexandru Avadanii]

Hi, Alec,
If all you want is one commit on the stable branch, you should look at 
squashing all commits from master into a single commit on the stable branch.

Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alec Hothan 
(ahothan)
Sent: Thursday, October 19, 2017 1:31 AM
To: Trevor Bramwell
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates 
with gerrit

Hi Trevor,

Thanks for the tip!
If I am not mistaken that will result in as many commits in euphrates as there 
are commits to cherry-pick from master?
Although you achieve the same final state in stable/euphrates you do end up 
with potentially significantly more commits than a simple merge. I think it is 
best to keep release branches clean and devoid of unnecessary detailed commits.
I was just looking at the functest repo and they do have tons of small commits 
in their release branch, which is the result of multiple cherry picking.
In my case I have well over 40 commits to merge into stable/euphrates so that 
requires as many gerrit reviews and result in as many commits on the release 
branch (I only need one – not 40+)… ;-(

Is there any objection to allow merges to be submitted in git review? They 
should be reviewed equally and can be accepted/rejected by committers.
I think this requires adding the “Push Merge Commit” access right for the 
“refs/for/refs/*” reference in Gerrit.

See gerrit doc at: 
https://codereview.qt-project.org/Documentation/access-control.html#category_push_merge

If we want to allow all projects to submit merges to gerrit (such as syncing 
master to their stable branch), we’d need to enable it for All-Projects:
https://gerrit.opnfv.org/gerrit/#/admin/projects/All-Projects,access

I think that will result in “cleaner” stable branches.


David and all: note that this ability to submit merges in Gerrit (sync content 
of one branch to another) might be needed for XCI if we move towards the use of 
a long-lived “stable” branch (a branch that contains only stable commits off 
master that are validated for XCI usage) that sits between master (which 
contains all dev commits subject to each project CI but not necessarily vetted 
for XCI use) and the release branches (which contain only release material and 
would then be branched off the stable branch). The benefit of this extra stable 
branch is you can effectively run CD/XCI anytime and well before release 
branches are even created.
I’ll try to send out a diagram of how that branching model works out with CI 
and XCI.

Thanks

   Alec






From: Trevor Bramwell 
mailto:tbramw...@linuxfoundation.org>>
Date: Wednesday, October 18, 2017 at 3:04 PM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates 
with gerrit

Hey Alec,

Here's a quick way to cherry-pick these all over to the stable/euphrates
branch. Though you'll still need to submit them all through Gerrit:

  git checkout euphrates
  git cherry -v stable/euphrates master | cut -d' ' -f2 | xargs -I{} git 
cherry-pick -x '{}'

'git review' will ask you to confirm you want to upload multiple
patchsets. A 'yes' should put all of them up for review.

Regards,
Trevor Bramwell

On Wed, Oct 18, 2017 at 08:14:59PM +, Alec Hothan (ahothan) wrote:
I have many commits in master which I’d like to merge to stable/euphrates.
Would like to check if anybody knows how to merge master into a release branch 
using gerrit?
Looks like I may need the permission to upload merges with Gerrit.
Here is what I did:
$ git fetch origin  stable/euphrates:euphrates
$ git checkout euphrates
$ git merge master –no-ff
# at this point, so far so good, I got all my commits into my euphrates branch
# git review fails due to permission:
$ git review
Warning: Permanently added '[gerrit.opnfv.org]:29418,[198.145.29.81]:29418' 
(RSA) to the list of known hosts.
remote: Processing changes: refs: 1, done
To ssh://gerrit.opnfv.org:29418/nfvbench.git
! [remote rejected] HEAD -> refs/publish/master/euphrates (you are not allowed 
to upload merges)
error: failed to push some refs to 
'ssh://ahot...@gerrit.opnfv.org:29418/nfvbench.git'
Is there a different way to achieve this?
I do not want to cherry pick my commits as I have too many of them.
Thanks
   Alec

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Alexandru Avadanii]

Hi,
Not really. A squashed commit will be just that – a single commit, optionally 
keeping the commit titles and/or descriptions of all the patches, but no 
further code separation.
It’s basically one big patch, with all commit metdata concatenated.
If you are after a link between the commits on master and their counterparts on 
stable, this is clearly not what you want ☺

BR,
Alex


From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Thursday, October 19, 2017 3:35 AM
To: Alexandru Avadanii; Trevor Bramwell
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates 
with gerrit

Alex,

Ross has proposed a method using rebase, is that what you are also proposing?
It is still not quite same as a merge (see my reply to Ross).

Thanks

  Alec



From: Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>
Date: Wednesday, October 18, 2017 at 4:20 PM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisco.com>>, 
Trevor Bramwell 
mailto:tbramw...@linuxfoundation.org>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [opnfv-tech-discuss] [releng] How to merge master to euphrates 
with gerrit

Hi, Alec,
If all you want is one commit on the stable branch, you should look at 
squashing all commits from master into a single commit on the stable branch.

Alex

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alec Hothan 
(ahothan)
Sent: Thursday, October 19, 2017 1:31 AM
To: Trevor Bramwell
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates 
with gerrit

Hi Trevor,

Thanks for the tip!
If I am not mistaken that will result in as many commits in euphrates as there 
are commits to cherry-pick from master?
Although you achieve the same final state in stable/euphrates you do end up 
with potentially significantly more commits than a simple merge. I think it is 
best to keep release branches clean and devoid of unnecessary detailed commits.
I was just looking at the functest repo and they do have tons of small commits 
in their release branch, which is the result of multiple cherry picking.
In my case I have well over 40 commits to merge into stable/euphrates so that 
requires as many gerrit reviews and result in as many commits on the release 
branch (I only need one – not 40+)… ;-(

Is there any objection to allow merges to be submitted in git review? They 
should be reviewed equally and can be accepted/rejected by committers.
I think this requires adding the “Push Merge Commit” access right for the 
“refs/for/refs/*” reference in Gerrit.

See gerrit doc at: 
https://codereview.qt-project.org/Documentation/access-control.html#category_push_merge<https://url10.mailanyone.net/v1/?m=1e4yoP-0007GG-4V&i=57e1b682&c=Y2pED-uSssP9Z4rEFCe0GbAxMGPe3c7sFPiK2bcTTJh4S4P_PhgBow4WvF6Sl2NTg6UY_h921vh1viaDIygqPhRlKuWePkZVpGNIE6BXLULQIgH0j_TuGRVUvkdEOrOYXDVqHpmo0_0fHUHJbbYHT0VTarn4AsiK5osUlAZBzVXDKhM0hUfzsuFRgG1eRIezkJKG-MHl0W0KM1xEMmyg_hLJ2349m33CKEo3fk_gXQ80kk2n0ZEsDFv_XBPx8_uOSsALU24HxmdXkI8ahnRpswTzdXQNGbkKu0Bup9t2NjqRMhJNEO-hyzXbu3ZcMEy9>

If we want to allow all projects to submit merges to gerrit (such as syncing 
master to their stable branch), we’d need to enable it for All-Projects:
https://gerrit.opnfv.org/gerrit/#/admin/projects/All-Projects,access<https://url10.mailanyone.net/v1/?m=1e4wrT-0002ZU-4b&i=57e1b682&c=a2g_4BpDOQ6btXvlnpkYLPFIeukquaxWtcyeDVq81_1xDr8OjzcxllX6V7Ytwi-QhMo7t8bMkT68A8KiUPF5iSR23zwNbxBA4JvgMGKm4dHU8fOEVVT59mcuVcNhTRPvQ-j11cHBysQtSlPcOvyq4tUekYO4LgSi6kicOqfQe1Ja26HqUzw1obh59eTpE3fgnMVT7n4rcXKuH6BIh2t2iFt4yX2aqLog8MMqmK-wUF8yt2Yd2QdbP3hiKrRyWn4RUj-7jc3zyljcK7sXBSLPCw>

I think that will result in “cleaner” stable branches.


David and all: note that this ability to submit merges in Gerrit (sync content 
of one branch to another) might be needed for XCI if we move towards the use of 
a long-lived “stable” branch (a branch that contains only stable commits off 
master that are validated for XCI usage) that sits between master (which 
contains all dev commits subject to each project CI but not necessarily vetted 
for XCI use) and the release branches (which contain only release material and 
would then be branched off the stable branch). The benefit of this extra stable 
branch is you can effectively run CD/XCI anytime and well before release 
branches are even created.
I’ll try to send out a diagram of how that branching model works out with CI 
and XCI.

Thanks

   Alec






From: Trevor Bramwell 
mailto:tbramw...@linuxfoundation.org>>
Date: Wednesday, October 18, 2017 at 3:04 PM
To: "Alec Hothan (ahothan)" mailto:ahot...@cisc

[opnfv-tech-discuss] [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,
Fuel and Armband projects are pleased to announce the public release of
Euphrates 5.0 (opnfv-5.0.0).

Note that starting with this release, Fuel no longer produces ISO artifacts,
the only deliverable being the git repo itself (similar to Joid).

1. Fuel artifacts
Git tag at [1], documentation [3, 4].

2. Armband artifacts
Git tag at [2], documentation [5, 6].

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.0.0
[2] https://git.opnfv.org/armband/tag/?h=opnfv-5.0.0
[3] 
http://docs.opnfv.org/en/stable-euphrates/submodules/fuel/docs/release/release-notes/release-notes.html
[4] 
http://docs.opnfv.org/en/stable-euphrates/submodules/fuel/docs/release/installation/installation.instruction.html
[5] 
http://docs.opnfv.org/en/stable-euphrates/submodules/armband/docs/release/release-notes/release-notes.html
[6] 
http://docs.opnfv.org/en/stable-euphrates/submodules/armband/docs/release/installation/installation.instruction.html

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, July 14, 2017 9:49 PM
> To: 'Aric Gardner'
> Cc: opnfv-tech-discuss@lists.opnfv.org
> Subject: FW: Fuel and Armband Fuel Danube 3.0 ISOs
> 
> Hi,
> Fuel and Armband projects are pleased to announce the public release of
> Danube 3.0.
> 
> 1. Fuel artifacts
> Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].
> 
> 2. Armband artifacts
> Git tag at [2], ISO build logs [4], ISO [6], documentation [10, 11, 12].
> 
> BR,
> Alex
> 
> [1] https://git.opnfv.org/fuel/tag/?h=danube.3.0
> [2] https://git.opnfv.org/armband/tag/?h=danube.3.0
> [3] https://build.opnfv.org/ci/view/fuel/job/fuel-build-daily-
> danube/738/console
> [4] https://build.opnfv.org/ci/view/armband/job/armband-fuel-build-daily-
> danube/28/console
> [5] http://artifacts.opnfv.org/fuel/danube/opnfv-2017-07-14_14-00-12.iso
> [6] http://artifacts.opnfv.org/armband/danube/opnfv-2017-07-14_13-43-04.iso
> [7] http://docs.opnfv.org/en/stable-
> danube/submodules/fuel/docs/development/overview/build/build.instruction.ht
> ml
> [8] http://docs.opnfv.org/en/stable-
> danube/submodules/fuel/docs/release/release-notes/release-notes.html
> [9] http://docs.opnfv.org/en/stable-
> danube/submodules/fuel/docs/release/installation/installation.instruction.html
> [10] http://docs.opnfv.org/en/stable-
> danube/submodules/armband/docs/development/overview/build/build.instruct
> ion.html
> [11] http://docs.opnfv.org/en/stable-
> danube/submodules/armband/docs/release/release-notes/release-notes.html
> [12] http://docs.opnfv.org/en/stable-
> danube/submodules/armband/docs/release/installation/installation.instruction.
> html
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,
Michael fixed an important issue for Fuel OVS-DPDK scenario, so we tagged 
'opnfv-5.0.1' in Fuel git repo.
Please use this updated tag instead of previous 5.0.0 [1].

[1'] https://git.opnfv.org/fuel/tag/?h=opnfv-5.0.1

BR,
Alex

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, October 20, 2017 7:38 PM
> To: 'Aric Gardner'
> Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; Bob Monkman;
> 'Michail Polenchuk'
> Subject: [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts
> 
> Hi,
> Fuel and Armband projects are pleased to announce the public release of
> Euphrates 5.0 (opnfv-5.0.0).
> 
> Note that starting with this release, Fuel no longer produces ISO artifacts, 
> the
> only deliverable being the git repo itself (similar to Joid).
> 
> 1. Fuel artifacts
> Git tag at [1], documentation [3, 4].
> 
> 2. Armband artifacts
> Git tag at [2], documentation [5, 6].
> 
> BR,
> Alex
> 
> [1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.0.0
> [2] https://git.opnfv.org/armband/tag/?h=opnfv-5.0.0
> [3] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/release-notes/release-notes.html
> [4] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/installation/installation.instruction.ht
> ml
> [5] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/release-notes/release-
> notes.html
> [6] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/installation/installation.instructi
> on.html
> 
> > -Original Message-
> > From: Alexandru Avadanii
> > Sent: Friday, July 14, 2017 9:49 PM
> > To: 'Aric Gardner'
> > Cc: opnfv-tech-discuss@lists.opnfv.org
> > Subject: FW: Fuel and Armband Fuel Danube 3.0 ISOs
> >
> > Hi,
> > Fuel and Armband projects are pleased to announce the public release
> > of Danube 3.0.
> >
> > 1. Fuel artifacts
> > Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].
> >
> > 2. Armband artifacts
> > Git tag at [2], ISO build logs [4], ISO [6], documentation [10, 11, 12].
> >
> > BR,
> > Alex
> >
> > [1] https://git.opnfv.org/fuel/tag/?h=danube.3.0
> > [2] https://git.opnfv.org/armband/tag/?h=danube.3.0
> > [3] https://build.opnfv.org/ci/view/fuel/job/fuel-build-daily-
> > danube/738/console
> > [4]
> > https://build.opnfv.org/ci/view/armband/job/armband-fuel-build-daily-
> > danube/28/console
> > [5]
> > http://artifacts.opnfv.org/fuel/danube/opnfv-2017-07-14_14-00-12.iso
> > [6]
> > http://artifacts.opnfv.org/armband/danube/opnfv-2017-07-14_13-43-04.is
> > o
> > [7] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/development/overview/build/build.instructi
> > on.ht
> > ml
> > [8] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/release/release-notes/release-notes.html
> > [9] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/release/installation/installation.instruct
> > ion.html
> > [10] http://docs.opnfv.org/en/stable-
> > danube/submodules/armband/docs/development/overview/build/build.instru
> > ct
> > ion.html
> > [11] http://docs.opnfv.org/en/stable-
> > danube/submodules/armband/docs/release/release-notes/release-notes.htm
> > l
> > [12] http://docs.opnfv.org/en/stable-
> >
> danube/submodules/armband/docs/release/installation/installation.instruction.
> > html
___
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 Meeting Minutes - Oct. 23rd

[Alexandru Avadanii]

Hi,
One minor observation about encrypted yaml – I succesfully used `eyaml` on 
Ubuntu Trusty a while back, so I expect that to work without any issues.
I think the problem was about missing instructions for this (what packages to 
install to get `eyaml` on Ubuntu).

BR,
Alex


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan
Sent: Monday, October 23, 2017 6:52 PM
To: opnfv-tech-discuss
Subject: [opnfv-tech-discuss] [Infra] Infra WG Meeting Minutes - Oct. 23rd

October 23rd

Agenda:
1.Status Updates
· PDF, IDF , SDF efforts
· LaaS and Dashboard integration
· Infra documentation on RTD
· 
https://gerrit.opnfv.org/gerrit/#/c/45089/
· Hardware Resources
· Long duration stress testing - 
INFRA-154
· vPOD for container4nfv - 
INFRA-185
2.LaaS Hardware proposal to OPNFV board Ray 
Paik
3.Octopus PTL role as it relates to Infra WG
4.Review actions items

Action Items:

· Start etherpad on Zuul topic including links to upstream Fatih 
Degirmenci
· Create documentation about the job creation on stable branch Fatih 
Degirmenci,
 Trevor 
Bramwell

· Work with Lincoln 
Lavoie
 to get CI Pods displayed on 
labs.opnfv.org
 Trevor 
Bramwell

· Determine requirements for CI-PODs to ensure ZTE-POD2 meets them. 
Trevor 
Bramwell
· Update documents on CI POD requirements Trev

[opnfv-tech-discuss] PDF success story with Fuel/MCP on ericsson-pod1

[Alexandru Avadanii]

Hi,
Today we re-enabled ericsson-pod1 as a Fuel CI POD in OPNFV, only by populating 
the PDF/IDF correctly.
A big thank you to Dianfeng for helping us fill in the missing data, as well as 
Fatih and Aric for their support along the way!

This is the validation we were looking for when we added PDF support in 
Fuel/MCP.
Since lf-pod2 and ericsson-pod1 have quite different network layouts, we 
expected some tweaking to be required, but that was not the case.

Note that our PDFs use the net_config section (which I would very much like to 
improve going forward), while the IDFs only describe the names of jumphost 
network bridges and PCI bus information for target node interfaces (for DPDK 
binding).

I know ZTE has 1 or 2 Fuel PODs, which should also work with the new Fuel, 
provided thier PDFs are aligned with lf-pod2/ericsson-pod1.

BR,
Alex

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

Re: [opnfv-tech-discuss] [fuel] How to use packetary to create local repo for fuel

[Alexandru Avadanii]

Hi,
Old Fuel (the one used in Danube 3.0) was the only OPNFV release to switch from 
`fuel-mirror` to `python-packetary`.
You can take a look at [1] to get an idea on how to use packetary to create 
offline mirrors.
You can also install an older version of `fuel-mirror` if you’re familiar with 
that.

However, D3.0 is no longer supported. We now focus on MCP/Fuel, which does not 
yet support offline installation (although it is proposed for a future release).

BR,
Alex

[1] 
https://github.com/opnfv/fuel/blob/stable/danube/build/f_isoroot/f_repobuild/opnfv_mirror_ubuntu.py


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Julien
Sent: Sunday, October 29, 2017 10:56 AM
To: np4gs3
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [fuel] How to use packetary to create local 
repo for fuel

Hi

Fuel uses "fuel-mirror" to create mirrors for Fuel since Fuel9.

Since Euphrates, Mirantis abandoned Fuel and use MCP instead. They are 
completely different architecture. I don't suggest to use Danube3.0 of Fuel, if 
you don't have exercises of Fuel previously.

Julien


np4gs3 <13787110...@163.com>于2017年10月27日周五 上午2:37写道：
Hi,
I use Fuel to deployment the OPNFV-D3,but my lab without internet access,So I 
use my notebook to create the fuel master VM.I want use the VM to build the 
local mirror repo . I known the packetary tools is the only tools to do it ,but 
I can not find the ubuntu_mirrors.yaml and ubuntu_packages.yaml to create 
mirrors.
I read the packetary doc and edit the ubuntu_mirrors.yaml list below:
- name: "mos9.0-ubuntu"
  uri: 
"http://mirror.seed-cz1.fuel-infra.org/mos-repos/ubuntu/9.0/"
  suite: "mos9.0"
  section: ["main", "restricted"]
  priority: 1000
   path: "/tmp/mirrors/ubuntu"

- name: "mos9.0-ubuntu"
  uri: 
"http://mirror.seed-cz1.fuel-infra.org/mos-repos/ubuntu/9.0/"
  suite: "mos9.0"
  section: ["main", "restricted"]
  priority: 1000
   path: "/tmp/mirrors/ubuntu"


  - name: "ubuntu"
uri: 
http://archive.ubuntu.com/ubuntu/
priority: null
section:  ["main", "universe", "multiverse"]
suite: "xenial"
type: deb
uri: 
http://archive.ubuntu.com/ubuntu/
path: "/tmp/mirrors/ubuntu"

  - name: "ubuntu-updates"
priority: null
section:  ["main", "universe", "multiverse"]
suite: "xenial-updates"
type: deb
uri: 
http://archive.ubuntu.com/ubuntu/
path: "/tmp/mirrors/ubuntu"

  - name: ubuntu-security
priority: null
section: ["main", "universe", "multiverse"]
suite: "xenial-security"
type: deb
uri: 
http://archive.ubuntu.com/ubuntu/
path: "/tmp/mirrors/ubuntu"

  - name: mos
priority: 1050
section: ["main", "restricted"]
suite: "mos10.0"
type: deb
uri: 
http://10.10.10.2:8080/newton-10.0/ubuntu/x86_64

Re: [opnfv-tech-discuss] [Gerrit] Can not connect to Gerrit

[Alexandru Avadanii]

Hi, Sofia,
Your gerrit URL looks wrong – the  should be your Linux Foundation 
ID (which is also the gerrit account username).

-gerritssh://@review.opnfv.org:29418/opnfv/container4nfv.git 
(fetch)
+gerritssh://yourl...@review.opnfv.org:29418/opnfv/container4nfv.git (fetch)

Also, you should have set up a few things before being able to push to gerrit:

-  Linux Foundation ID according to [1];

-  SSH keypair on your gerrit account [2];

-  accept the license agreement in gerrit web dashboard (once you do 
that, you should have „CLA Accepted – Individual” in [3]);

-  be on the list of contributors for the project you want to push to 
(once you have that, [3] should list something like 
„ldap/opnfv-gerrit-container4nfv…”) – maybe Trevor/Aric can help you with this?

BR,
Alex

[1] https://wiki.opnfv.org/display/DEV/Developer+Getting+Started
[2] https://gerrit.opnfv.org/gerrit/#/settings/ssh-keys
[3] https://gerrit.opnfv.org/gerrit/#/settings/group-memberships


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Sofia Enriquez
Sent: Tuesday, November 21, 2017 9:16 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Gerrit] Can not connect to Gerrit

Hey!
My name is Sofia and I'm trying to send my first patch to Gerrit without 
success. I'm having the next problem:

❯ cat .gitreview
[gerrit]
host=gerrit.opnfv.org
port=29418
project=container4nfv.git
❯ git remote -v
gerrit
ssh://@review.opnfv.org:29418/opnfv/container4nfv.git
 (fetch)
gerrit
ssh://@review.opnfv.org:29418/opnfv/container4nfv.git
 (push)
origin
https://github.com/opnfv/container4nfv.git
 (fetch)
origin
https://github.com/opnfv/container4nfv.git
 (push)
❯ git review
Username for 
'https://github.com':
 
Password for 
'https://enriquet...@github.com':
remote: Permission to opnfv/container4nfv.git denied to .
fatal: unable to access 
'https://github.com/opnfv/container4nfv.git/':
 The requested URL returned error: 403

What should I do? I'm not sure why `git review` command ask me for the GitHub 
pass instead of Gerrit's.
Thanks!
Sofia
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [opnfv-5.1.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

1. Fuel artifacts
- git tag [1];
- documentation [3, 4, 5];

2. Armband artifacts
- git tag [2];
- documentaiton [6, 7, 8] - identical to Fuel@OPNFV, we just publish it for 
uniformity;

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.1.0
[2] https://git.opnfv.org/armband/tag/?h=opnfv-5.1.0
[3] 
http://docs.opnfv.org/en/stable-euphrates/submodules/fuel/docs/release/release-notes/release-notes.html
[4] 
http://docs.opnfv.org/en/stable-euphrates/submodules/fuel/docs/release/installation/installation.instruction.ht
[5] 
http://docs.opnfv.org/en/stable-euphrates/submodules/fuel/docs/release/userguide/userguide.html
[6] 
http://docs.opnfv.org/en/stable-euphrates/submodules/armband/docs/release/release-notes/release-notes.html
[7] 
http://docs.opnfv.org/en/stable-euphrates/submodules/armband/docs/release/installation/installation.instruction.ht
[8] 
http://docs.opnfv.org/en/stable-euphrates/submodules/armband/docs/release/userguide/userguide.html

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, October 20, 2017 7:38 PM
> To: 'Aric Gardner'
> Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; Bob Monkman;
> 'Michail Polenchuk'
> Subject: [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts
> 
> Hi,
> Fuel and Armband projects are pleased to announce the public release of
> Euphrates 5.0 (opnfv-5.0.0).
> 
> Note that starting with this release, Fuel no longer produces ISO artifacts, 
> the
> only deliverable being the git repo itself (similar to Joid).
> 
> 1. Fuel artifacts
> Git tag at [1], documentation [3, 4].
> 
> 2. Armband artifacts
> Git tag at [2], documentation [5, 6].
> 
> BR,
> Alex
> 
> [1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.0.0
> [2] https://git.opnfv.org/armband/tag/?h=opnfv-5.0.0
> [3] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/release-notes/release-notes.html
> [4] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/installation/installation.instruction.ht
> ml
> [5] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/release-notes/release-
> notes.html
> [6] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/installation/installation.instructi
> on.html
> 
> > -Original Message-
> > From: Alexandru Avadanii
> > Sent: Friday, July 14, 2017 9:49 PM
> > To: 'Aric Gardner'
> > Cc: opnfv-tech-discuss@lists.opnfv.org
> > Subject: FW: Fuel and Armband Fuel Danube 3.0 ISOs
> >
> > Hi,
> > Fuel and Armband projects are pleased to announce the public release
> > of Danube 3.0.
> >
> > 1. Fuel artifacts
> > Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].
> >
> > 2. Armband artifacts
> > Git tag at [2], ISO build logs [4], ISO [6], documentation [10, 11, 12].
> >
> > BR,
> > Alex
> >
> > [1] https://git.opnfv.org/fuel/tag/?h=danube.3.0
> > [2] https://git.opnfv.org/armband/tag/?h=danube.3.0
> > [3] https://build.opnfv.org/ci/view/fuel/job/fuel-build-daily-
> > danube/738/console
> > [4]
> > https://build.opnfv.org/ci/view/armband/job/armband-fuel-build-daily-
> > danube/28/console
> > [5]
> > http://artifacts.opnfv.org/fuel/danube/opnfv-2017-07-14_14-00-12.iso
> > [6]
> > http://artifacts.opnfv.org/armband/danube/opnfv-2017-07-14_13-43-04.is
> > o
> > [7] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/development/overview/build/build.instructi
> > on.ht
> > ml
> > [8] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/release/release-notes/release-notes.html
> > [9] http://docs.opnfv.org/en/stable-
> > danube/submodules/fuel/docs/release/installation/installation.instruct
> > ion.html
> > [10] http://docs.opnfv.org/en/stable-
> > danube/submodules/armband/docs/development/overview/build/build.instru
> > ct
> > ion.html
> > [11] http://docs.opnfv.org/en/stable-
> > danube/submodules/armband/docs/release/release-notes/release-notes.htm
> > l
> > [12] http://docs.opnfv.org/en/stable-
> >
> danube/submodules/armband/docs/release/installation/installation.instruction.
> > html
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [release][fraser] MS3.0 - Dec 15 / Installer teams able to deploy nosdn-nofeature scenario

[Alexandru Avadanii]

Hi,


1.   Fuel

a.   Functest healthcheck pass [1]

b.  Done, see [2]

c.   Done, see [2]

d.  Done, see [2]

2.   Armband

a.   Functest healtcheck pass [3]

b.  Done, see [4]

c.   Done, see [5]

d.  Done, see [5]

BR,
Alex

[1] 
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/2008/console
[2] 
https://build.opnfv.org/ci/job/fuel-os-nosdn-nofeature-ha-baremetal-daily-master/628/
[3] 
https://build.opnfv.org/ci/job/functest-fuel-armband-baremetal-arm-daily-master/65/console
[4] 
https://build.opnfv.org/ci/view/armband/job/fuel-os-nosdn-nofeature-ha-armband-baremetal-daily-master/167/console
[5] 
https://build.opnfv.org/ci/view/armband/job/fuel-os-nosdn-nofeature-ha-armband-baremetal-daily-master/168/console

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Friday, December 08, 2017 9:43 PM
To: TECH-DISCUSS OPNFV; opnfv-project-leads; Raymond Paik; 
tim.irn...@ericsson.com
Subject: Re: [opnfv-tech-discuss] [release][fraser] MS3.0 - Dec 15 / Installer 
teams able to deploy nosdn-nofeature scenario

Reminder... one week from today.

On Mon, Dec 4, 2017 at 3:56 PM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Installer teams,

I realize that many of you are focused on Plugfest this week, but please don't 
forget about Fraser MS3.0 one week from Friday, on December 15.

Requirements:

  *   Functest has completed integration of Openstack Pike and health check is 
functional
  *   Installers have completed integration of Openstack Pike
  *   Installers have enabled Jenkins jobs to deploy os-nosdn-nofeature-ha
  *   Installers have enabled Jenkins jobs to run health check
Please let me know if you have questions.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Models][Auto] vHello_Tacker updated for Euphrates

[Alexandru Avadanii]

Hi,
Actually you can run x86_64 containers on AArch64 just fine (and the other way 
around), provided you use the appropiate translation tools, like 
qemu-user-static.
See [1], I can't find a guide that explains how to do this step-by-step for 
containers, but I'm quite sure it's possible (I think it's enough to set up 
binfmt on the host system and mount the binary of qemu-x86_64-static in the 
expected location inside the container).

BR,
Alex

[1] https://wiki.debian.org/QemuUserEmulation


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of UKASICK, AIMEE 
L (AIMEE L)
Sent: Wednesday, January 10, 2018 2:19 AM
To: SULLIVAN, BRYAN L (BRYAN L); pramod.sud...@wipro.com; Tina Tsou; 
eric.dm...@wipro.com; Joe Kidder
Cc: 'opnfv-tech-discuss@lists.opnfv.org'
Subject: Re: [opnfv-tech-discuss] [Models][Auto] vHello_Tacker updated for 
Euphrates

Yes you need a Docker image compiled on ARM in order for it to run on ARM.
I've never created a Docker image for multiple architectures but I did read 
about the capability last year:
https://blog.docker.com/2017/11/multi-arch-all-the-things/
https://developer.ibm.com/linuxonpower/2017/07/27/create-multi-architecture-docker-image/

Good luck!
-
Aimee Ukasick
AT&T Research Advanced Technology

From: SULLIVAN, BRYAN L (BRYAN L)
Sent: Tuesday, January 09, 2018 17:50
To: pramod.sud...@wipro.com; Tina Tsou; 
eric.dm...@wipro.com; UKASICK, AIMEE L (AIMEE L); 
Joe Kidder
Cc: 'opnfv-tech-discuss@lists.opnfv.org'
Subject: RE: [Models][Auto] vHello_Tacker updated for Euphrates
Re ARM arch, good point. I don't have ARM hw and did not build this for ARM. 
You can try to build it using the script (tacker.sh) in the models build 
folder. If it works, you will need to push the container to docker hub and 
patch the vHello_Tacker.sh script to reference it, or figure out how to pull it 
as a local container image.

Thanks,
Bryan Sullivan | AT&T

From: pramod.sud...@wipro.com 
[mailto:pramod.sud...@wipro.com]
Sent: Tuesday, January 09, 2018 3:09 PM
To: SULLIVAN, BRYAN L (BRYAN L) 
mailto:bryan.sulli...@research.att.com>>; Tina 
Tsou mailto:tina.t...@arm.com>>; 
eric.dm...@wipro.com; UKASICK, AIMEE L (AIMEE L) 
mailto:aim...@research.att.com>>; Joe Kidder 
mailto:joe.kid...@5thlayer.com>>
Cc: 'opnfv-tech-discuss@lists.opnfv.org' 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [Models][Auto] vHello_Tacker updated for Euphrates

Hi Bryan,

I am copying Joe for getting info/process used by him to deploy OPNFV/Fuel in 
this ARM Pod.

The sudo docker logs -f tacker shows "standard_init_linux.go:178: exec user 
process caused "exec format error"". The "sudo docker image inspect 
blsaws/models-tacker" shows "Architecture": "amd64", so I was wondering whether 
we need specific docker image for ARM architecture.

Regards,
Pramod

From: SULLIVAN, BRYAN L (BRYAN L) [mailto:bryan.sulli...@research.att.com]
Sent: Tuesday, January 9, 2018 4:25 PM
To: Pramod Sudrik (Product Engineering Service) 
mailto:pramod.sud...@wipro.com>>; Tina Tsou 
mailto:tina.t...@arm.com>>; Eric DMaye (Product Engineering 
Service) mailto:eric.dm...@wipro.com>>; UKASICK, AIMEE L 
(AIMEE L) mailto:aim...@research.att.com>>
Cc: 'opnfv-tech-discuss@lists.opnfv.org' 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [Models][Auto] vHello_Tacker updated for Euphrates


** This mail has been sent from an external source **
Two minor edits:

  1.  The link to start.sh (thanks, outook): 
https://git.opnfv.org/models/tree/build/tacker/start.sh

Re: [opnfv-tech-discuss] [Models][Auto] vHello_Tacker updated for Euphrates

[Alexandru Avadanii]

Hi,
2) MCP sets up all Openstack services to talk to each other over unencrypted 
connections on the internal management network (172.16.10.0/24).
This means all admin/internal endpoints use plain http, while the public 
endpoints are handled via nginx (*with* SSL termination) on the prx01/02 VCP 
VMs.
If you plan to use the public endpoints, you will most likely have to add the 
certificate (mcp_os_cacert) on the machine that connects to those public 
endpoints.
For convenience, the deploy will copy that cert to the cfg01 node in 
/etc/ssl/certs/os_cacert.

Functest/yardstick, which use the public endpoints, copy this file via [1, 2] 
inside their respective containers as /etc/ssl/cert/mcp_os_cacert (to prevent 
name collisions).
I'll open a bug report for documenting this better in the Fuel docs.

BR,
Alex

[1] https://git.opnfv.org/releng/tree/utils/fetch_os_creds.sh#n119
[2] 
https://github.com/opnfv/releng/blob/dca0a72d315416f17dd4296299726b4fbcb88c8a/jjb/functest/functest-alpine.sh#L108

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of SULLIVAN, 
BRYAN L (BRYAN L)
Sent: Wednesday, January 10, 2018 4:35 PM
To: pramod.sud...@wipro.com; Tina Tsou; eric.dm...@wipro.com; UKASICK, AIMEE L 
(AIMEE L); Joe Kidder
Cc: 'opnfv-tech-discuss@lists.opnfv.org'
Subject: Re: [opnfv-tech-discuss] [Models][Auto] vHello_Tacker updated for 
Euphrates

A couple of notes:
1)  There should not be multiple endpoints with the same name defined in 
OpenStack. It's likely that one is a remainder from some earlier test. You may 
need to use "openstack endpoint delete ..." to remove one of the endpoints. 
Being related to keystone in this case, it's not something that was setup by 
this test script. It may also be some quirk in the way that MOS sets up the 
endpoints, that I have not encountered so far.
a.   Send me the result of "openstack endpoints list" and "openstack 
endpoint show " for each endpoint. I will see if 
I can mod the script to handle it, if it's not some error in the Fuel setup.
2)  "OS_CACERT=/etc/ssl/certs/mcp_os_cacert" looks like some Fuel-specific 
cert file. I'm not sure what the effects related to that might be. You will 
probably need Fuel team support. It could indicate that for Fuel, there needs 
to be some additional file installed on the Tacker client... I have not 
encountered such an error on Apex or JOID.

Thanks,
Bryan Sullivan | AT&T

From: pramod.sud...@wipro.com 
[mailto:pramod.sud...@wipro.com]
Sent: Tuesday, January 09, 2018 9:05 PM
To: SULLIVAN, BRYAN L (BRYAN L) 
mailto:bryan.sulli...@research.att.com>>; Tina 
Tsou mailto:tina.t...@arm.com>>; 
eric.dm...@wipro.com; UKASICK, AIMEE L (AIMEE L) 
mailto:aim...@research.att.com>>; Joe Kidder 
mailto:joe.kid...@5thlayer.com>>
Cc: 'opnfv-tech-discuss@lists.opnfv.org' 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [Models][Auto] vHello_Tacker updated for Euphrates

Hi Bryan and Joe,

I could create an image for tacker on ARM Pod using tacker.sh. I had to change 
start.sh in /tmp/models/ to account for a change in "endpoint create" API 
syntax and also to  account for multiple endpoints with the same name in 
openstack. The Tacker container is now started but still encounters an error 
for "tacker vim-register" as below. I also encountered some auth failure for 
this command on last Friday (for auth_url: 
http://172.16.10.10:35357/v3
 and OS_PROJECT_DOMAIN_ID=Default). I was also wondering about the non-existent 
file for OS_CACERT=/etc/ssl/certs/mcp_os_cacert being used in env. Complete 
session logs are attached.

main:203 (Wed Jan 10 03:39:11 UTC 2018) Register default VIM
SSL exception connecting to 
https://10.10.50.103:5000/v2.0:

[opnfv-tech-discuss] [fuel] Nominating Guillermo Herrero as committer

[Alexandru Avadanii]

Hi,
I would like to nominate Guillermo Herrero (Enea) as a committer in Fuel@OPNFV.
I have been in contact with Guillermo and he is willing to take on the role.

Guillermo is one of the main contributors in Armband and Fuel@OPNFV,
and he has been one of the most active and valuable contributors during the 
Euphrates release cycle.

Fuel committers, reply to this mail with your vote (-1, 0, +1).
I'll start:
+1

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

[opnfv-tech-discuss] POD Descriptor File schema validation and minor fixes

[Alexandru Avadanii]

Hi,

Intended audience:
- Pharos contributors;
- installer teams;
- lab owners;
There are some APs summarized at the end, if you want to skip to that.

I propose a few changes trying to achieve the following goals:
- prepare for introducing a strict schema validation for PDFs;
- clean up PDF spec deviations, typos etc. in existing PDFs;
- propose PDF schema based on spec, as strict as possible;
- add tooling for a verify job (to be added later) that checks new PDFs
  against the schema;
- propose IDF schema based on current implementations (not so strict);

I apologize for the numerous mails you'll receive to review all these changes.
I am aiming at a clean git history (without merges) for the below topics,
so they'll be easier to track later. This means a lot of rebase and request for
review mails for the Pharos committers.

While working on this, I found a few errors that justify using a schema to
validate PDFs instead of relying on peer review only, e.g.:
- out-of-range/not-in-enum errors;
- type errors;
- wrong features separators;
- missing mandatory properties (unless my schema understanding is wrong);
- wrong key names (typos);
- wrong MAC (I left this one unchanged, because although 'G' is clearly an
   invalid char, I'm not sure it should be an 'F' there);

The main topics, their indended audience and goals are summarized below:

1. yamllint-fix: Pharos committers, installer teams;
   - skip trying to `eyaml` PDFs that are not encrypted, leading to cleaner
 verify (check-jinja) logs, as well as ~25% faster verify jobs;
   - skip trying to validate the  files, they are not
 valid PDFs;
   - fix yamllint for output YAMLs generated based on PDF + installer adapter
 templates;
   - replace encrypted string with (shorter) dummy values during yamllint to
 bypass false-positive line-too-long yamllint warnings;

2. check-jinja-cleanup: Pharos committers;
   - since we now have a dedicated yamllint CI job for checking PDF files,
 let's drop that same check from `check-jinja` and slightly refactor the
 output log to make it a bit easier to read;

3. move-net_config-idf: Pharos committers, installer teams, lab owners;
   - net_config is a leftover from early IDF development, it wrongfully got
 into a few PDFs, althought its place is in the IDF; let's move it there
 and deal with the other related properties (e.g. 'fixed_ips') so all
 PDFs are compliant with the PDF specification;
   - the first step adds support for IDF net_config where missing (Fuel, Daisy);
   - next, we move net_config from PDF to IDF for all PODs in all labs;
   - the last step removes PDF net_config from installer adapters (Fuel, Daisy);
   - NOTE for installer teams: additional changes may be required in the 
installer
 if additional templates rely on net_config being in the PDF (true for 
Fuel).
 Ideally, we'd add support IDF net_config in all installers (where required,
 this might only be the case for Fuel?), merge the Pharos changes, then 
remove
 old support for PDF net_config from installers;

4. fix-pdf-spec-deviations: Pharos committers, lab owners;
   - minor changes in unused/default values (e.g. disk_rotation for SSD drives);
   - add interfaces "name: 'nicN'" where missing;
   - fix some typos;

5. pdf-schema: Pharos committers;
   - add PDF schema based on the spec (I hope my understanding of the spec is
 correct);
   - add `check-schema` similar to `check-jinja`, to be leveraged by CI verify;

6. pdf-spec-update: Pharos committers, installer teams, lab owners;
   - add new enum value '0' to 'disk_rotation' for ssd/nvme drives;
   - use 'name: nicN' for jumpserver interfaces to align with cluster nodes;
   - add new enum values 'scsi', 'iscsi' to 'disk_interface' - I am not sure
 this is correct;
   - I still have some question about certain enums in PDF, but I'll try to
 bring those up during the infra meeting on 22nd;

7. idf-schema: Pharos committers, installer teams;
   - add schema for IDF: strict for Fuel section, not so strict for Daisy or
 the net_config section yet;

8. config-license: Pharos committers
   - update copyright year in files we touched;
   - add license headers where missing;
   - this is separate from all of the above because we might want to refactor
 licensing by adding a single LICENSE file in each dir;

Proposed action points:

1. Pharos committers
   - please scan all of the above, input is greatly appreciated;

2. Installer teams
   - most likely, no changes are expected in the installers' code (except for
 Fuel, which I'll handle myself);
   - a quick scan of the above is recommened for Daisy & Fuel contributors;

3. Lab owners
   - [all] all labs are affected, changes to PDFs are split by lab name;
 most of them are simple typo fixes and don't require input;
   - [Ericsson, Intel, BII] there are some missing user/pass fields, most likely
 removed during the move from securedlab to pharos git repo.
 This s

Re: [opnfv-tech-discuss] [Pharos] Stepping down as PTL

[Alexandru Avadanii]

Hi, Jack,
Thank you for your great contributions and the patience in answering all our 
questions!
I wish you the best of luck in your future endeavours!

+2 for Julien as the new PTL.

BR,
Alex


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan
Sent: Wednesday, January 17, 2018 9:07 AM
To: opnfv-tech-discuss
Subject: [opnfv-tech-discuss] [Pharos] Stepping down as PTL


OPNFV,

It is with great sorrow that I'm announcing that I will be stepping down as the 
Pharos PTL. It has been nearly two years since I took over the PTL role and I 
hope my contributions have been beneficial. I really appreciate all the help 
and support I've received from the community. I feel I've really gained from 
the experience.

In the meanwhile, I would like to nominate Julien Zhang as the next Pharos PTL. 
He has been very active in the Pharos project this past year not just with 
gerrit patches, but also in documentation, Infra WG meetings and other Pharos 
projects.



Committers, please vote +2/-2 for Julien as Pharos PTL.



Thanks,

--

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

Re: [opnfv-tech-discuss] New Adventures

[Alexandru Avadanii]

Hi, Dan,
Thank you for your contributions and the occasional nightly debugging sessions!
No doubt we will meet again :)

All the best,
Alex

> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
> boun...@lists.opnfv.org] On Behalf Of Dan Radez
> Sent: Wednesday, January 17, 2018 9:56 PM
> To: opnfv-tech-discuss@lists.opnfv.org
> Subject: [opnfv-tech-discuss] New Adventures
> 
> With a new year I have been assigned to a new primary project.
> 
> I've enjoyed my time with OPNFV and want to say thank you to the community
> and leadership for the past three years of working together.
> It's been a pleasure to work along side of you all.
> 
> I'll be around less but not inaccessible. I'll be working to hand off my 
> tasks over
> the next couple weeks so they can be carried forward. Please be in contact 
> with
> me if I'm not already in discussion with you about certain tasks.
> 
> Happy New Year!
> 
> Dan Radez
> ___
> 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] Gerrit groups proposal

[Alexandru Avadanii]

Hi, all,
I've recently pushed a few Gerrit changes in Pharos that affect different 
installers and noticed it is hard to track down the appropriate committers to 
add as reviewers for each project.
That's why I want to suggest we create more Gerrit groups.

Pharos, Fuel and Armband already do that - to add all project committers as 
reviewers to a change one can use 'Pharos', 'fuel-review' or 'armband-review' 
groups.
This makes it easier to track down & add committers one by one, and also 
reduces the number of mails Gerrit sends out during that operation.

Afaik, any committer can create a Gerrit group. But if you do that, please 
align to the naming convention used so far: Gerrit group name == project name; 
eventually add a suffix, like '-review' if there's already an entity with that 
name, which was the case for Fuel.

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

Re: [opnfv-tech-discuss] [pharos] [infra] POD Descriptor File documentation for OPNF Docs hackfest?

[Alexandru Avadanii]

Hi, Mika,
Original documentation [1, 2, 3].

However, I think the best reference is the schema file itself [6].
Additional information about eyaml encryption can be found at [5].
OPNFV Pharos docs has a small chapter about PDF [7], but I don't think it's 
detailed enough.
Recent plumbing additions (related to PDF/IDF) were summarized in [4] 
(meanwhile all of that was merged).

Jack, Julien, please let us know if we missed anything. Also, I think you 
wanted to maintain a wiki page for PDF - any updates on that?

BR,
Alex

[1] https://wiki.opnfv.org/display/INF/POD+Descriptor
[2] 
https://www.slideshare.net/OPNFV/how-to-reuse-opnfv-testing-components-in-telco-validation-chain?next_slideshow=1
[3] https://www.youtube.com/watch?v=iZcJQO9BAsU
[4] 
https://www.mail-archive.com/opnfv-tech-discuss@lists.opnfv.org/msg08008.html
[5] https://github.com/opnfv/pharos/blob/master/config/utils/README.eyaml.rst
[6] https://github.com/opnfv/pharos/blob/master/config/pdf/pod1.yaml
[7] 
http://docs.opnfv.org/en/latest/submodules/pharos/docs/release/release-notes/lab-description/pdf.html


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Rautakumpu, 
Mika (Nokia - FI/Espoo)
Sent: Thursday, January 25, 2018 1:01 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [pharos] [infra] POD Descriptor File 
documentation for OPNF Docs hackfest?

Hi all,

Is there any PDF documentation available at the moment? My plan is to 
participate OPNFV docs Hackfest next week and if there is no documentation from 
PDF, it could be one area that I could hack.

Br,
Mika Rautakumpu

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

Re: [opnfv-tech-discuss] [pharos] [infra] POD Descriptor File documentation for OPNF Docs hackfest?

[Alexandru Avadanii]

Hi, Julien,
Yes, there’s no `idf.yaml` (let’s call it a spec file), like we have for PDF.
If we decide to add it, I can help fill in the Fuel section, the other 
installer teams will have to propose a format for each of their sections.

BR,
Alex


From: Julien [mailto:julien...@gmail.com]
Sent: Saturday, January 27, 2018 11:51 AM
To: Alexandru Avadanii
Cc: Rautakumpu, Mika (Nokia - FI/Espoo); opnfv-tech-discuss@lists.opnfv.org; 
Jack Morgan
Subject: Re: [opnfv-tech-discuss] [pharos] [infra] POD Descriptor File 
documentation for OPNF Docs hackfest?

Hi Alex,

You have listed all the most important information about PDF.
We will migrate all the definition and description into gerrit repo and release 
it in readthedocs together with all infra projects.
I find that in our repo, we miss the idf.yaml for reference.

BR/Julien


Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>于2018年1月26日周五 
上午3:28写道：
Hi, Mika,
Original documentation [1, 2, 3].

However, I think the best reference is the schema file itself [6].
Additional information about eyaml encryption can be found at [5].
OPNFV Pharos docs has a small chapter about PDF [7], but I don’t think it’s 
detailed enough.
Recent plumbing additions (related to PDF/IDF) were summarized in [4] 
(meanwhile all of that was merged).

Jack, Julien, please let us know if we missed anything. Also, I think you 
wanted to maintain a wiki page for PDF – any updates on that?

BR,
Alex

[1] 
https://wiki.opnfv.org/display/INF/POD+Descriptor<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=flivH33ibFJ9W9c-Dk8rwTtPHxbaiDgcwaoiavY5w-Uuu_zIz5LyJSNhMmAbYhJT_bmvUGrbY2djor9UOn4w5uzJonIH3QqN07_2Nh8KnWuEBBbNHXKIj_FeFNRIp2P2me6xOLmxUpZfFVmUvRmXFviomAYme8Yu9ZvRZDC0GcT4L09Mz0nCvYUsfrzrPBo2XDsGnFOMCtP58-R2FuVXE5YQMuN9zOr1lJzlEbKUs_4khivUmzWmZTPrpslPNz7t>
[2] 
https://www.slideshare.net/OPNFV/how-to-reuse-opnfv-testing-components-in-telco-validation-chain?next_slideshow=1<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=CW9SyFf2jNnBx15OYIQDpBB9PG0f6TCuKDo-eR3wcTSkCCZXXXOKLr4OxHjv1WcJRT4Xzl-vPgb2Z68SYyjo08QjuS88oyYGgUS3j5xzvpUzx0xFvCLAKlGMS70d3LOprCtzicz-grKk7psvFDe1y4_RnhPilf21YJu2lup3Qto90QebeQb3znjIFmn0bfI6kvxGfL6eaRfXKirkIYuz77oDzxA7vGTed-r7za0dfIde9h9v-GT3LnZHdFHP8b2nVhgMNqYuDx0vIcyrlo-iedSxQnSJNNXqzDjN2yKtnr_rufeJ6cBKKmLImJrhRsEiUW-4J2GrimRnVxwxU_hSGA>
[3] 
https://www.youtube.com/watch?v=iZcJQO9BAsU<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=utGwXzptpCoijlD06qkR5HCPcouOdlo_0Gt2s5hRE23dbcCIOZAWlGWh7REyLvwGcKcSjc-68IrVmKV9dZSzJogWABQKMKb2PFugpNTh5jPq81b61R-5EnvxsgxZEx5uvV9AbD9YJ2Voda6oWxO0YsdS9GuXf1aD1xsTjukHIiEhyjpQqJFBCHOTLDb1rUpyFDm12OLpXKxYeozTsPOgmwUBtMB_YwjIWmZW55aw2yqHsmbih5ASOPaPq66GhkFG>
[4] 
https://www.mail-archive.com/opnfv-tech-discuss@lists.opnfv.org/msg08008.html<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=-W3HYHkaYwO9NYwKOpjWdWVWc3VR0g1OncwBKwj5H6O1ud6NM0R097lnwiCD04SDzv0Nu_83wa1ODeZ1OeRkJZBgnAvJvGfBEFkk6AfZY8vNVVF2wXcjN9Ty9gIjHXeQjt6ZinqEYFk19Sb_yyGg3vEAhp_eN7AQV3NypO1r5twPmszKHI25-CJrxq9lj476V_2Hjmy2JwET3TA77Wyv2hNvOh344exGy5M_30lZ8JMxQ1TC0oAJt6j6Q-l9uqoviAk-Xcyi4R0zauVzxSppnqWqFhedFwAh96lBM-rm0Cg>
[5] 
https://github.com/opnfv/pharos/blob/master/config/utils/README.eyaml.rst<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=KT3Wwl7qPikoda7ZcRQdVirchR7Vh0Le8pQ9WtOo3h01T01G6XlmduLtGWDtfVDEMQ6qaIdppLA1hYzBWYv-gce_cpE681ABYhhlCqrxfyO_f4G2TR-v9igqjTHD_L1Lnk9K2tjUogmSiutmSF0oKlvmXRco-A85djBQNedqQifMdL4BKlXAI1mPU1HE3ViWvamJVflSTtKGNw_36yXNUBiUoKmBI2sOHNw-G0jwob9to8CZMoxuQnaZZfX5edtE0dpPQ39-dB_B4rpcrYKn8vp3uQ2XuHNXMykkXrr9B5c>
[6] 
https://github.com/opnfv/pharos/blob/master/config/pdf/pod1.yaml<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=osRuADhxi8100Hk0INKkv_awPHDJgsXLmY_rayqMSgAN7L-kuWxZwhBMpKv2AhxEaft9PW6YY-WyWr6hgYECi4CevMQaWagV811TsdtEqhAS9m1WMvGbZ6nxl8n-l9VIbobTBmlFxNloTuLDfIujdTprEgdpxP6BJalwP3JgCJfXlCKyg9lqkM4lHf5VgJphL09-pLRLSVlQOUpMFfkSkYUcqlX1cokm9ICRKVa7-oKpRF5myyBgG9iSbYxfOfgh7cozDyOycEC78SgbEgihNw>
[7] 
http://docs.opnfv.org/en/latest/submodules/pharos/docs/release/release-notes/lab-description/pdf.html<https://url10.mailanyone.net/v1/?m=1efN8Q-0001QK-6I&i=57e1b682&c=_2cTi7k6-doWmNTeQq0Z48f3gaL3TYgL6YPcKKwIEH8CUZ5m4GJkoEcm1dlOG_1h_pf6d7-UoX5hVx2t6LmFx8lUnFr8yOFjmCuZhiw-5luMk_AZ5QhrnDvvvqYWSf99ExlSjWY2o3o7GVmelQ7ucUNQ_lr-R6qVHMctfMv4XTOaHxKVIImGRAHiGcz-9ea4eZNwfZ2BRzrY-h4kRetnidqYqhU3_84JUOC_jkLzAMMIi_8wpnjpThlgvEBAsfH9RiZ8k4zeS1Es2KCpqB5MUB_FNkkbSrQFQTDOiVBWOeIfZX9wanLy9F0_TBYblyWVGYMw-NedcozTlxoUw-ZD_w>


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:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of Rautakumpu, Mika (Nokia - FI/Espoo)
Sent: Thursday, January 25, 2018 1:01 PM
To: 
opnfv-tech-discuss@lists.opn

Re: [opnfv-tech-discuss] [armband] [fuel] Deployment file for Fuel on LaaS ARM

[Alexandru Avadanii]

Hi,

+Joe


Lincoln is right, you could spawn a VM, but it would be emulated without hw 
acceleration, so not really useful.

Reserving a single aarch64 node might be limiting though, Armband Fuel requires 
at least 6 nodes (1 jump server + 5 cluster nodes) right now.

Not sure what the mininum requirement for Compass4NFV + k8 are, but if you want 
to stick to Openstack, you should try reserving more nodes (afaik, there are 
enough available in UNH lab).


BR,

Alex


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
 on behalf of Lincoln Lavoie 

Sent: Friday, April 6, 2018 4:48:18 PM
To: Beierl, Mark
Cc: opnfv-tech-discuss@lists.opnfv.org; Parker Berberian
Subject: Re: [opnfv-tech-discuss] [armband] [fuel] Deployment file for Fuel on 
LaaS ARM

Hi Mark,

I think you can do a virtual deployment, which is 1 level of VMs.  But, I don't 
think you can host a VM on top of the open stack deployment (because that's 
nested).

Cheers,
Lincoln

On Fri, Apr 6, 2018 at 9:45 AM, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:
Hello, Parker, and thanks for the quick response.

So to be clear, I cannot deploy OPNFV on this system at this time?

Regards,
Mark

Mark Beierl
SW System Sr Principal Developer
Dell EMC | Cloud & Communication Service Provider Solution
mobile +1 613 314 8106
mark.bei...@dell.com

On Apr 6, 2018, at 09:43, Parker Berberian 
mailto:pberber...@iol.unh.edu>> wrote:

Mark,

You have to be mindful that ARM does not support nested virtualization (and 
therefore virtual deployments with openstack are impossible). If Fuel does not 
support Kubernetes, then you may be out of luck until we can provide pharos 
POD's through LaaS.

Thanks,
Parker

On Fri, Apr 6, 2018 at 9:39 AM, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:
Hello, folks!

I have reserved an Arm server (arm41) in the LaaS and it's ready.  I am 
wondering if anyone has a configuration file for deploying Fuel on a single Arm 
server that I can borrow for this?

Or is there a better way to deploy Fuel on Arm, like re-using an existing 
Jenkins job?

Regards,
Mark

Mark Beierl
SW System Sr Principal Developer
Dell EMC | Cloud & Communication Service Provider Solution
mobile +1 613 314 8106
mark.bei...@dell.com






--
***
Lincoln Lavoie
Senior Engineer, Broadband Technologies

[http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/unh-iol-logo.png]
www.iol.unh.edu
21 Madbury Rd., Ste. 100, Durham, NH 03824
Mobile: +1-603-674-2755
lylav...@iol.unh.edu
[http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/facebook.png]
  [http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/twitter.png] 

   [http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/linkedin.png] 


Ars sine scientia nihil est! -- Art without science is nothing.
Scientia sine ars est vacua! -- Science without art is empty.

Broadband Forum Gfast Certified Product 
List

[opnfv-tech-discuss] [opnfv-6.0.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,
After a tricky release cycle, we are happy to be able to release all planned 
scenarios as expected.

1. Fuel artifacts (x86_64)
- git tag gerrit change [1];
- git tag [2] (will go live once [1] is merged);
- documentation [4, 5, 6];

2. Armband Fuel artifacts (aarch64)
- git tag gerrit change [1];
- git tag [3] (will go live once [1] is merged);
- documentation [7, 8, 9];

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/56809/
[2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.0.0
[3] https://git.opnfv.org/armband/tag/?h=opnfv-6.0.0
[4] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/release-notes/release-notes.html
[5] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html
[6] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/userguide/userguide.html
[7] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/release-notes/release-notes.html
[8] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/installation/installation.instruction.html
[9] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/userguide/userguide.html

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, December 15, 2017 9:44 PM
> To: 'Aric Gardner'
> Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; 'Bob Monkman';
> 'Michail Polenchuk'
> Subject: [opnfv-5.1.0] Fuel and Armband Fuel Release Artifacts
>
> Hi,
>
> 1. Fuel artifacts
> - git tag [1];
> - documentation [3, 4, 5];
>
> 2. Armband artifacts
> - git tag [2];
> - documentaiton [6, 7, 8] - identical to Fuel@OPNFV, we just publish it for
> uniformity;
>
> BR,
> Alex
>
> [1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.1.0
> [2] https://git.opnfv.org/armband/tag/?h=opnfv-5.1.0
> [3] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/release-notes/release-notes.html
> [4] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/installation/installation.instruction.ht
> [5] http://docs.opnfv.org/en/stable-
> euphrates/submodules/fuel/docs/release/userguide/userguide.html
> [6] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/release-notes/release-
> notes.html
> [7] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/installation/installation.instructi
> on.ht
> [8] http://docs.opnfv.org/en/stable-
> euphrates/submodules/armband/docs/release/userguide/userguide.html
>
> > -Original Message-
> > From: Alexandru Avadanii
> > Sent: Friday, October 20, 2017 7:38 PM
> > To: 'Aric Gardner'
> > Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; Bob Monkman;
> > 'Michail Polenchuk'
> > Subject: [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts
> >
> > Hi,
> > Fuel and Armband projects are pleased to announce the public release
> > of Euphrates 5.0 (opnfv-5.0.0).
> >
> > Note that starting with this release, Fuel no longer produces ISO
> > artifacts, the only deliverable being the git repo itself (similar to Joid).
> >
> > 1. Fuel artifacts
> > Git tag at [1], documentation [3, 4].
> >
> > 2. Armband artifacts
> > Git tag at [2], documentation [5, 6].
> >
> > BR,
> > Alex
> >
> > [1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.0.0
> > [2] https://git.opnfv.org/armband/tag/?h=opnfv-5.0.0
> > [3] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/fuel/docs/release/release-notes/release-notes.htm
> > l
> > [4] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/fuel/docs/release/installation/installation.instr
> > uction.ht
> > ml
> > [5] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/armband/docs/release/release-notes/release-
> > notes.html
> > [6] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/armband/docs/release/installation/installation.in
> > structi
> > on.html
> >
> > > -Original Message-
> > > From: Alexandru Avadanii
> > > Sent: Friday, July 14, 2017 9:49 PM
> > > To: 'Aric Gardner'
> > > Cc: opnfv-tech-discuss@lists.opnfv.org
> > > Subject: FW: Fuel and Armband Fuel Danube 3.0 ISOs
> > >
> > > Hi,
> > > Fuel and Armband projects are pleased to announce the public release
> > > of Danube 3.0.
> > >
> > > 1. Fuel artifacts
> > > Git tag at [1], ISO build logs [3], ISO [5], documentation [7, 8, 9].
> > >
> > > 2. Armband artifacts
> > > Git tag at [2], ISO buil

[opnfv-tech-discuss] [fuel] FW: Cleaning up Fuel @ OPNFV committer rolls

[Alexandru Avadanii]

Hi,
Forwarding this to the list (and attaching responses), so mailman will archive 
it and we can link it in [1].
After this cleanup, we will have 3 Fuel committers, all of them currently 
active.

BR,
Alex

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

From: Greg Elkinbard [mailto:elkin...@gmail.com]
Sent: Wednesday, April 25, 2018 9:42 PM
To: Nikolas Hermanns; Jonas Bjurel; Stefan Berg K; Daniel Smith; Szilard 
Cserey; Michal Skalski; Guo, Ruijing; Fedor Zhadaev; Alexandru Avadanii; 
Michail Polenchuk; Guillermo Herrero
Cc: Cristina Pauna
Subject: Cleaning up Fuel @ OPNFV committer rolls

Hi folks,
we are trying to reorganize the Fuel project.
We currently have a large list of committers, who are not very active. This 
makes decisions which require committer vote hard. So we would like to prune 
this list down to people who intend to actively participate in the project.

If you would like to remain a committer on the Fuel project.
Please notify me and Cristina by May 2nd.

Thanks
Greg


This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
--- Begin Message ---
Hi, All,

Pls just remove me from committer list☺

Thanks,
-Ruijing


From: Greg Elkinbard [mailto:elkin...@gmail.com]
Sent: Thursday, April 26, 2018 2:42 AM
To: Nikolas Hermanns ; Jonas Bjurel 
; Stefan Berg K ; Daniel 
Smith ; Szilard Cserey ; 
Michal Skalski ; Guo, Ruijing ; 
Fedor Zhadaev ; Alexandru Avadanii 
; Michail Polenchuk ; 
guillermo.herr...@enea.com
Cc: Cristina Pauna 
Subject: Cleaning up Fuel @ OPNFV committer rolls

Hi folks,
we are trying to reorganize the Fuel project.
We currently have a large list of committers, who are not very active. This 
makes decisions which require committer vote hard. So we would like to prune 
this list down to people who intend to actively participate in the project.

If you would like to remain a committer on the Fuel project.
Please notify me and Cristina by May 2nd.

Thanks
Greg

--- End Message ---
--- Begin Message ---
If I still am a contributor, you can remove me./Jonas

Skickat från min iPhone

> 25 apr. 2018 kl. 20:42 skrev Greg Elkinbard :
>
> Hi folks,
> we are trying to reorganize the Fuel project.
> We currently have a large list of committers, who are not very active. This 
> makes decisions which require committer vote hard. So we would like to prune 
> this list down to people who intend to actively participate in the project.
>
> If you would like to remain a committer on the Fuel project.
> Please notify me and Cristina by May 2nd.
>
> Thanks
> Greg
>
--- End Message ---
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Fuel] call for PTL elections

[Alexandru Avadanii]

Hi, Greg,
Thank you very much for the great work done as Fuel PTL. I think we wouldn’t 
have a Fuel@OPNFV today without you, so we’re all thankful for that!

BR,
Alex

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Greg Elkinbard
Sent: Monday, May 07, 2018 9:22 PM
To: TECH-DISCUSS OPNFV
Subject: [opnfv-tech-discuss] [Fuel] call for PTL elections

Hi folks,
As many of you remember, I have stepped down as Fuel PTL, but we have never had 
an election to appoint a new one. Time to correct this issue.


We need to elect a new Fuel PTL.
Any active project committer is allowed to run.

However I would like to nominate Alexandru Avadanii for his extra ordinary 
contributions to the project over the last several years.

Voting period is open for one week. Project committers are allowed to vote.
Committers please respond with the name of the candidate for PTL you support.

Thanks
Greg




This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [release][gambia][fuel] Fuel Intent to Participate in the OPNFV Gambia Release

[Alexandru Avadanii]

This is to inform the TSC that the Fuel@OPNFV project intends to participate in 
the Gambia release.
We intend to follow the traditional release track for select scenarios.

BR,
Alex

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
___
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] [opnfv-6.1.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,
Fuel and Armband 6.1.0 release information:

1. Fuel artifacts (x86_64)
- git tag gerrit change [1];
- git tag [2] (will go live once [1] is merged);
- documentation [4, 5, 6];

2. Armband Fuel artifacts (aarch64)
- git tag gerrit change [1];
- git tag [3] (will go live once [1] is merged);
- documentation [7, 8, 9];

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/57931/
[2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.1.0
[3] https://git.opnfv.org/armband/tag/?h=opnfv-6.1.0
[4] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/release-notes/release-notes.html
[5] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html
[6] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/userguide/userguide.html
[7] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/release-notes/release-notes.html
[8] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/installation/installation.instruction.html
[9] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/userguide/userguide.html

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, April 27, 2018 9:54 PM
> To: 'Aric Gardner'
> Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; 'Bob Monkman';
> 'Michail Polenchuk'
> Subject: [opnfv-6.0.0] Fuel and Armband Fuel Release Artifacts
>
> Hi,
> After a tricky release cycle, we are happy to be able to release all planned
> scenarios as expected.
>
> 1. Fuel artifacts (x86_64)
> - git tag gerrit change [1];
> - git tag [2] (will go live once [1] is merged);
> - documentation [4, 5, 6];
>
> 2. Armband Fuel artifacts (aarch64)
> - git tag gerrit change [1];
> - git tag [3] (will go live once [1] is merged);
> - documentation [7, 8, 9];
>
> BR,
> Alex
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/56809/
> [2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.0.0
> [3] https://git.opnfv.org/armband/tag/?h=opnfv-6.0.0
> [4] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/release-notes/release-notes.html
> [5] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/installation/installation.instruction.html
> [6] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/userguide/userguide.html
> [7] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/release-notes/release-notes.html
> [8] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/installation/installation.instruction.h
> tml
> [9] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/userguide/userguide.html
>
> > -Original Message-
> > From: Alexandru Avadanii
> > Sent: Friday, December 15, 2017 9:44 PM
> > To: 'Aric Gardner'
> > Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; 'Bob
> > Monkman'; 'Michail Polenchuk'
> > Subject: [opnfv-5.1.0] Fuel and Armband Fuel Release Artifacts
> >
> > Hi,
> >
> > 1. Fuel artifacts
> > - git tag [1];
> > - documentation [3, 4, 5];
> >
> > 2. Armband artifacts
> > - git tag [2];
> > - documentaiton [6, 7, 8] - identical to Fuel@OPNFV, we just publish
> > it for uniformity;
> >
> > BR,
> > Alex
> >
> > [1] https://git.opnfv.org/fuel/tag/?h=opnfv-5.1.0
> > [2] https://git.opnfv.org/armband/tag/?h=opnfv-5.1.0
> > [3] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/fuel/docs/release/release-notes/release-notes.htm
> > l
> > [4] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/fuel/docs/release/installation/installation.instr
> > uction.ht
> > [5] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/fuel/docs/release/userguide/userguide.html
> > [6] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/armband/docs/release/release-notes/release-
> > notes.html
> > [7] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/armband/docs/release/installation/installation.in
> > structi
> > on.ht
> > [8] http://docs.opnfv.org/en/stable-
> > euphrates/submodules/armband/docs/release/userguide/userguide.html
> >
> > > -Original Message-
> > > From: Alexandru Avadanii
> > > Sent: Friday, October 20, 2017 7:38 PM
> > > To: 'Aric Gardner'
> > > Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; Bob
> > > Monkman; 'Michail Polenchuk'
> > > Subject: [opnfv-5.0.0] Fuel and Armband Fuel Release Artifacts
> > >
> > >

Re: [opnfv-tech-discuss] [release][gambia] MS3.1 - June 29

[Alexandru Avadanii]

Hi,
Fuel & Armband CI runs:

-  nosdn x86_64 HA [1];

-  nosdn aarch64 HA [2];

-  ODL x86_64 HA [3] (last CI run was before the new tests were 
skipped, so please ignore failures related to those);

-  ODL aarch64 HA [4] (ditto);

With the new functest testcases skipped, both architectures pass all HC (for 
aarch64 we tested this on a non-CI POD recently and will be reflected in OPFNV 
CI within 1-2 days after some more runs).

BR,
Alex

[1] 
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/295/console
[2] 
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/296/console
[3] 
https://build.opnfv.org/ci/job/functest-fuel-armband-baremetal-daily-master/18/console
[4] 
https://build.opnfv.org/ci/job/functest-fuel-armband-baremetal-daily-master/17/console


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Monday, June 25, 2018 7:16 PM
To: Tim Rozet; Cristina Pauna; Alexandru Avadanii; Bob Monkman; Chigang 
(Justin); Xueyifei (Yifei Xue); huangxiangyu
Cc: TECH-DISCUSS OPNFV; opnfv-project-leads; tim.irn...@ericsson.com
Subject: Re: [release][gambia] MS3.1 - June 29

Reminder... this Friday.

On Wed, Jun 20, 2018 at 3:35 PM David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

MS3.1 is just 9 days away (June 29).

Requirements:

  *   Integration with OS "Queens"
  *   Successfully deploy sdn scenario
  *   Pass HC for both nosdn and sdn scenarios.
Recall that the requirements of MS3.2 have been consolidated with MS3.1 and 
MS3.2 is deprecated.

Let me know if you have any questions.

David
--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride


--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21487): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21487
Mute This Topic: https://lists.opnfv.org/mt/22620047/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [opnfv-6.2.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,
Fuel and Armband 6.2.0 release information:

1. Fuel artifacts (x86_64)
- git tag gerrit change [1];
- git tag [2] (will go live once [1] is merged);
- documentation [4, 5, 6];

2. Armband Fuel artifacts (aarch64)
- git tag gerrit change [1];
- git tag [3] (will go live once [1] is merged);
- documentation [7, 8, 9];

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/59365/
[2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.2.0
[3] https://git.opnfv.org/armband/tag/?h=opnfv-6.2.0
[4] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/release-notes/release-notes.html
[5] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html
[6] 
http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/userguide/userguide.html
[7] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/release-notes/release-notes.html
[8] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/installation/installation.instruction.html
[9] 
http://docs.opnfv.org/en/stable-fraser/submodules/armband/docs/release/userguide/userguide.html

> -Original Message-
> From: Alexandru Avadanii
> Sent: Friday, May 25, 2018 9:05 PM
> To: 'Aric Gardner'
> Cc: 'David McBride'; 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; 'Bob
> Monkman'; 'Michail Polenchuk'
> Subject: [opnfv-6.1.0] Fuel and Armband Fuel Release Artifacts
>
> Hi,
> Fuel and Armband 6.1.0 release information:
>
> 1. Fuel artifacts (x86_64)
> - git tag gerrit change [1];
> - git tag [2] (will go live once [1] is merged);
> - documentation [4, 5, 6];
>
> 2. Armband Fuel artifacts (aarch64)
> - git tag gerrit change [1];
> - git tag [3] (will go live once [1] is merged);
> - documentation [7, 8, 9];
>
> BR,
> Alex
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/57931/
> [2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.1.0
> [3] https://git.opnfv.org/armband/tag/?h=opnfv-6.1.0
> [4] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/release-notes/release-notes.html
> [5] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/installation/installation.instruction.html
> [6] http://docs.opnfv.org/en/stable-
> fraser/submodules/fuel/docs/release/userguide/userguide.html
> [7] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/release-notes/release-notes.html
> [8] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/installation/installation.instruction.h
> tml
> [9] http://docs.opnfv.org/en/stable-
> fraser/submodules/armband/docs/release/userguide/userguide.html
>
> > -Original Message-
> > From: Alexandru Avadanii
> > Sent: Friday, April 27, 2018 9:54 PM
> > To: 'Aric Gardner'
> > Cc: 'opnfv-tech-discuss@lists.opnfv.org'; 'svc-armband'; 'Bob
> > Monkman'; 'Michail Polenchuk'
> > Subject: [opnfv-6.0.0] Fuel and Armband Fuel Release Artifacts
> >
> > Hi,
> > After a tricky release cycle, we are happy to be able to release all
> > planned scenarios as expected.
> >
> > 1. Fuel artifacts (x86_64)
> > - git tag gerrit change [1];
> > - git tag [2] (will go live once [1] is merged);
> > - documentation [4, 5, 6];
> >
> > 2. Armband Fuel artifacts (aarch64)
> > - git tag gerrit change [1];
> > - git tag [3] (will go live once [1] is merged);
> > - documentation [7, 8, 9];
> >
> > BR,
> > Alex
> >
> > [1] https://gerrit.opnfv.org/gerrit/#/c/56809/
> > [2] https://git.opnfv.org/fuel/tag/?h=opnfv-6.0.0
> > [3] https://git.opnfv.org/armband/tag/?h=opnfv-6.0.0
> > [4] http://docs.opnfv.org/en/stable-
> > fraser/submodules/fuel/docs/release/release-notes/release-notes.html
> > [5] http://docs.opnfv.org/en/stable-
> > fraser/submodules/fuel/docs/release/installation/installation.instruct
> > ion.html
> > [6] http://docs.opnfv.org/en/stable-
> > fraser/submodules/fuel/docs/release/userguide/userguide.html
> > [7] http://docs.opnfv.org/en/stable-
> > fraser/submodules/armband/docs/release/release-notes/release-notes.htm
> > l
> > [8] http://docs.opnfv.org/en/stable-
> > fraser/submodules/armband/docs/release/installation/installation.instr
> > uction.h
> > tml
> > [9] http://docs.opnfv.org/en/stable-
> > fraser/submodules/armband/docs/release/userguide/userguide.html
> >
> > > -Original Message-
> > > From: Alexandru Avadanii
> > > Sent: Friday, December 15, 2017 9:44 PM
> > > To: 'Aric Gardner'
> > > Cc: 'opnfv-tech-discuss@lists.opnfv.o

Re: [opnfv-tech-discuss] [gerrit] Allow forge author across projects on Gerrit

[Alexandru Avadanii]

+1

From: opnfv-tech-discuss@lists.opnfv.org 
[mailto:opnfv-tech-discuss@lists.opnfv.org] On Behalf Of Aric Gardner
Sent: Wednesday, July 11, 2018 10:00 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [gerrit] Allow forge author across projects on 
Gerrit

Forge author is extremely useful if you ever want to update someone else's 
patch.
To align with all other LFN projects I would like to allow forge author 
globally for any opnfv project member that is properly signed off.
This is standard practice and will facilitate cross project participation.


This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21579): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21579
Mute This Topic: https://lists.opnfv.org/mt/23248193/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [announce][election] Opening nominations for OPNFV Technical Steering Committee (TSC)

[Alexandru Avadanii]

Hi,
I would like to nominate 3 people for TSC. Somehow I feel the statements are 
superfluous ☺
I know I’m not doing a great job at praising them here, but that’s not the 
point; most of you should have worked with them at some point or another.


1.   Name: Tim Rozet

Organization: Red Hat

Statement: Tim is one of the few people who actually works with a very large 
number of OPNFV projects, contributing to installers, testing projects, 
integration and not only.

His expertise and professionalism are something we can all learn from.


2.   Name: Trevor Bramwell

Organization: LF

Statement: Trevor is one of the few people touching all OPNFV projects, 
contributing to both infrastructure and development. His contributions speak 
for themselves,

while his friendly attitude makes our collaboration always a pleasure.


3.   Dimitrios Markou

Organization: Intracom Telecom

Statement: Dimitris is one of the most active contributors in SDN-related 
projects, touching everything from installers to infrastructure and testing 
suites. His work on ODL

(including maintaining the PPA deb repository) is reflected by the constant 
increase in stability, performance and interoperability of our SDN scenarios in 
Fuel, Apex etc.

BR,
Alex


From: opnfv-tech-discuss@lists.opnfv.org 
[mailto:opnfv-tech-discuss@lists.opnfv.org] On Behalf Of David McBride
Sent: Friday, August 24, 2018 8:48 PM
To: TSC OPNFV; TECH-DISCUSS OPNFV
Cc: tim.irn...@ericsson.com; Heather Kirksey
Subject: [opnfv-tech-discuss] [announce][election] Opening nominations for 
OPNFV Technical Steering Committee (TSC)

Team,

Today, we begin nominations for a new TSC, consisting of 15 members, in 
accordance with the Community Election 
Procedures.
  Individuals who are eligible to both vote and run for a TSC position are 
those with 20 or more contributions on this list of active 
contributors.
  Before nominating someone, please consult the list and verify that the 
individual has 20 or more contributions.  You may find a schedule of election 
activities 
here.

PTL Input to the Active Contributor List
Note that the election procedures have a provision for adding and individual to 
the active contributor list, who has less than 20 contributions, yet who has 
make significant contributions to the OPNFV community.  Per the election 
procedure:

PTLs have an input on the "active contributor list" compiled over a 2-week 
review period (with a view that this step primarily targets at making sure 
qualified people that haven't been identified via the metric get added to the 
list)
I am working with the TSC to define a specific process for this situation.  In 
the mean time, if you are a PTL, and you would like to add someone to the 
active contributor list, please contact me directly with the name and a brief 
statement about why they should be included on the list.  Note that this action 
simply adds them to the active contributor list, they still must be nominated, 
separately.  Also, note that the 2-week review period for the active 
contributor list, cited in the election procedure, ends on Aug 31.

Nomination procedure

  1.  You may nominate yourself, or someone else.

 *   Remember that both you and the person nominated must be on the active 
contributor 
list
 with 20 or more contributions.
 *   If you nominate someone else, I will confirm with that person that 
they accept the nomination.

  1.  Announce the nomination with a "reply all" to this email prior to 5 p.m. 
(PT), Sept 7.
  2.  Please include the following information:

 *

Re: [opnfv-tech-discuss] [announce][election] Opening nominations for OPNFV Technical Steering Committee (TSC)

[Alexandru Avadanii]

Hi,
I think Tim might be on PTO/vacation, but I reached him before sending out the 
nomination.
Just in case his reply does not arrive before the deadline, below is his 
informal response.

Sorry for sending out the nomination(s) so close to the deadline.
Thank you,
Alex

From: Tim Rozet [mailto:tro...@redhat.com]
Sent: Friday, September 07, 2018 4:36 PM
To: Alexandru Avadanii
Subject: Re: OPNFV TSC Nomination

Hi Alex,
That would be great. Thanks for thinking of me.

>On Fri, Sep 7, 2018, 9:12 AM Alexandru Avadanii 
>mailto:alexandru.avada...@enea.com>> wrote:
>Hi, Tim,
>I'm writing up my TSC proposal and I was thinking about nominating you, so I 
>wanted to check with you first if you'd be interested in being nominated in 
>the first place.
>
>Thanks,
>Alex

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Friday, September 07, 2018 6:39 PM
To: Alexandru Avadanii
Cc: TSC OPNFV; TECH-DISCUSS OPNFV; tim.irn...@ericsson.com; Heather Kirksey; 
Tim Rozet; Trevor Bramwell; Dimitris
Subject: Re: [opnfv-tech-discuss] [announce][election] Opening nominations for 
OPNFV Technical Steering Committee (TSC)

Tim - do you accept the nomination?

On Fri, Sep 7, 2018 at 7:29 AM Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>> wrote:
Hi,
I would like to nominate 3 people for TSC. Somehow I feel the statements are 
superfluous ☺
I know I’m not doing a great job at praising them here, but that’s not the 
point; most of you should have worked with them at some point or another.


1.   Name: Tim Rozet

Organization: Red Hat

Statement: Tim is one of the few people who actually works with a very large 
number of OPNFV projects, contributing to installers, testing projects, 
integration and not only.

His expertise and professionalism are something we can all learn from.


2.   Name: Trevor Bramwell

Organization: LF

Statement: Trevor is one of the few people touching all OPNFV projects, 
contributing to both infrastructure and development. His contributions speak 
for themselves,

while his friendly attitude makes our collaboration always a pleasure.


3.   Dimitrios Markou

Organization: Intracom Telecom

Statement: Dimitris is one of the most active contributors in SDN-related 
projects, touching everything from installers to infrastructure and testing 
suites. His work on ODL

(including maintaining the PPA deb repository) is reflected by the constant 
increase in stability, performance and interoperability of our SDN scenarios in 
Fuel, Apex etc.

BR,
Alex


From: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 
[mailto:opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>]
 On Behalf Of David McBride
Sent: Friday, August 24, 2018 8:48 PM
To: TSC OPNFV; TECH-DISCUSS OPNFV
Cc: tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>; Heather Kirksey
Subject: [opnfv-tech-discuss] [announce][election] Opening nominations for 
OPNFV Technical Steering Committee (TSC)

Team,

Today, we begin nominations for a new TSC, consisting of 15 members, in 
accordance with the Community Election 
Procedures<https://url10.mailanyone.net/v1/?m=1ftGCE-000XWc-4a&i=57e1b682&c=H5fuxEWosY5yQdvBrORv9VpICsWDPbtmyHX9ZOZvh9I5Jvp9UGOVM2eQC6y__ctZT74GYZSMi6QRpOkwYxGaBM2cL2I2UJR6gHZ5U5sqMvCl4Oxd3uZl1lwMBDuKCdSto-DovoqVr4mCQ_cwObvqHG1K1wXF64qWi1Cq_vrfwGCG7VuBukb34DE9r1zSlh4AW2oK1yl01wKZQ6xynnh1MZ5LIraaHs7LTZu13bZSa-RhXbyhwRUGUi9pTgLQujztitjNPaH4qeGm0oPCaoJc8Q>.
  Individuals who are eligible to both vote and run for a TSC position are 
those with 20 or more contributions on this list of active 
contributors<https://url10.mailanyone.net/v1/?m=1ftGCE-000XWc-4a&i=57e1b682&c=xWWK8s1a8sc_8uQ8eY_DAV4vGq-rDUYMJvzuRZS5zVg9EZ87GNgLWDeIilM4o6dRI5YZvuENXJx9YFnPTYZCLy2mKzY75uZBhW8fgY0Gv82j04M8LAkYum0fnJllwNogKBEqkQXC3-uOTAZZApAelkBXvtEZm909jbq6vYpCC_oeqmyg17iWewaw5FInS1NZ8un8N-88fu8Im9WbRDlO4mf94wwdtOHKIPfGaCD-7TeYg5h3z3pXOCrvUu71WCmxgUleVN-G-dCzpDn7CR3gfg>.
  Before nominating someone, please consult the list and verify that the 
individual has 20 or more contributions.  You may find a schedule of election 
activities 
here<https://url10.mailanyone.net/v1/?m=1ftGCE-000XWc-4a&i=57e1b682&c=vtm_-70nJOIDlpkxBvCw9fRinGrHC90XK8gz7DlGKlGyfJ0nrUS13AxX6KyS1-pXoxMO1WulCFd2geSy_TbiSPOHXv70uRWVY86r9-mv1NxriBNvZRrph9iVSH-MfU6MskQhyqPzqox1u3ite-30nMqLQ3PyfH2hK6FKZJKgR5-IopjvxmLTOR-kvt_VXUkbcGSIqlp37mV_dD4d4QlJ_5y8NbmAi6tPZ29mmIvgv7cPN6VfYyKsOCR3_dBbAC4L5FXaJiRLt2AoF5_SUdwh3hgGGZ02NsQ6GA7ME4wQtANZ9euAOlt53659l47zTEk7>.

PTL Input to the Active Contributor List
Note that the election procedures have a provision for adding and individual to 
the active contributor list, who has less than 20 contributions, yet who has 
make significant contributions to the OPNFV community.  Per the election 
procedure:

PTLs have an input on the "active contributor list" compiled over a

[opnfv-tech-discuss] [fuel] Nominating Cristina Pauna as committer

[Alexandru Avadanii]

Hi,
I would like to nominate Cristina Pauna (Enea) as a committer in Fuel@OPNFV.
I have been in contact with Cristina and she is willing to take on the role.

Cristina is one of the main contributors in multiple OPNFV projects
and she has been one of the most active and valuable contributors during the 
last release cycles.

Fuel committers, please cast your vote via gerrit (+2) in [1].

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/62945

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22085): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22085
Mute This Topic: https://lists.opnfv.org/mt/26220819/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] #fuel Intent to Participate in the OPNFV Hunter Release

[Alexandru Avadanii]

Hi,

The purpose of this mail is to notify the OPNFV TSC that the Fuel project 
intends to participate in the OPNFV Hunter release.
We intend to follow the traditional track.

BR,
Alex

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22316): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22316
Mute This Topic: https://lists.opnfv.org/mt/28036980/21656
Mute #fuel: https://lists.opnfv.org/mk?hashtag=fuel&subid=2783016
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [opnfv-7.0.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

Fuel and Armband 7.0.0 release information:

1. Fuel artifacts:
- git tag [1];
- documentation [3, 4, 5];

2. Armband Fuel artifacts:
- git tag [2];
- documentation [6, 7, 8];

NOTE: Although we release Armband like we did in the previous releases, all 
AArch64 specifics are now upstream in OPNFV Fuel as well, so starting with 
7.0.0, the Fuel artifacts can be used for any/all supported architectures. 
Using the armband git repo will continue to work like before, for backwards 
compatibility.

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-7.0.0
[2] https://git.opnfv.org/armband/tag/?h=opnfv-7.0.0
[3] 

 
https://opnfv-fuel.readthedocs.io/en/latest/release/release-notes/release-notes.html
[4] 
https://opnfv-fuel.readthedocs.io/en/latest/release/installation/installation.instruction.html
[5] 

 
https://opnfv-fuel.readthedocs.io/en/latest/release/userguide/userguide.html
[6] 

 
https://opnfv-armband.readthedocs.io/en/latest/release/release-notes/release-notes.html
[7] 
https://opnfv-armband.readthedocs.io/en/latest/release/installation/installation.instruction.html
[8] 

 
https://opnfv-armband.readthedocs.io/en/latest/release/userguide/userguide.html

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22338): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22338
Mute This Topic: https://lists.opnfv.org/mt/28071960/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [opnfv-7.1.0] Fuel and Armband Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

Fuel and Armband 7.1.0 release information:

1. Fuel artifacts:
- git tag [1];
- documentation [3, 4, 5];

2. Armband Fuel artifacts:
- git tag [2];
- documentation [6, 7, 8];

NOTE: Although we release Armband like we did in the previous releases, all 
AArch64 specifics are now upstream in OPNFV Fuel as well, so starting with 
7.0.0, the Fuel artifacts can be used for any/all supported architectures. 
Using the armband git repo will continue to work like before, for backwards 
compatibility.

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-7.1.0
[2] https://git.opnfv.org/armband/tag/?h=opnfv-7.1.0
[3] 
https://opnfv-fuel.readthedocs.io/en/stable-gambia/release/release-notes/release-notes.html
[4] 
https://opnfv-fuel.readthedocs.io/en/stable-gambia/release/installation/installation.instruction.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html>
[5] 
https://opnfv-fuel.readthedocs.io/en/stable-gambia/release/userguide/userguide.html
[6] 
https://opnfv-armband.readthedocs.io/en/stable-gambia/release/release-notes/release-notes.html
[7] 
https://opnfv-armband.readthedocs.io/en/stable-gambia/release/installation/installation.instruction.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html>
[8] 
https://opnfv-armband.readthedocs.io/en/stable-gambia/release/userguide/userguide.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/userguide/userguide.html>

From: Alexandru Avadanii
Sent: Saturday, November 10, 2018 4:44 PM
To: David McBride
Cc: opnfv-tech-discuss@lists.opnfv.org; svc-armband; Bob Monkman
Subject: [opnfv-7.0.0] Fuel and Armband Fuel Release Artifacts


Hi,

Fuel and Armband 7.0.0 release information:

1. Fuel artifacts:
- git tag [1];
- documentation [3, 4, 5];

2. Armband Fuel artifacts:
- git tag [2];
- documentation [6, 7, 8];

NOTE: Although we release Armband like we did in the previous releases, all 
AArch64 specifics are now upstream in OPNFV Fuel as well, so starting with 
7.0.0, the Fuel artifacts can be used for any/all supported architectures. 
Using the armband git repo will continue to work like before, for backwards 
compatibility.

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-7.0.0
[2] https://git.opnfv.org/armband/tag/?h=opnfv-7.0.0
[3] 
https://opnfv-fuel.readthedocs.io/en/latest/release/release-notes/release-notes.html
[4] 
https://opnfv-fuel.readthedocs.io/en/latest/release/installation/installation.instruction.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html>
[5] 
https://opnfv-fuel.readthedocs.io/en/latest/release<https://opnfv-fuel.readthedocs.io/en/latest/release/release-notes/release-notes.html>/userguide/userguide.html
[6] 
https://opnfv-armband.readthedocs.io/en/latest/release/release-notes/release-notes.html
[7] 
https://opnfv-armband.readthedocs.io/en/latest/release/installation/installation.instruction.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/installation/installation.instruction.html>
[8] 
https://opnfv-armband.readthedocs.io/en/latest/release/userguide/userguide.html<http://docs.opnfv.org/en/stable-fraser/submodules/fuel/docs/release/userguide/userguide.html>

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22565): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22565
Mute This Topic: https://lists.opnfv.org/mt/28755018/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [fuel] Dovetail jobs failed on arm-pod10

[Alexandru Avadanii]

Hi,

I downgraded pip to 8.1.1 (the version installed by APT).

I also had to remove the locally installed pip (using `sudo python -m pip 
uninstall pip`.


Unless we have a stray job that calls `sudo pip --upgrade pip`, this issue 
should not regress.

Please ping me if you see this happening again.


BR,

Alex



From: opnfv-tech-discuss@lists.opnfv.org  
on behalf of xudan 
Sent: Tuesday, April 16, 2019 10:45:20 AM
To: Cristina Pauna; David McBride; Trevor Bramwell
Cc: Aric Gardner; opnfv-tech-discuss@lists.opnfv.org; Alexandru Avadanii
Subject: Re: [opnfv-tech-discuss] [fuel] Dovetail jobs failed on arm-pod10


Thanks everyone for the help.



From: Cristina Pauna [mailto:cristina.pa...@enea.com]
Sent: Tuesday, April 16, 2019 3:26 PM
To: David McBride ; Trevor Bramwell 

Cc: Aric Gardner ; 
opnfv-tech-discuss@lists.opnfv.org; xudan (N) ; Alexandru 
Avadanii 
Subject: RE: [opnfv-tech-discuss] [fuel] Dovetail jobs failed on arm-pod10



Hi all,



The pod is in Enea Lab, we’ll look into it.



Thanks,

Cristina



From: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 
[mailto:opnfv-tech-discuss@lists.opnfv.org] On Behalf Of David McBride
Sent: Monday, April 15, 2019 11:25 PM
To: Trevor Bramwell 
mailto:tbramw...@linuxfoundation.org>>
Cc: Aric Gardner 
mailto:agard...@linuxfoundation.org>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
xudan mailto:xuda...@huawei.com>>
Subject: Re: [opnfv-tech-discuss] [fuel] Dovetail jobs failed on arm-pod10



Ok - thanks. Has the lab owner been contacted directly. Who is it?



David



On Mon, Apr 15, 2019 at 11:30 AM Trevor Bramwell 
mailto:tbramw...@linuxfoundation.org>> wrote:

Hey David,

This is on the POD/Lab owner to fix. Neither me nor Aric have have
access to arm-pod10.

I can provide some insight into the error though. There is a system
version of pip installed, which is called from a wrapper script
/usr/local/bin/pip. If anyone runs `sudo pip install --upgrade pip` it
will upgrade the system version of pip, but not the wrapper script
(which comes with the package), causing `pip` to fail, as around version
9/10 they renamed the 'main' function.

To fix this, pip needs to be downgraded on the system (or reinstalled),
and someone needs to find out which script/job/user upgraded pip so the
problem doesn't repeat.

Regards,
Trevor Bramwell

On Mon, Apr 15, 2019 at 07:20:55AM -0700, David McBride wrote:
> +Aric Gardner 
> mailto:agard...@linuxfoundation.org>> +Trevor 
> Bramwell
> mailto:tbramw...@linuxfoundation.org>>
>
> On Mon, Apr 15, 2019 at 2:26 AM xudan 
> mailto:xuda...@huawei.com>> wrote:
>
> > Hi all,
> >
> >
> >
> > All Dovetail jobs failed when running on arm-pod10, refer to
> > https://build.opnfv.org/ci/view/dovetail/job/dovetail-fuel-baremetal-default-optional-master/206/console<https://url10.mailanyone.net/v1/?m=1hG8AI-000UBP-5m&i=57e1b682&c=PtG_Pea1_zdfY7dIKYt_5TCKO-3dhXRoQAygvxa50cJAX55GkN3hQO1c9FHW72bbliQGNZ2D4tpdTsjN8zK7k3iJ9mOSFwl8SSRG4bXtZ30dviIJg0wwNGAV4bXlcVte7BlM82ai_Bw9fCI1BuxoHCtCaMX_mxVuOQQDM1kBQCCro-b_ZIkBHFzGzn1bELbcqmhoZF0PbBmR14S6TRzD_ZI6piB_czLtUBiI6Qju6fC1GFs8NHF2WYC6UBVxTGjJTU8FcGH-uZ6PNPPwwT6PodYO7ulbspeulc2ziF2W-pmGZpZZu6CEEaxBqZeND76WRwwM8itFsBwLQJteNFdyhQ>
> > .
> >
> > The Error message is:
> >
> > Traceback (most recent call last):
> >
> >   File "/usr/local/bin/pip", line 7, in 
> >
> > from pip import main
> >
> > ImportError: cannot import name main
> >
> >
> >
> > I guess it can be fixed after updating the version of pip on arm-pod10.
> > Could someone help to check this?
> >
> > Thanks in advance.
> >
> >
> >
> > Dan Xu
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> >
> > View/Reply Online (#23050):
> > https://lists.opnfv.org/g/opnfv-tech-discuss/message/23050<https://url10.mailanyone.net/v1/?m=1hG8AI-000UBP-5m&i=57e1b682&c=hBVWAKyCVr1OeNeQY-Y080CGCljJswBQDXLTLLmahOgXza-eqZVUuVFgPkGmoN-SCG5MNCZPcBH68Jte3P_-UDKNgd2gjxw_dosl1-iHNbynoC715R4kb3CIdjE0lAq849M_ywoaphMyw5sVuJ2Dn4R2-XcOrlI3sKsJMrhThIqGszWe3O3YNasbUN29Mg1_zMqbpfMT4th4VNFvFkR5DHDM-FA2KV3alD1r1uWrlAl6wUYvuNNy_h5Z5AwQLMOo6_9kYBguuoewtcRP7mcJNg>
> > Mute This Topic: 
> > https://lists.opnfv.org/mt/31186195/766177<https://url10.mailanyone.net/v1/?m=1hG8AI-000UBP-5m&i=57e1b682&c=JdH3TBUpLVp8e0-gI97x1iUjyKazqx887Hu713eJv1gLESB2PqUAB7MY1hvBPArdjpppG5gyZmVWgH40ym_MM_YuXlH1m6YwriRikCQbJTwaTsWhctVxtcVlS8j4_FDyF2nx0X9jnQrT15rEFjx-u0-SBoTaLI-oEwZkznNyw7Lzga7vUlu_cOLhhRwNjgoV_dDV_pC5UNBiooAmUhNnPdHnYk9BuQdZIq76Yj7gXSHHlfU6

[opnfv-tech-discuss] [opnfv-8.0.0] Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

Fuel release information:

1. Fuel artifacts:
- git tag [1];
- documentation [2, 3, 4];

NOTE: Although we do not release Armband like we did in the previous releases, 
all AArch64 specifics are now upstream in OPNFV Fuel as well, so starting with 
7.0.0, the Fuel artifacts can be used for any/all supported architectures.

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-8.0.0
[2] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/release-notes/release-notes.html
[3] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/installation/installation.instruction.html
[4] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/userguide/userguide.html

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23127): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23127
Mute This Topic: https://lists.opnfv.org/mt/31579015/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [opnfv-8.1.0] Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

Fuel release information:

1. Fuel artifacts:
- git tag [1] (available once [5] is merged);
- documentation [2, 3, 4];
NOTE: Although we do not release Armband like we did in the previous releases, 
all AArch64 specifics are now upstream in OPNFV Fuel as well, so starting with 
7.0.0, the Fuel artifacts can be used for any/all supported architectures.

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-8.1.0
[2] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/release-notes/release-notes.html
[3] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/installation/installation.instruction.html
[4] 
https://opnfv-fuel.readthedocs.io/en/stable-hunter/release/userguide/userguide.html
[5] https://gerrit.opnfv.org/gerrit/#/c/68156/

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23296): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23296
Mute This Topic: https://lists.opnfv.org/mt/32243061/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] MS1 - Intent-to-participate / OPNFV Iruya - Sept 30 #release #iruya

[Alexandru Avadanii]

Hi,

Fuel intends to participate in the Iruya release.

BR,
Alex

From: opnfv-tech-discuss@lists.opnfv.org  
on behalf of David McBride 
Sent: Saturday, September 14, 2019 3:58 AM
To: OLLIVIER Cédric IMT/OLN ; Juvonen, Tomi (Nokia 
- FI/Espoo) (tomi.juvo...@nokia.com) ; 付乔 
; Mingjiang Li ; Mark Beierl 
; Manuel Buil ; Yuyang (Gabriel) 
; Cristina Pauna ; S, 
Deepak ; Xuan Jia ; Koren Lev 
(korlev) ; Trinath Somanchi ; Steven 
Pisarski ; Stephen Wong ; 
Stephen Wong ; 郭莎莎 ; 
niweichen 
Cc: TECH-DISCUSS OPNFV ; Bin Hu 
; James Baker 
Subject: [opnfv-tech-discuss] MS1 - Intent-to-participate / OPNFV Iruya - Sept 
30 #release #iruya

Team,

The intent-to-participate window for the compressed Iruya release closes on 
Sept 30.  Please submit your intent-to-participate notification prior to Sept 
30.  Note that Sept 30 is also the deadline for release plans.

if you are not intending to participate in the release, it would be helpful if 
you would respond to this email to let me know.

Let me know if you have any questions.

David

--
David McBride
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
IRC: dmcbride

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23595): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23595
Mute This Topic: https://lists.opnfv.org/mt/34139220/21656
Mute #release: https://lists.opnfv.org/mk?hashtag=release&subid=2783016
Mute #iruya: https://lists.opnfv.org/mk?hashtag=iruya&subid=2783016
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [Fuel] 3 computes and baremetal

[Alexandru Avadanii]

Hi, Tomi,

Fuel already supports a dynamic number of compute nodes based on the total 
number of nodes in PDF/IDF and assumes the following node definition ordering 
in both files:

  *   the first 3 nodes in PDF/IDF are controller/gateway or opendaylight 
roles, depending on the current scenario and its type (ha/noha) - sometimes the 
3rd node remaining unused, in which case a dummy node should be defined just to 
keep this indexing assumption in place;
  *   (later edit): I see you are targeting a noha scenario, so you should 
definitely add one dummy node before the computes in PDF/IDF, just to keep our 
hardcoded indexing happy - a total a 6 nodes will be present, but the 3rd one 
will be ignores;
  *   any number of remaining nodes will be assigned the compute role (cmp001, 
cmp002, cmp003? etc.);

However, the scenario description file you attached looks a bit different than 
what I expected (also may be a bit outdated since I see the maas state in 
there):

  *   cluster:domain should match an existing directory in 
mcp/reclass/classes/cluster, so mcp-nosdn-noha.local might need to be renamed 
to mcp-ovs-noha.local (I assume you are targeting the os-nosdn-nofeature-noha 
OPNFV scenario);
  *   cluster:states should not contain maas & baremetal_init, they have been 
abstracted into the defaults.yaml used by all scenarios;
  *   virtual:nodes:control and virtual:nodes:compute should contain node roles 
(generic and not tied to the specific POD), e.g. ctl01,gtw01,cmp001,cmp002;
  *   this is probably the important bit: you don't need to define more than 2 
computes in the scenario file you attached, as long as the PDF/IDF has more 
nodes than the ones defined in that scenario file, all remaining nodes will 
also become computes;
  *   defining 3 computes in that scenario file will make the mininum nodes 
requirement 6 instead of 5, so it's up to you if you want to enforce this;

Please let me know if you need some help with adding this scenario, as Fuel 
scenario black magic is not very well documented and full of footguns ...

BR,
Alex



From: opnfv-tech-discuss@lists.opnfv.org  
on behalf of Tomi Juvonen 
Sent: Tuesday, October 1, 2019 8:22 AM
To: opnfv-tech-discuss@lists.opnfv.org 
Cc: wenjuan dong 
Subject: [opnfv-tech-discuss] [Fuel] 3 computes and baremetal


Hi,



Currently Doctor can test fault management use case with Fuel, but maintenance 
use case will need at least 3 compute nodes.



I got things through without this pdf check error earlier when only had 2 
computes (then it went as far as complaining my bridges). I guess it is not 
just having my scenario with 3 computes, but something else need to be changed 
too.



I sure need to work on the idf-file and those bridges, but before that my issue 
seems to relate to supporting 3 computes. For now also single controller is 
just fine, tried with 2 as there seems to be some controller + gw node in 
existing setups.



./deploy.sh -b file:///home/jenkins/fuel/mcp/deploy/config -l nokia-pod1 -p 
nokia-pod1 -s os-nosdn-nofeature-noha-doctor -D

…

  File "/home/tojuvone/fuel/mcp/scripts/xdf_data.sh.j2", line 66, in template

{%- if ( section_map[section] < conf.nodes | length and

  File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 430, in 
getattr

return getattr(obj, attribute)

jinja2.exceptions.UndefinedError: list object has no element 5

+ notify_e '[ERROR] Could not convert PDF to network definitions!



Any pointers to have this forwards? Is there an easy way to get more debugging 
data?



Br,

Tomi

Doctor PTL

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23613): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23613
Mute This Topic: https://lists.opnfv.org/mt/34354279/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [opnfv-9.0.0] Fuel Release Artifacts

[Alexandru Avadanii]

Hi,

Fuel release information:

1. Fuel artifacts:
- git tag [1];
- documentation [2, 3, 4];

NOTE: Documentation on RTD is not yet available due to RTD webhooks refusing to 
trigger new builds for Fuel - I'll follow up with LF on this in a ticket [5].

BR,
Alex

[1] https://git.opnfv.org/fuel/tag/?h=opnfv-9.0.0
[2] 
https://opnfv-fuel.readthedocs.io/en/stable-iruya/release/release-notes/release-notes.html
[3] 
https://opnfv-fuel.readthedocs.io/en/stable-iruya/release/installation/installation.instruction.html
[4] 
https://opnfv-fuel.readthedocs.io/en/stable-iruya/release/userguide/userguide.html
[5] https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-18869

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23895): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23895
Mute This Topic: https://lists.opnfv.org/mt/70880146/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] arm-build3 and arm-build4 will be retired

[Alexandru Avadanii]

Hi,
Since we are taking most of the Enea Pharos Lab offline soon, arm-build3 and 
arm-build4 will be retired.
I see there are some functest build jobs still occasionally running on 
arm-build4 - these should either be disabled or moved to different hosts, 
either aarch64 baremetal/VMs or using qemu in emulation mode.

Sorry for the inconvenience,
Alex

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#24424): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24424
Mute This Topic: https://lists.opnfv.org/mt/77061441/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-