[opnfv-tech-discuss] Following-up on CII Badging update for OPNFV

[Raymond Paik]

All,

A few TSC meetings ago there was an update on CII badging for OPNFV (
http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2016-August/011907.html).
There was a question on how community members could provide feedback after
reviewing the Security team members' answers captured in
https://bestpractices.coreinfrastructure.org/projects/164.

If you have any questions/feedback on the questionnaire, could you open a
Jira ticket under the "Security Group" project (Security Group
)?  Please provide your feedback by
August 19th (Friday).

Thanks,

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

Re: [opnfv-tech-discuss] [Dovetail] Aug 5 Dovetail meeting notes

[Dave Neary]

Hi Bryan,

On 08/08/2016 10:45 AM, SULLIVAN, BRYAN L wrote:
> I missed the last Dovetail meeting but from what I heard about some of
> the discussion, I’d like to seek clarification on some things that might
> have been expressed in the meeting, e.g. that implementations which will
> go thru C may not be expected to be compatible with existing OPNFV
> test suites, or at least that not all of the OPNFV test suites, e.g.
> FuncTest and Yardstick, would be expected to be tested on an certified
> implementations.
> 
> First I’d like to verify that such opinions were expressed (e.g. per
> Bin’s comment that as a result “Dovetail testing and OPNFV tests are
> different”), and have them further explained if possible.

Yes, I expressed the view that Functest and Yardstick, as testing
projects, were designed to stretch the platform - that we will
periodically add failing functest tests to validate that the tests pass
after we make a change to the upstream projects under test. They will
also include tests which are targeting specific scenarios, and are known
to fail (and thus will not be run) on other scenarios.

In that sense, the Dovetail test suite should be a subset of FuncTest
and Yardstick which pass on multiple scenarios and installers, and can
be run unchanged on stacks with (for example) a proprietary SDN controller.

> Second , given that the notes do capture the discussion and concerns
> correctly, here are some thoughts about that:
> 
> 1)  The C committee is responsible for setting the “what is
> expected” out of a certification, within some flexibility within
> Doevtail as to what/how/when that can be delivered.
> 
> 2)  Overall, it’s expected that any implementation is compatible
> with the OPNFV test suites as test frameworks. The degree of
> compatibility with specific test may be limited e.g. if the target
> hardware/software function focused on by the tests is not supported by
> the implementation (e.g. an implementation that supports only a specific
> SDNC), but the significance of such N/As needs to be carefully
> considered by the C committee or Dovetail.

This is the context for the "subset of..." I mentioned above.

Chris started a page in the wiki a couple of weeks ago to describe the
criteria for a test case in the Dovetail test framework, I and others
added to it: https://wiki.opnfv.org/pages/viewpage.action?pageId=6827269

Thanks,
Dave.

> Overall we need to ensure that any aspect of certification can work
> equally (same end result) on an OPNFV-based implementation (meaning a
> collection of the core components as released in some OPNFV release, or
> even with slight variations e.g. different versions of the components),
> or another implementation. We should not leave tests out of the Dovetail
> scope just because they will “not work” on some implementations. There
> may be good reasons for them not to work (the N/As), but if those
> reasons are simply based upon the test design, the platform vendor
> should provide a compatible version of the tests based upon the OPNFV
> tests, so that we can still certify the platform functionally. Examples
> of this may be:
> 
> -  FuncTest
> 
> o   vIMS (Clearwater IMS) is based upon Orange’s implementation of the
> Cloudify blueprint, using Cloudify as a VNFM. In the process, the
> Cloudify Manager is installed as a VM under OpenStack, and then executes
> the vIMS blueprint. I see no reason that this should not work
> essentially the same in any other environment. AFAIK, the only possible
> differences, which would need to be addressed by adding options to the
> existing FuncTest code for this, are that e.g. a different approach to
> kicking off the FuncTest framework is needed due to differences in
> Jumphost OS or configuration. But OPNFV should not be responsible for
> accommodating platform implementations that vary in this way; the vendor
> should step up and implement the support so their product can be validated.
> 
> o   The rest of FuncTest is pretty generic and I see no reason why it
> should not be supportable.
> 
> -  Yardstick
> 
> o   As with FuncTest, the framework under which Yardstick operates may
> need some tweaks for compatibility with the vendor implementation. These
> tweaks need to be contributed to OPNFV by the vendor.
> 
> o   The C program may not initially include performance benchmarking,
> but any implementation should have demonstrated compatibility with the
> Yardstick test suite.
> 
> -  Other tests that we develop for Dovetail may go beyond
> FuncTest and Yardstick, to focus on more complex use cases or specific
> technical capabilities. In principle I would expect that these would
> migrate into FuncTest and Yardstick however, over time, because if they
> are important they need to be part of the base test system. These might
> include tests for reference VNFs that we collect and run as blueprints
> under various VNFMs, e.g. thru the Models project. In those cases, if a
> vendor 

Re: [opnfv-tech-discuss] Reminder to register for the Q3 Hackfest

[Raymond Paik]

Just wanted to send a weekly reminder on the Hackfest in Toronto in a few
weeks :-)

On Mon, Aug 1, 2016 at 10:01 PM, Raymond Paik 
wrote:

> All,
>
> This is a reminder to register for the Q3 Hackfest in Toronto at
> https://www.regonline.com/OPNFVTorontoHackfest
>
> When you register for the Hackfest, you'll have the opportunity to
> register for the LinuxCon-North America at a 20% discount.  There is also a
> more affordable option to register for a Hall Pass at $100.  The Hall Pass
> gives you access to the Expo Hall, Lounge Area (OPNFV will be sponsoring
> one of the Lounges), Booth Crawl, etc.  When you register for a Hall Pass,
> you can also add the 25th Anniversary of Linux evening event for an
> additional fee.
>
> There is also a discounted room block at the Raddison (the location of the
> Hackfest), but this is limited you please book your rooms as soon as
> possible by following the instructions on the registration confirmation
> page.
>
> Thanks,
>
> Ray
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [OPNFV Helpdesk #26575] AutoReply: [SDNVPN] New committers Nikolas Hermanns and Jose Lausuch

[Tim Irnich via RT]

Hi Aric,

Here's the approval of the other two active committers. 

/Tim

-Original Message-
From: OPNFV Helpdesk via RT [mailto:opnfv-helpd...@rt.linuxfoundation.org] 
Sent: Monday, August 08, 2016 16:11
To: Tim Irnich
Subject: [OPNFV Helpdesk #26575] AutoReply: [SDNVPN] New committers Nikolas 
Hermanns and Jose Lausuch


Greetings,

Your support ticket regarding:
"[SDNVPN] New committers Nikolas Hermanns and Jose Lausuch", has been 
entered in our ticket tracker.  A summary of your ticket appears below.

If you have any follow-up related to this issue, please reply to this email or 
include:

 [OPNFV Helpdesk #26575]

in the subject line of subsequent emails.

Thank you,
Linux Foundation Support Team

-
Dear TSC,

Jose Lausuch and Nikolas Hermanns have been nominated and accepted as 
committers by the SDNVPN project. Congrats to both!

Helpdesk, please add them to the SDNVPN submitters group. Thank you...

Regards, Tim

From: Jan Scheurich
Sent: Monday, August 08, 2016 15:54
To: Tim Irnich; MORIN Thomas IMT/OLN (thomas.mo...@orange.com); Prem sankar G; 
Diego Garcia del Rio (di...@nuagenetworks.net)
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [SDNVPN] Nominations for Committer promotion

+1 from my side!

BR, Jan

From: Tim Irnich
Sent: Tuesday, 02 August, 2016 16:40
To: MORIN Thomas IMT/OLN 
(thomas.mo...@orange.com); Jan Scheurich; Prem 
sankar G; Diego Garcia del Rio 
(di...@nuagenetworks.net)
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN] Nominations for Committer promotion

Hi SDNVPN committers,

I would like to nominate the following SDNVPN contributors for promotion to 
committer:

Nikolas Hermanns (yes we already voted for this in January but I failed to 
execute the actual promotion at that time so I'd like to renew the vote) Jose 
Lausuch

Both are undoubtedly core contributors to the project for already quite some 
time.

Please reply with +1 if you support this promotion.

Regards, Tim


+1!

-Thomas
(mobile)

 Prem sankar G a écrit 



+1 for Niko and Jose.

Regards,

Prem



From: Tim Irnich
Sent: Tuesday, August 02, 2016 7:40 AM
To: MORIN Thomas IMT/OLN (thomas.mo...@orange.com); Jan Scheurich; Prem sankar 
G; Diego Garcia del Rio (di...@nuagenetworks.net)
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN] Nominations for Committer promotion



Hi SDNVPN committers,



I would like to nominate the following SDNVPN contributors for promotion to 
committer:



Nikolas Hermanns (yes we already voted for this in January but I failed to 
execute the actual promotion at that time so I’d like to renew the vote)

Jose Lausuch



Both are undoubtedly core contributors to the project for already quite some 
time.



Please reply with +1 if you support this promotion.



Regards, Tim

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



+1! 

-Thomas
(mobile)

 Prem sankar G a écrit 



+1 for Niko and Jose.
Regards,
Prem
 


From: Tim Irnich

Sent: Tuesday, August 02, 2016 7:40 AM
To: MORIN Thomas IMT/OLN (thomas.mo...@orange.com); Jan Scheurich; Prem sankar G; Diego Garcia del Rio (di...@nuagenetworks.net)
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN] Nominations for Committer promotion 


 
Hi SDNVPN committers,
 
I would like to nominate the following SDNVPN contributors for promotion to committer:
 
Nikolas Hermanns (yes we already voted for this in January but I failed to execute the actual promotion at that time so I’d like to renew the vote)
Jose Lausuch
 
Both are undoubtedly core contributors to the project for already quite some time.

 
Please reply with +1 if you support this promotion. 
 
Regards, Tim


_

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 

Re: [opnfv-tech-discuss] [Dovetail] Aug 5 Dovetail meeting notes

[Christopher Price]

Hi Bryan,

 

There was a fair amount of discussion around what Dovetail is testing.

One item I was trying to articulate is that the purpose of the Dovetail suite 
is to validate the compliance of a platform to the behaviors and interfaces 
targeted for compliance validation in OPNFV.  This differs from the purpose of 
Functest and Yardstick which is to validate as thoroughly as possible the 
design of the OPNFV platform.

 

I have one small concern with your comment: ”The rest of FuncTest is pretty 
generic“

Functest is anything but generic as far as a platform for generic platform 
feature validation is concerned, functest test cases derive mostly from the 
upstream community and do not, by design, provide neutral generic test cases 
for a platform.  This is not a bad thing, it simply does not lend itself to 
creating test cases that should be able to be run over any platform 
composition.  

 

Our Dovetail suite needs to work even when someone swaps out OpenStack for 
another VIM, or a completely different SDN controller for instance.

 

/ Chris

 

From:  on behalf of "SULLIVAN, 
BRYAN L" 
Date: Monday 8 August 2016 at 16:45
To: Prakash Ramchandran , TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [Dovetail] Aug 5 Dovetail meeting notes

 

Hi all,

 

I missed the last Dovetail meeting but from what I heard about some of the 
discussion, I’d like to seek clarification on some things that might have been 
expressed in the meeting, e.g. that implementations which will go thru C may 
not be expected to be compatible with existing OPNFV test suites, or at least 
that not all of the OPNFV test suites, e.g. FuncTest and Yardstick, would be 
expected to be tested on an certified implementations.

 

First I’d like to verify that such opinions were expressed (e.g. per Bin’s 
comment that as a result “Dovetail testing and OPNFV tests are different”), and 
have them further explained if possible.

 

Second, given that the notes do capture the discussion and concerns correctly, 
here are some thoughts about that:

1)   The C committee is responsible for setting the “what is expected” 
out of a certification, within some flexibility within Doevtail as to 
what/how/when that can be delivered.

2)   Overall, it’s expected that any implementation is compatible with the 
OPNFV test suites as test frameworks. The degree of compatibility with specific 
test may be limited e.g. if the target hardware/software function focused on by 
the tests is not supported by the implementation (e.g. an implementation that 
supports only a specific SDNC), but the significance of such N/As needs to be 
carefully considered by the C committee or Dovetail. 

 

Overall we need to ensure that any aspect of certification can work equally 
(same end result) on an OPNFV-based implementation (meaning a collection of the 
core components as released in some OPNFV release, or even with slight 
variations e.g. different versions of the components), or another 
implementation. We should not leave tests out of the Dovetail scope just 
because they will “not work” on some implementations. There may be good reasons 
for them not to work (the N/As), but if those reasons are simply based upon the 
test design, the platform vendor should provide a compatible version of the 
tests based upon the OPNFV tests, so that we can still certify the platform 
functionally. Examples of this may be:

-  FuncTest

ovIMS (Clearwater IMS) is based upon Orange’s implementation of the 
Cloudify blueprint, using Cloudify as a VNFM. In the process, the Cloudify 
Manager is installed as a VM under OpenStack, and then executes the vIMS 
blueprint. I see no reason that this should not work essentially the same in 
any other environment. AFAIK, the only possible differences, which would need 
to be addressed by adding options to the existing FuncTest code for this, are 
that e.g. a different approach to kicking off the FuncTest framework is needed 
due to differences in Jumphost OS or configuration. But OPNFV should not be 
responsible for accommodating platform implementations that vary in this way; 
the vendor should step up and implement the support so their product can be 
validated.

oThe rest of FuncTest is pretty generic and I see no reason why it should 
not be supportable.

-  Yardstick

oAs with FuncTest, the framework under which Yardstick operates may need 
some tweaks for compatibility with the vendor implementation. These tweaks need 
to be contributed to OPNFV by the vendor.

oThe C program may not initially include performance benchmarking, but 
any implementation should have demonstrated compatibility with the Yardstick 
test suite.

-  Other tests that we develop for Dovetail may go beyond FuncTest and 
Yardstick, to focus on more complex use cases or specific technical 

Re: [opnfv-tech-discuss] [Dovetail] Aug 5 Dovetail meeting notes

[SULLIVAN, BRYAN L]

Hi all,

I missed the last Dovetail meeting but from what I heard about some of the 
discussion, I'd like to seek clarification on some things that might have been 
expressed in the meeting, e.g. that implementations which will go thru C may 
not be expected to be compatible with existing OPNFV test suites, or at least 
that not all of the OPNFV test suites, e.g. FuncTest and Yardstick, would be 
expected to be tested on an certified implementations.

First I'd like to verify that such opinions were expressed (e.g. per Bin's 
comment that as a result "Dovetail testing and OPNFV tests are different"), and 
have them further explained if possible.

Second, given that the notes do capture the discussion and concerns correctly, 
here are some thoughts about that:

1)  The C committee is responsible for setting the "what is expected" out 
of a certification, within some flexibility within Doevtail as to what/how/when 
that can be delivered.

2)  Overall, it's expected that any implementation is compatible with the 
OPNFV test suites as test frameworks. The degree of compatibility with specific 
test may be limited e.g. if the target hardware/software function focused on by 
the tests is not supported by the implementation (e.g. an implementation that 
supports only a specific SDNC), but the significance of such N/As needs to be 
carefully considered by the C committee or Dovetail.

Overall we need to ensure that any aspect of certification can work equally 
(same end result) on an OPNFV-based implementation (meaning a collection of the 
core components as released in some OPNFV release, or even with slight 
variations e.g. different versions of the components), or another 
implementation. We should not leave tests out of the Dovetail scope just 
because they will "not work" on some implementations. There may be good reasons 
for them not to work (the N/As), but if those reasons are simply based upon the 
test design, the platform vendor should provide a compatible version of the 
tests based upon the OPNFV tests, so that we can still certify the platform 
functionally. Examples of this may be:

-  FuncTest

o   vIMS (Clearwater IMS) is based upon Orange's implementation of the Cloudify 
blueprint, using Cloudify as a VNFM. In the process, the Cloudify Manager is 
installed as a VM under OpenStack, and then executes the vIMS blueprint. I see 
no reason that this should not work essentially the same in any other 
environment. AFAIK, the only possible differences, which would need to be 
addressed by adding options to the existing FuncTest code for this, are that 
e.g. a different approach to kicking off the FuncTest framework is needed due 
to differences in Jumphost OS or configuration. But OPNFV should not be 
responsible for accommodating platform implementations that vary in this way; 
the vendor should step up and implement the support so their product can be 
validated.

o   The rest of FuncTest is pretty generic and I see no reason why it should 
not be supportable.

-  Yardstick

o   As with FuncTest, the framework under which Yardstick operates may need 
some tweaks for compatibility with the vendor implementation. These tweaks need 
to be contributed to OPNFV by the vendor.

o   The C program may not initially include performance benchmarking, but any 
implementation should have demonstrated compatibility with the Yardstick test 
suite.

-  Other tests that we develop for Dovetail may go beyond FuncTest and 
Yardstick, to focus on more complex use cases or specific technical 
capabilities. In principle I would expect that these would migrate into 
FuncTest and Yardstick however, over time, because if they are important they 
need to be part of the base test system. These might include tests for 
reference VNFs that we collect and run as blueprints under various VNFMs, e.g. 
thru the Models project. In those cases, if a vendor does not support one of 
the VNFMs for some reason (as with vIMS/Cloudily), then they need to contribute 
the support using their VNFM to OPNFV.

-  The rest of the Dovetail tests will be based upon existing upstream 
test suites including certification suites such as RefStack. We need to be 
proactively reaching out to these upstream teams, e.g. per 
https://etherpad.openstack.org/p/interop-challenge-meeting-2016-08-03.


Thanks,
Bryan Sullivan | AT

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Prakash 
Ramchandran
Sent: Friday, August 05, 2016 8:08 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Dovetail] Aug 5 Dovetail meeting notes

Here is today's OPNFV Dovetail meeting notes based on Gotomeeting and  
#opnfv-dovetail channels ...
Agenda:
1)start point(L3VPN, SFC and IPV6)
2)test cases structures
3) additional basic testcases( for SDN controller and NFVI...)
https://wiki.opnfv.org/pages/viewpage.action?pageId=6827269
4)other issues

Re: [opnfv-tech-discuss] [Orchestra] new project proposal

[Liu Yuan]

Hi Pasi,

I like your idea. It makes more clear.

Regards,
Yuan

Liu Yuan
liuyuan_c...@hotmail.com

From: Pasi Vaananen
Date: 2016-08-05 23:51
To: 'Bob Monkman'; 'Liu 
Yuan'; 'BIN'; 'Carella, 
Giuseppe'
CC: 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] [Orchestra] new project proposal
So, to make it clear, should we attempt to name the single upstream 
community/project specific projects based on their upstream name, like we have  
https://wiki.opnfv.org/display/PROJ/OPNFV-OPEN-O (and to some extent “ONOS 
Framework” and “OpenContral Virtual Networking for NFV”) this could be e.g. 
OPNFV-OpenBaton ?

Regards,

Pasi

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bob Monkman
Sent: Friday, August 05, 2016 11:00 AM
To: Liu Yuan; BIN; Carella, Giuseppe
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Orchestra] new project proposal

Yuan,
I can see your point. I think projects should avoid names that 
come to close to appearing to describe themselves as _the_ solution for some 
category of function, unless the project is an umbrella for multiple options. I 
am not judging that this was the intent with Orchestra, but one could argue 
such a name “grabs” the function for one option.

I think we made a mistake with Fast Data Stacks, but no one 
else seemed to question it. It comprises a single vendor solution for a broad 
function area that has innumerable options. I think teams should be sent back 
to the drawing board for a new name, as was asked of Open-O team.

One opinion,
Bob

Robert (Bob) Monkman
Enterprise Segment Marketing Manager
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Liu Yuan
Sent: Friday, August 05, 2016 10:25 AM
To: BIN; Carella, Giuseppe
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Orchestra] new project proposal

Hi,

I just recall the OPNFV OPEN-O project was named OPNFV-MANO at the beginning. 
And during the discussion, the team thought the scope were too broad, and 
needed focus or convergence. Then the project changed the name.

About the name of the Orchestra, I think have the similar situation. The 
meaning of Orchestra also includes broad scopes. So, I am wondering why there 
is a difference between these two projects.

Regards,
Yuan


Liu Yuan
liuyuan_c...@hotmail.com

From: liuyuan_c...@hotmail.com
Date: 2016-08-02 18:23
To: Carella, Giuseppe
CC: 
opnfv-tech-discuss@lists.opnfv.org; 
Michael Pauls
Subject: Re: Re: [opnfv-tech-discuss] [Orchestra] new project proposal
Hi Giuseppe,

I just think your project needs a unique name to represent the Open Baton, 
instead of a general name. Anyway, we can see others' suggestions on this. :)

Regards,
Yuan

Liu Yuan
liuyuan_c...@hotmail.com

From: Carella, Giuseppe
Date: 2016-08-02 18:00
To: Liu Yuan
CC: 
opnfv-tech-discuss@lists.opnfv.org; 
Michael Pauls
Subject: Re: [opnfv-tech-discuss] [Orchestra] new project proposal
Hi Yuan,

I get your point, however we are not aware of any guidelines for project names, 
therefore we believe this is the most appropriate name for this project. If 
this is a common issue, we can change the name. Consider that this is only a 
proposal...

We can discuss about it during the next conference call.

Cheers,
Giuseppe

Join us at the IEEE 5G Week in November in Berlin (http://www.berlin5gweek.org/)

On 02 Aug 2016, at 11:44, Liu Yuan 
> wrote:

Hi Giuseppe,

I am confused about the name of the project. Your main objective is to 
integrate between Open Baton and OPNFV. There are many MANO / Orcheatrator open 
source projects, and there is a MANO group in the OPNFV. I don't think you 
could use the "Orchestra" to only appoint to the Open Baton, maybe named Open 
Baton or OPNFV-Open Baton are more better.

Regards,
Yuan

Liu Yuan
liuyuan_c...@hotmail.com

From: Carella, Giuseppe
Date: 

[opnfv-tech-discuss] [ovsnfv] Weekly Open vSwitch for NFV meeting (8th August 2016)

[Gray, Mark D]

Here are the minutes from the last meeting.

http://ircbot.wl.linuxfoundation.org/meetings/opnfv-ovsnfv/2016/opnfv-ovsnfv.2016-08-08-14.02.html

Actions:
* Billy to suggest support format on tomorrows Release call [DONE]
* Mark to see if we can update scenarios to only support ha initially
* Billy to check to see what the impact of ha is on the dataplane [DONE]
* Billy - Attend fuel meeting to give update of plugin status [DONE]
* Billy - Sync with Ruijing on plugin [DONE]
* Tom will also figure this (documentation) out with Apex.

___
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-tech-discuss[QTIP]

[Yujun Zhang]

Hi, Sudha,

May I know which version you are using for the test? And what modification
you have done?

You may send a gerrit review to the
https://gerrit.opnfv.org/gerrit/#/admin/projects/qtip so we can have a
better idea on the issue you have encountered.

Best regards!
--
Yujun

On Mon, Aug 8, 2016 at 6:31 PM Kumari, Sudha (NFV BU) 
wrote:

> Hello Team,
>
>
>
> I am trying to set up QTIP on one of my NFV environment, where we are
> bringing up the stack using one of our solution. While going through the
> QTIP documentation, I understood that it is necessary to export any one of
> the OPNFV installers in order to run the tests. But since we are not using
> any of those OPNFV installers, can someone suggest me on how to set up QTIP
> without using installers/ or using custom installers.
>
>
>
> Right now I have made some customization in order to run
> “qtip/test_cases/default/compute/ramspeed_bm.yaml” scenario, below is the
> yml file.
>
> Scenario:
>
>   benchmark: ramspeed
>
>   host:
>
>   server: machine_1, machine_2
>
> Context:
>
>   Host_Machines:
>
> machine_1:
>
>   ip: 
>
>   pw: 
>
>   role: server
>
> machine_2:
>
>   ip: 
>
>   pw: 
>
>   role: server
>
> Scripts modified in order to make this work:
>
> · Modified qtip_creds.sh
>
> · Modified qtip/test_cases/default/compute/ramspeed_bm.yaml
>
> · Source opnfv-creds.sh
>
> · Ran, the test “python qtip.py -l default -f compute”. While
> doing the ssh test, the script throws error below,
>
>
>
> Traceback (most recent call last):
>
>   File "qtip.py", line 22, in 
>
> main()
>
>   File "qtip.py", line 15, in main
>
> cli()
>
>   File "/home/yardstick/qtip/func/cli.py", line 98, in __init__
>
> obj.call_ssh_test()
>
>   File "/home/yardstick/qtip/func/env_setup.py", line 176, in call_ssh_test
>
> self.ssh_test(self.ip_pw_list)
>
>   File "/home/yardstick/qtip/func/env_setup.py", line 72, in ssh_test
>
> ssh.connect(k, key_filename='./data/QtipKey')
>
>   File
> "/home/yardstick/qtip_venv/local/lib/python2.7/site-packages/paramiko/client.py",
> line 381, in connect
>
> look_for_keys, gss_auth, gss_kex, gss_deleg_creds, gss_host)
>
>   File
> "/home/yardstick/qtip_venv/local/lib/python2.7/site-packages/paramiko/client.py",
> line 604, in _auth
>
> raise saved_exception
>
> paramiko.ssh_exception.AuthenticationException: Authentication failed.
>
>
>
> I have check the servers are having the qtip key-pair. Any help here will
> be appreciated.
>
> Thanks,
>
>
> ___
> 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] [testperf] poll for APAC friendly time slot for weekly meeting

[Yujun Zhang]

Dear testers,

As an action of last weekly meeting, I have created a poll to select an
APAC friendly time slot.

http://doodle.com/poll/fa4nspdf4ta2u7pb

Please follow the link and vote for your opinion.

If agreed, we shall shift one meeting per month to the new hour.

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

Re: [opnfv-tech-discuss] [SDNVPN] Nominations for Committer promotion

[Jan Scheurich]

+1 from my side!

BR, Jan

From: Tim Irnich
Sent: Tuesday, 02 August, 2016 16:40
To: MORIN Thomas IMT/OLN (thomas.mo...@orange.com); Jan Scheurich; Prem sankar 
G; Diego Garcia del Rio (di...@nuagenetworks.net)
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN] Nominations for Committer promotion

Hi SDNVPN committers,

I would like to nominate the following SDNVPN contributors for promotion to 
committer:

Nikolas Hermanns (yes we already voted for this in January but I failed to 
execute the actual promotion at that time so I'd like to renew the vote)
Jose Lausuch

Both are undoubtedly core contributors to the project for already quite some 
time.

Please reply with +1 if you support this promotion.

Regards, Tim
___
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] Vote to make Trevor a submitter on releng.

[morgan.richomme]

+1

Le 27/07/2016 02:58, Meimei a écrit :
> +1
>
>
> 在 2016/7/22 5:42, Jose Lausuch 写道:
>> +1
>>
>> -Original Message-
>> From: Aric Gardner [mailto:agard...@linuxfoundation.org]
>> Sent: Thursday, July 21, 2016 20:05 PM
>> To: OPNFV Tech
>> Cc: Fatih Degirmenci; Jose Lausuch; Meimei; RICHOMME Morgan IMT/OLN;
>> Ryota Mibu; Tim Rozet
>> Subject: [opnfv-tech-discuss] [RELENG] Vote to make Trevor a
>> submitter on releng.
>>
>> Hi Releng committers,
>>
>> Please vote on making Trevor (tbramw...@linuxfoundation.org) a releng
>> committer.
>>
>> Here's my +1
>>
>> -Aric
>
>
>


-- 
Morgan Richomme
Orange/ IMT/ OLN/ CNC/ NCA/ SINA 

Network architect for innovative services
Future of the Network community member
Open source Orange community manager


tel. +33 (0) 296 072 106
mob. +33 (0) 637 753 326
morgan.richo...@orange.com


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [opnfv-tech-discuss] [NetReady] Resigning from committer role

[Georg Kunz]

Hi Ildiko,

Thanks a lot for your initiative to lay the foundation for this project and 
your help during its definition and creation! Of course this is a loss to the 
project but I suppose we will still meeting and chat at least during the 
summits, given your new position.

Thanks again.

Best regards
Georg


-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Ildiko Vancsa
Sent: Tuesday, August 02, 2016 1:52 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [NetReady] Resigning from committer role

Dear NetReady team,

Hereby I would like to inform you that I left Ericsson and starting from this 
week I’m working for the OpenStack Foundation.

Due to my new assignments I cannot fulfil the duties of a committer within this 
team, therefore please accept my resignation from the NetReady project.

I’m glad I could help and participate in creating this project and I wish the 
team all the best in the future.

I will try to still follow the activities within this project and also the 
Gluon activities within OpenStack as much as my time and bandwidth allows. Feel 
free to contact me with any OpenStack related questions or topics that you 
might have in the future.

Thanks and Best Regards,
Ildikó
e-mail: ild...@openstack.org
IRC: ildikov
___
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