[opnfv-tech-discuss] [VSPERF] topology description scheme

[Tahhan, Maryam]

Hi folks
I've been thinking about this and I think I have a possible suggestion



Lettering:

It's case sensitive



L - Local

R - Remote

S - vSwitch

P- Physical NIC

V - Virtual NIC

pp - patch port

O - Overlay port - not sure if we need...



Numbering:
Numeric values can follow any of the last S, V, and P or nothing follows them 
which implies a 1.

For ports it implies the number of ports V2 is two virtual ports connected in 
succession.

For switches it actually acts as an Identifier LS2 is local switch 2.





The scheme is really to describe the flows from port to port through the vswitch



so

Current scheme


Proposed scheme


Phy2phy


LS_P2


PVP


LS_PVP


PVVP


LS_PV2P


Multiple VMs in series


LS_PVxP where X is the number


Multiple VMs in Parallel


LS_PVP_x (where X is a number applies to everything surrounded by underscores)


2 local switches doing phy2phy


LS1_P2_LS2_P2


2 local switches patched together


LS1_Ppp_LS2_P


Overlayed -switches on a local and a remote


LS_PO_RS_OP


Overlayed - local switched


LS1_PO_LS2_OP








Not as simple as I would have hoped, but open to any suggestions



BR
Marayam


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

Re: [opnfv-tech-discuss] Evolution of OPNFV mailing lists

[Raymond Paik]

Yunhong,

Sorry for the delay.  Please see my comments below

Thanks,

Ray

On Tue, Aug 30, 2016 at 5:22 PM, yunhong jiang <
yunhong.ji...@linux.intel.com> wrote:

> On Mon, 29 Aug 2016 09:41:46 -0700
> Raymond Paik  wrote:
>
> > All,
> >
> > One of the topics discussed at the Q3 Hackfest last week was OPNFV
> > mailing lists.  After ~2 years, I think most will agree that the
> > opnfv-tech-discuss mailing list in particular has become difficult to
> > digest.
> >
> > The consensus among attendees last week was to keep
>
> Such discussion has happened on almost each open source project, and
> different project has diffrent conclusion.
>
> I'm not on the Hackfest and no idea of the exact meaning of "difficult
> to digest". If you can provide more information of the "difficulty" of
> the digest, it will be really good.
>
> Below is just my input. I'm against the spliting as:
>
> a) I think it's easy to filter the mail based on the subject. And till
> now, I think the mailing list is quite well on the tag, of course we
> can always do better on it.
>
> b) Keep all topic on the same mailing list make it easier to have a
> quick look on the topic on the project. OPNFV includes a bunch of
> projects and they are related to each other quite tightly. For example,
> test projects are sure to be related to the test bed, i.e. the Pharos
> project, which I think is part of the opnfv-infra.
>
> =>  Comments I heard from many community members is that even with tags,
the tech-discuss mailing lists has become difficult to manage.  Or with 40+
tags, tags themselves are not very useful or usable...

> More inputs below.
>
> > opnfv-tech-discuss for general and project-related discussions (using
> > tags), but it'd make sense to create additional mailing lists for
> > other discussions.  Below is the proposal that the attendees came up
> > with and wanted to share this with the rest of the community for
> > feedback and further discussions.
>
> >
> >
> >- Mailing list for Release discussions (e.g. opnfv-release)
>
> I'm not sure if we really need the release discussion mailing list. Per
> my understanding and experience, the projects have more interactive
> during the release time, and need more collaboration. Also every
> projects would participate on the release discussion, why don't we do
> that on the tech-discuss mailing list, which should involve everyone
> already?
>
> But if you are talking about the discussion of stable release (like
> B-release, or C-release after the C release date), I agree it make
> sense.
>
> >- Mailing lists for OPNFV working groups: create separate lists
> > for Test (opnfv-test-wg), Infra (opnfv-infra-wg), and MANO
> > (opnfv-mano-wg) working groups
>
> As stated above, these work groups have very tight relationship.
>
> >- Create new mailing lists for upstream discussions with OpenStack
> >(opnfv-openstack) and OpenDaylight (opnfv-odl) communities
>
> Most of the OPNFV projects have corresponding upstream project. Will we
> create upstream discussion list for each one?  And also what's
> the benefit of this upstream mailing list? Is it to involve the upstream
> community? If yes, I doubt if it will have any help. After all, the
> involvement from upstream community depends more on our impact to
> them :)
>

=> Actually got requests from upstream community members (e.g. from
OpenStack, ODL, etc.) that they would like an open mailing list that they
can participate in without having to subscribe to it...

>
> Thanks
> --jyh
>
> >   - This will have the same set up as the mailing list already
> > created for fd.io (fds-...@lists.opnfv.org)
> >
> > Please jump in with your thoughts or other suggestions.  We can have
> > email discussions this week and try to come to a consensus during the
> > TSC call next week (September 6th).
> >
> > 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] Infra Working Group Weekly Meeting

[Daniel Smith]

Hello Jack et al

I have an offsite meeting tomorrow at 1pm and have to travel there in advance 
so I wont be able to make the call.

>From my side (INFRA):
-   I have 3 slides almost ready (should post by end of the week) on 
possible approaches to having multi-scenario (thus multi-installer) PODs that I 
will put up for comment.
o   Jose has recently added and outlined EPICs for the Dashboard and 
Booking Tool.  I would really like to incorporate these into the overall 
messaging system that will come about between sites and will call for a meeting 
with  Max, Jose and others in the coming weeks.

-   The naming issue that Frank brought up today is something that we 
touched on leading up to B release and then ran out of time.  From the meeting 
the community has seen there is a need to create a better naming schema for the 
"at a glance list" or to come up with agree upon nomenclature for terms used - 
i.e HA means Openstack HA from a controller standpoint? From a Component Level 
standpoint? From a Storage/Network/Compute standpoint (as Prakash outlined).
-
o   My take on it is that people shouldn't really use a simple label in 
Jenkins to derive what a scenario contains.   If we are trying to make a 
labelling that will represent all the state of components in a given scenario I 
feel our labels will get rather large or need a legend/index to decipher them.  
   We should have a note that simply says that and if you want details on what 
is HA / not in a given scenario, then sole place for that is the description 
and not to infer anything from a label (which is an operation construct anyway, 
not a release deliverable).

Lastly, please note that Ericsson lab Migration starts next Monday and all 
projects will be off the current site by the end of the month. Including CI/CD.


Best Regards,

-Original Appointment-
From: Morgan, Jack [mailto:jack.mor...@intel.com]
Sent: Tuesday, August 09, 2016 7:03 PM
To: Morgan, Jack; 'opnfv-tech-discuss@lists.opnfv.org'
Subject: [opnfv-tech-discuss] Infra Working Group Weekly Meeting
When: Wednesday, September 07, 2016 8:00 AM-9:00 AM (UTC-08:00) Pacific Time 
(US & Canada).
Where: #opnfv-meeting and GTM



The "Infra Working Group" plans and tracks infrastructure cross project 
initiatives and reports these up to the TSC to ensure we are able to provide 
sufficient resources and support for development and release infrastructure.

Wiki Page for topics and meeting agendas at 
https://wiki.opnfv.org/display/INF/Infra+Working+Group

Weekly on Wednesday at 
15:00 
UTC (8am PST)
GTM Link https://global.gotomeeting.com/join/773318405
Minutes at 
Meetings#InfraWorkingGroupMeeting
IRC #opnfv-meeting - freenode.net
Chaired by Jack Morgan
You can also dial in using your phone with Access Code: 773-318-405
United States +1 (224) 501-3312
Australia (Long distance): +61 2 8355 1039
Austria (Long distance): +43 7 2088 1033
Belgium (Long distance): +32 (0) 28 93 7001
Canada (Long distance): +1 (647) 497-9379
Denmark (Long distance): +45 69 91 89 33
Finland (Long distance): +358 (0) 942 41 5770
France (Long distance): +33 (0) 170 950 585
Germany (Long distance): +49 (0) 692 5736 7205
Ireland (Long distance): +353 (0) 19 030 050
Italy (Long distance): +39 0 693 38 75 50
Netherlands (Long distance): +31 (0) 208 080 208
New Zealand (Long distance): +64 9 925 0481
Norway (Long distance): +47 21 54 82 21
Spain (Long distance): +34 911 82 9890
Sweden (Long distance): +46 (0) 853 527 817
Switzerland (Long distance): +41 (0) 435 0167 65
United Kingdom (Long distance): +44 (0) 330 221 0099



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

[opnfv-tech-discuss] 2017 OPNFV Summit website, registration & sponsorship details live

[Jill Lovato]

Hello OPNFV Tech Community,

Heads-up that we've officially launched details for the 2017 OPNFV Summit
taking place June 12-15 in Beijing. A media advisory

went
live this morning, along with the Summit website
 which includes
the registration
page

 and sponsorship details
.

Please help spread the word and promote the live links via your social
media channels; sample copy and easy click-to-tweet content is below.

As always, let us know if there are any questions.

Thank you!

+

NEWS: Open Source NFV Project to Host 2017 Summit in Beijing
http://bit.ly/2bIEvUd #OPNFV

Click-to-tweet: http://ctt.ec/w9hWV

.@OPNFV announces 2017 #OPNFVSummit in Beijing, sponsorship opportunities &
registration now open: http://bit.ly/2bIEvUd
Click-to-tweet: http://ctt.ec/dxtU 

-- 
*Jill Lovato*
PR Manager
The Linux Foundation
jlov...@linuxfoundation.org
Skype: jill.lovato1
Phone: +1.503.703.8268
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Parser]Verigraph Presentation slide

[Zhipeng Huang]

Hi Ulas,

As far as I understand, verigraph currently focus on the orchestration
layer of ESCAPE  which
is mainly a service funcation chaining engine. For verigraph's integration
with Parser, we do need certain modifications so that verigraph could
better suited for the tosca template we are focusing now.

How this modification will happen need to be further discussed with
verigraph subteam later on, I could not mandate a direction for the moment
: )

BTW in parser's project scope definition, there is no restriction or
limitation on the template format we use.

On Tue, Sep 6, 2016 at 11:30 AM, Ulas Kozat  wrote:

> Zhipeng,
>
>
>
> This looks quite interesting indeed. From the slides you forwarded though
> my understanding is that the level of VNF model being verified in Verigraph
> is much richer than what is prescribed in a Tosca template. Does this mean
> that Parser is moving away from Tosca based service models? Or is the
> intent to somehow translate high level Tosca VNFDs and NSDs into
> intermediate forms that Verigraph can accept as input and verify?
>
>
>
> Thanks,
>
>
>
> Ulas
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Zhipeng Huang
> *Sent:* Monday, September 05, 2016 3:48 AM
> *To:* opnfv-tech-discuss@lists.opnfv.org
> *Cc:* Guido Marchetto; Riccardo Sisto; Serena Spinoso
> *Subject:* [opnfv-tech-discuss] [Parser]Verigraph Presentation slide
>
>
>
> ​​Hi Team,
>
>
>
> On today's weekly meeting, Riccardo and his team gave a great presentation
> on a project "Verigraph" they have been working on. Personally I think it
> would be a very interesting and great feature for Parser to have in the
> next release. With Verigraph Parser might be able to check semantic
> validity and also provide "on-the-fly" verification of the templates before
> deployment.
>
>
>
> Please see the slide in the attachment, and feel free to comment.
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
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-tsc] harmonized configuration set for OPNFV

[Yujun Zhang]

I agree. We should track this issue in JIRA. Which project shall we put it
in? Pharos?

Besides the configuration harmonization, we have also spotted some
performance deviation between environments deployed by different installers.

Theoretically , a consistent environment should be targeted no matter which
installer user has chosen.
--
Yujun

On Tue, Sep 6, 2016 at 11:52 PM SULLIVAN, BRYAN L  wrote:

> I’d suggest a Jira issue be created that we can add details to. I agree
> that this will be a very helpful effort. Right now there is substantial
> variation in the deployed platform e.g. even to such things as:
>
> -  Number and names of networks, routers, etc created by default
>
> -  Default images created in glance
>
> -  Names of projects (e.g. “services” vs “service”)
>
> -  …
>
>
>
> These variations add complexity to install and test scripts for features.
> As we eliminate the variations, we do need a process to identify and
> address  impact to existing code and tests.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Jack Morgan
> *Sent:* Tuesday, September 06, 2016 8:41 AM
> *To:* TSC OPNFV
> *Cc:* TECH-DISCUSS OPNFV
> *Subject:* Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV
>
>
>
> Yujun,
>
> Thanks for raising this issue. This is a longer term issue to solve but
> for now I've added it as a topic for to the Infra WG weekly meeting. I'm
> hoping to solve this for the D release and been tasked by the TSC to help
> drive this effort. Please join the Infra WG meeting to provide your input.
>
>
>
> On 09/05/2016 12:11 AM, Yujun Zhang wrote:
>
> Dear TSC,
>
>
>
> We have encountered some issues on the openstack environment configuration
> for some projects and it could not be resolved within the project scope. So
> I have to escalate it to TSC to look for a solution.
>
>
>
> Some OPNFV project requires *dedicated* configuration on *common*
> services. But the environment deployed by the installers may not always
> come with a valid configuration.
>
>
>
> For example, doctor project requires `notifier://?topic=alarm.all` in
> ceilometer event pipeline configuration. But the default deployed
> environment by fuel does not include this configuration. There has been a
> long debates between the two teams on where the modification should be made
> [1][2]. The contradiction is that if we enable this notifier topic, doctor
> will work, but nobody can guarantee that other projects are not affected.
>
>
>
> OPNFV is targeting to deliver a "de facto standard open source NFV
> platform for the industry" [3]. The platform on software part includes
> not only the services installed but also a common configuration for all
> projects to run.
>
>
>
> So the first step should be working out a *harmonized configuration** set*
> which will allow all existing projects to run normally. Then it can be used
> to validate the deployed environment from each installer.
>
>
>
> I'm sincerely hoping TSC can help to resolve this issue and lead OPNFV to
> a success.
>
>
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/18285/
>
> [2] https://jira.opnfv.org/browse/FUEL-159
>
> [3] https://wiki.opnfv.org/
>
>
>
> --
>
> Yujun Zhang
>
>
>
>
> ___
>
> opnfv-tech-discuss mailing list
>
> opnfv-tech-discuss@lists.opnfv.org
>
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
> --
>
> Jack Morgan
>
> OPNFV Pharos Intel Lab
>
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Apex] puppet logging for debug

[Peng Liu]

Hi Tim,

Thanks for your answer.

I also find the debug logs in /run/heat-confg/deployed on the nodes is very
helpful for debugging the puppet issue.

BRs,

On Wed, Sep 7, 2016 at 12:54 AM, Tim Rozet  wrote:

> Hi Peng,
> On the jump host you can do opnfv-util debug-stack.  That will print out
> the reason for heat stack failure, including puppet errors.  If that
> doesn't give you enough information, then look at each /var/log/messages on
> the nodes themselves.  That will contain all the puppet and other
> configuration calls.
>
> Thanks,
>
> Tim Rozet
> Red Hat SDN Team
>
> - Original Message -
> From: "Peng Liu" 
> To: opnfv-tech-discuss@lists.opnfv.org
> Sent: Monday, September 5, 2016 11:18:22 AM
> Subject: [opnfv-tech-discuss]  [Apex] puppet logging for debug
>
> Hi Team,
>
> How can I get the puppet log of overcloud deployment? I made some change
> in dpdk_dataplanes.pp to make ovs-dpdk work, thenI got error when run
> 'openstack overcloud deploy'.
>
> I try to add '-e 
> /usr/share/openstack-tripleo-heat-templates/environments/config-debug.yaml'
> to enable logging for puppet. But I cannot see the folder
> /var/run/heat-config/deployed.
>
>
> Thanks,
> --
> Peng Liu | Senior Software Engineer
>
> Tel: + 86 10 62608046 (direct)
> Mobile: +86 13801193245
>
> Red Hat Software (Beijing) Co., Ltd.
> 9/F, North Tower C,
> Raycom Infotech Park,
> No.2 Kexueyuan Nanlu, Haidian District,
> Beijing, China, POC 100190
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>



-- 
Peng Liu | Senior Software Engineer

Tel: +86 10 62608046 (direct)
Mobile: +86 13801193245

Red Hat Software (Beijing) Co., Ltd.
9/F, North Tower C,
Raycom Infotech Park,
No.2 Kexueyuan Nanlu, Haidian District,
Beijing, China, POC 100190
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Adi Molkho]

Hi
Is there any final conclusion to this mail thread ? Are the documents of the 
requirement project going to be part of the C release?

Thanks
Adi



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Sofia Wallin
Sent: Wednesday, August 31, 2016 1:42 PM
To: Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; Christopher Price
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi everyone,
I haven’t been involved in the discussion whether we want the requirement 
projects to be a part of our releases or not.
But when it comes to documentation it is obvious that people see a need to 
include this kind of work as well.
I agree with Chris, “to publish a “future work” section of our release library 
that describes more where our community is heading”.

I talked to Daniel yesterday and we think that it would be fine to handle this 
in the same way as the release documentation. We create an introduction 
document explaining what this is about and link to the projects documentation.


But let’s discuss this (and hopefully agree),
I will add this as topic for the docs meeting this afternoon, so people 
concerned are welcome to call in.

BR,
Sofia

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kunzmann, 
Gerald
Sent: den 31 augusti 2016 09:51
To: Georg Kunz; Daniel Smith; David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi David, all,

My 2 cent on your question:

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

Best regards,
Gerald

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith >; 
David McBride 
>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi Daniel, hi all,

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:


-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV


I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section such as “requirements projects”. This could 
be a simple link – just as we have it right now on our project wiki.

As David pointed out, there is some overhead involved for the project, but I 
believe the benefits outweigh the overhead.

Looking forward to discussing with you in today’s docs meeting.

Best regards
Georg

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Daniel Smith
Sent: Tuesday, August 30, 2016 11:44 PM
To: David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hey All.

I spoke with Sofia as well about this and presented our NetReady situation. We 
have a document that covers what we wanted to cover for Phase 1 (targeting C 
release) of the NetReady Requirements Project.   We now want to stop internally 
editing it and release it for comment – and the thinking is that, since we have 
built the document in gerrit and based on DOCS formatting guidelines, was the 
vehicle to provide the following in terms of the work that the team did:


-Allow for the completion and publishing of the 

Re: [opnfv-tech-discuss] [dovetail]issures and suggestion: to upload the dovetail codes to the git/gerrit

[Dave Neary]

Hi Hongbo,

Since Dovetail is not participating in the C release, we should not have
a C release branch, I think - I would suggest that we work in master only.

I do not understand why we would need to be on a C branch to run our
test suite against a C release branch.

Thanks,
Dave.

On 09/05/2016 11:46 PM, Tianhongbo wrote:
> Hi Bin:
> 
>  
> 
> thanks.
> 
>  
> 
> Yes, we  need the help from Aric.
> 
>  
> 
> Also, we need the suggestion from Aric.
> 
>  
> 
> Best Regards
> 
>  
> 
> hongbo
> 
>  
> 
> *From:*HU, BIN [mailto:bh5...@att.com]
> *Sent:* 2016年9月6日11:44
> *To:* Tianhongbo; 'TECH-DISCUSS OPNFV'
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]issures and suggestion: to
> upload the dovetail codes to the git/gerrit
> 
>  
> 
> I think you need to work with Aric to create stable/colorado branch.
> 
>  
> 
> Then cherrypick those C Release stuff from master to stable/colorado.
> 
>  
> 
> Bin
> 
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org
> 
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of
> *Tianhongbo
> *Sent:* Monday, September 05, 2016 8:37 PM
> *To:* 'TECH-DISCUSS OPNFV'  >
> *Subject:* [opnfv-tech-discuss] [dovetail]issures and suggestion: to
> upload the dovetail codes to the git/gerrit
> 
>  
> 
> Hi dovetailers:
> 
>  
> 
> Now, we are trying to upload the documents and scripts to the dovetail
> repos.
> 
> But , there are at least two branches: master and C release. The master
> branch will be used for the D release.
> 
> The goal of the dovetail is to test against the C release now and to
> test against the D release in future. The problem comes: where can we
> put the documents and scripts?
> 
> There will be no problem with the documents. But there will be the
> issues with the scripts.
> 
> If we merge the script in the master, we cannot use the scripts to test
> the C release.
> 
> If we merge the scripts in the C release branch, we cannot use the
> scripts for the D release.
> 
> Meanwhile, the C release branch was frozen, we cannot edit the scripts
> in the C release branch now.
> 
>  
> 
> Objection for the dovetail scripts:
> 
> 1.   The codes will be used in future（next will be used for D release）
> 
> 2.   The first version of dovetail is used to test C release
> 
>  
> 
>  
> 
> Do you have any idea to handle these problem?
> 
>  
> 
> I have a suggestion:
> 
>  
> 
> When we commit the patches to the master, we can try our best to merge
> in the master branch. These will be used for the future release.
> 
> Meanwhile, cherry pick the patches to the C release. If the C release
> was frozen, cherry pick the patches to the dovetail branch.
> 
>  
> 
>  
> 
>  
> 
> Any comments are welcome.
> 
>  
> 
> Best regards
> 
>  
> 
> hongbo
> 
> 
> 
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV

[Jack Morgan]

  
  
Yujun,
Thanks for raising this issue. This is a longer term issue to
solve but for now I've added it as a topic for to the Infra WG
weekly meeting. I'm hoping to solve this for the D release and
been tasked by the TSC to help drive this effort. Please join
the Infra WG meeting to provide your input.


On 09/05/2016 12:11 AM, Yujun Zhang
  wrote:


  
  Dear TSC,

  We have encountered some issues on the openstack
environment configuration for some projects and it could not
be resolved within the project scope. So I have to escalate
it to TSC to look for a solution.


  
Some OPNFV project requires dedicated
configuration on common services. But the environment
deployed by the installers may not always come with a valid
configuration.



For example, doctor project requires
  `notifier://?topic=alarm.all` in ceilometer event pipeline
  configuration. But the default deployed environment by fuel
  does not include this configuration. There has been a long
  debates between the two teams on where the modification should
  be made [1][2]. The
contradiction is that if we enable this notifier topic,
doctor will work, but nobody can guarantee that other
projects are not affected.


OPNFV is targeting to deliver
a "de facto standard open source NFV platform for the
industry" [3]. The
platform on software part includes not only the services
installed but also a common configuration for all projects
to run.

  
So
the first step should be working out a harmonized
  configuration set
which will allow all existing projects to run normally. Then
it can be used to validate the deployed environment from
each installer.

  
I'm
sincerely hoping TSC can help to resolve this issue and lead
OPNFV to a success.

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

  [2] https://jira.opnfv.org/browse/FUEL-159
  [3] https://wiki.opnfv.org/
  
  
  --
  Yujun Zhang

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



-- 
Jack Morgan
OPNFV Pharos Intel Lab
  

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

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

[Frank Brockners (fbrockne)]

Hi Ray,

thanks for posting the initial cut. IMHO a "composite score", as proposed on 
the page, could be *very* misleading, especially for projects which do most of 
the work upstream. So unless we track all upstream repos and upstream Jiras (or 
similar), I would suggest to *not* compute a composite score but evaluate 
things qualitatively only.

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Montag, 29. August 2016 19:33
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Following up on Project Health metrics discussion

All,

I had an action item from last week to start a wiki page for the "project 
health metrics".  You can find a proposal page at 
https://wiki.opnfv.org/display/PROJ/Project+Health+Metrics.

Please add your comments/feedback via email or directly on the wiki page.  I 
listed four activity areas that was discussed on the TSC call, but feel free to 
add other activities that the community should consider.

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 #28648] AutoReply: [qtip] Nomination of Committer promotion for jiang.zhif...@zte.com.cn

[Aric Gardner via RT]

Hi,

I have sent jiang.zhif...@zte.com.cn an invite to join the qtip
submitters group.
In the future please do all of the voting on the same channel (Ie
gerrit or email) as this is easier to keep track of and refer to.

Regards,
Aric


On Tue, Sep 6, 2016 at 9:32 AM, zhangyujun+...@gmail.com via RT
 wrote:
>
> https://rt.linuxfoundation.org/Ticket/Display.html?id=28648 >
>
> How is it going?
>
> On Mon, Aug 29, 2016 at 1:53 PM OPNFV Helpdesk via RT <
> opnfv-helpd...@rt.linuxfoundation.org> wrote:
>
>>
>> Greetings,
>>
>> Your support ticket regarding:
>> "[qtip] Nomination of Committer promotion for
>> jiang.zhif...@zte.com.cn",
>> 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 #28648]
>>
>> in the subject line of subsequent emails.
>>
>> Thank you,
>> Linux Foundation Support Team
>>
>> -
>> I would like to inform TSC that Zhifeng Jiang has been added as a committer
>> to qtip project.
>>
>> Voted by Email
>>
>> +1 Morgan  Richommemorgan.richo...@orange.com
>> +1 Nauman  Ahadnauman.a...@xflowresearch.com
>> +1 Prabu   Kuppuswamy  prabu.kuppusw...@spirent.com
>> +1 Prakash Ramchandran prakash.ramchand...@huawei.com
>>
>> Voted in Gerrit [1][2]
>>
>> +1 Wenjing Chu chu.wenj...@gmail.com
>> +1 Yujun   Zhang   zhang.yuj...@zte.com.cn
>>
>> No response yet
>>
>> Michael Haugh   mha...@ixiacom.com
>> Trevor  Cooper  trevor.coo...@intel.com
>>
>> [1] https://gerrit.opnfv.org/gerrit/#/c/19141/
>> [2] https://gerrit.opnfv.org/gerrit/#/c/19703/
>>
>> Nominating Zhifeng Jiang  as new committer for
>> QTIP project. Zhifeng has been contributed a majority of code to QTIP since
>> last season[1][2]. I believe she will help QTIP project to make a success
>> in next release. All qtip committers, please vote +1 or +2 if you support
>> this nomination [3]. This patch reopens #19141 [4]. Please DO NOT merge
>> until we get a majority. [1]
>>
>> http://stackalytics.com/?project_type=opnfv-group=commits=qtip
>> [2]
>> https://git.opnfv.org/cgit/qtip/log/?qt=author=jiang.zhifeng%40zte.com.cn
>> [3] https://wiki.opnfv.org/display/DEV/Committer+Promotions [4]
>> https://gerrit.opnfv.org/gerrit/#/c/19141/
>>
>>
>> On Mon, Aug 29, 2016 at 1:25 PM Kuppuswamy, Prabu <
>> prabu.kuppusw...@spirent.com> wrote:
>>
>> > +1
>> >
>> >
>> >
>> > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
>> > *Sent:* Monday, August 29, 2016 7:55 AM
>> > *To:* Kuppuswamy, Prabu ; Prakash
>> > Ramchandran ; Cooper, Trevor <
>> > trevor.coo...@intel.com>; iben.rodrig...@vmsec.com
>> > *Cc:* TECH-DISCUSS OPNFV 
>> >
>> >
>> > *Subject:* Re: [qtip] nominating Zhifeng Jiang as committer
>> >
>> >
>> >
>> > A reminder for committers who haven't vote yet.
>> >
>> >
>> >
>> > Please either reply to this thread or vote on gerrit [1]
>> >
>> >
>> >
>> > Thank you for your supporting to qtip project.
>> >
>> >
>> >
>> > [1] https://gerrit.opnfv.org/gerrit/#/c/19703/
>> >
>> >
>> >
>> > On Mon, Aug 22, 2016 at 11:47 AM Yujun Zhang 
>> > wrote:
>> >
>> > Dear Qtip committers,
>> >
>> >
>> >
>> > I'd like to nominate Zhifeng Jiang  as new
>> > committer for QTIP project.
>> >
>> >
>> >
>> > Zhifeng has been contributed a majority of code to QTIP since last
>> > season[1]. I believe she will help QTIP project to make a success in next
>> > release.
>> >
>> >
>> >
>> > Please vote +2 in https://gerrit.opnfv.org/gerrit/#/c/19141/ if you
>> agree.
>> >
>> >
>> >
>> > [1]
>> >
>> http://stackalytics.com/?project_type=opnfv-group=commits=qtip
>> >
>> >
>> >
>> > [image: image001.png]
>> >
>> >
>> >
>> > --
>> >
>> > Yujun
>> >
>> >
>> >
>> >
>> >
>> > Spirent Communications e-mail confidentiality.
>> > 
>> > This e-mail contains confidential and / or privileged information
>> > belonging to Spirent Communications plc, its affiliates and / or
>> > subsidiaries. If you are not the intended recipient, you are hereby
>> > notified that any disclosure, copying, distribution and / or the taking
>> of
>> > any action based upon reliance on the contents of this transmission is
>> > strictly forbidden. If you have received this message in error please
>> > notify the sender by return e-mail and delete it from your system.
>> >
>> > Spirent Communications plc
>> > Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
>> > Kingdom.
>> > Tel No. +44 (0) 1293 767676
>> > Fax No. +44 (0) 1293 767677
>> >
>> > Registered in England Number 470893
>> > Registered at Northwood Park, Gatwick Road, Crawley, West 

Re: [opnfv-tech-discuss] [VSPERF] topology description scheme

[Klozik, MartinX]

Hi Maryam,

Thanks for initial proposal. It looks good overall. It seems, we are going to 
define a grammar of a small language. In that case it might be useful to define 
it well for both human and machine processing. Just for case, we would like to 
create a class, which will be able to prepare a setup automatically based on 
the scheme name.

In that case, we should consider:

1)  Possible ambiguity in number meaning; May be, we should consider a 
standalone number as an index and number prefixed with x as multiplication 
factor, e.g. LS1 vs. PVx3P

2)  In your proposal is V a synonym for VM with 2 NICs; We should consider 
a possibility of VMs with different NIC number, i.e. to really use V as a 
Virtual NIC, e.g. PVVP in meaning of phy_nic->virt_nic->virt_nic->phy_nic. 
However I can't figure out an intuitive but still flexible way to describe 
complex scenarios, e.g. 1VM with 4NICs in parallel or even 2 VMs in series, 
where 1st VM has 2NICs, but 2nd 4NICs in parallel...

Best Regards,
Martin

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
Sent: Tuesday, September 06, 2016 11:21 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [VSPERF] topology description scheme


Hi folks
I've been thinking about this and I think I have a possible suggestion



Lettering:

It's case sensitive



L - Local

R - Remote

S - vSwitch

P- Physical NIC

V - Virtual NIC

pp - patch port

O - Overlay port - not sure if we need...



Numbering:
Numeric values can follow any of the last S, V, and P or nothing follows them 
which implies a 1.

For ports it implies the number of ports V2 is two virtual ports connected in 
succession.

For switches it actually acts as an Identifier LS2 is local switch 2.





The scheme is really to describe the flows from port to port through the vswitch



so

Current scheme


Proposed scheme


Phy2phy


LS_P2


PVP


LS_PVP


PVVP


LS_PV2P


Multiple VMs in series


LS_PVxP where X is the number


Multiple VMs in Parallel


LS_PVP_x (where X is a number applies to everything surrounded by underscores)


2 local switches doing phy2phy


LS1_P2_LS2_P2


2 local switches patched together


LS1_Ppp_LS2_P


Overlayed -switches on a local and a remote


LS_PO_RS_OP


Overlayed - local switched


LS1_PO_LS2_OP








Not as simple as I would have hoped, but open to any suggestions



BR
Marayam


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [netready] NetReady weekly project meeting

[Laporte, Laurent [CTO]]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Laporte, Laurent [CTO]":MAILTO:laurent.lapo...@sprint.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:\n\n\n\nThis e-m
 ail may contain Sprint proprietary information intended for the sole use o
 f the recipient(s). Any use by others is prohibited. If you are not the in
 tended recipient\, please contact the sender and delete all copies of the 
 message.\n
RRULE:FREQ=WEEKLY;UNTIL=20161230T17Z;INTERVAL=1;BYDAY=TU;WKST=MO
SUMMARY;LANGUAGE=en-US:[netready] NetReady weekly project meeting
DTSTART;TZID=Europe/Berlin:20160405T18
DTEND;TZID=Europe/Berlin:20160405T19
UID:04008200E00074C5B7101A82E008406315ABB78ED101000
 010005322883390AEBF41B8068FC683FB97A6
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160906T155819Z
TRANSP:TRANSPARENT
STATUS:CONFIRMED
SEQUENCE:1
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV

[SULLIVAN, BRYAN L]

I’d suggest a Jira issue be created that we can add details to. I agree that 
this will be a very helpful effort. Right now there is substantial variation in 
the deployed platform e.g. even to such things as:

-  Number and names of networks, routers, etc created by default

-  Default images created in glance

-  Names of projects (e.g. “services” vs “service”)

-  …

These variations add complexity to install and test scripts for features. As we 
eliminate the variations, we do need a process to identify and address  impact 
to existing code and tests.

Thanks,
Bryan Sullivan | AT

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan
Sent: Tuesday, September 06, 2016 8:41 AM
To: TSC OPNFV
Cc: TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV


Yujun,

Thanks for raising this issue. This is a longer term issue to solve but for now 
I've added it as a topic for to the Infra WG weekly meeting. I'm hoping to 
solve this for the D release and been tasked by the TSC to help drive this 
effort. Please join the Infra WG meeting to provide your input.

On 09/05/2016 12:11 AM, Yujun Zhang wrote:
Dear TSC,

We have encountered some issues on the openstack environment configuration for 
some projects and it could not be resolved within the project scope. So I have 
to escalate it to TSC to look for a solution.

Some OPNFV project requires dedicated configuration on common services. But the 
environment deployed by the installers may not always come with a valid 
configuration.

For example, doctor project requires `notifier://?topic=alarm.all` in 
ceilometer event pipeline configuration. But the default deployed environment 
by fuel does not include this configuration. There has been a long debates 
between the two teams on where the modification should be made [1][2]. The 
contradiction is that if we enable this notifier topic, doctor will work, but 
nobody can guarantee that other projects are not affected.

OPNFV is targeting to deliver a "de facto standard open source NFV platform for 
the industry" [3]. The platform on software part includes not only the services 
installed but also a common configuration for all projects to run.

So the first step should be working out a harmonized configuration set which 
will allow all existing projects to run normally. Then it can be used to 
validate the deployed environment from each installer.

I'm sincerely hoping TSC can help to resolve this issue and lead OPNFV to a 
success.

[1] https://gerrit.opnfv.org/gerrit/#/c/18285/
[2] https://jira.opnfv.org/browse/FUEL-159
[3] https://wiki.opnfv.org/

--
Yujun Zhang




___

opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org

https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss



--

Jack Morgan

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

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Georg Kunz]

Hi Adi,

We had a discussion on this in the docs meeting last week and to my 
understanding we came to the agreement that the requirement docs should be 
included. The exact location and the naming still needs to be decided upon. For 
instance, it should be clear for users of the release that the requirement docs 
do NOT describe features which are available in the release. One proposal is to 
add a section to the documentation library called “Requirement Analyses” (my 
favorite) or “Future Work” (indicating that the requirements identified by the 
requirement docs will hopefully be addressed in future releases.

I hope we can conclude on the details soon, either here on the list or in 
tomorrow’s docs meeting.

Georg

From: Adi Molkho [mailto:adi.mol...@huawei.com]
Sent: Tuesday, September 06, 2016 3:40 PM
To: Sofia Wallin; Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; 
Christopher Price
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi
Is there any final conclusion to this mail thread ? Are the documents of the 
requirement project going to be part of the C release?

Thanks
Adi



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Sofia Wallin
Sent: Wednesday, August 31, 2016 1:42 PM
To: Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; Christopher Price
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi everyone,
I haven’t been involved in the discussion whether we want the requirement 
projects to be a part of our releases or not.
But when it comes to documentation it is obvious that people see a need to 
include this kind of work as well.
I agree with Chris, “to publish a “future work” section of our release library 
that describes more where our community is heading”.

I talked to Daniel yesterday and we think that it would be fine to handle this 
in the same way as the release documentation. We create an introduction 
document explaining what this is about and link to the projects documentation.


But let’s discuss this (and hopefully agree),
I will add this as topic for the docs meeting this afternoon, so people 
concerned are welcome to call in.

BR,
Sofia

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kunzmann, 
Gerald
Sent: den 31 augusti 2016 09:51
To: Georg Kunz; Daniel Smith; David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi David, all,

My 2 cent on your question:

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

Best regards,
Gerald

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith >; 
David McBride 
>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi Daniel, hi all,

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:


-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV


I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section such as “requirements projects”. This could 
be a simple link – just as 

Re: [opnfv-tech-discuss] [VSPERF] topology description scheme

[Tahhan, Maryam]

Hi Martin
Comment inline

From: Klozik, MartinX
Sent: Tuesday, September 6, 2016 3:16 PM
To: Tahhan, Maryam ; opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [VSPERF] topology description scheme

Hi Maryam,

Thanks for initial proposal. It looks good overall. It seems, we are going to 
define a grammar of a small language. In that case it might be useful to define 
it well for both human and machine processing. Just for case, we would like to 
create a class, which will be able to prepare a setup automatically based on 
the scheme name.

In that case, we should consider:

1)  Possible ambiguity in number meaning; May be, we should consider a 
standalone number as an index and number prefixed with x as multiplication 
factor, e.g. LS1 vs. PVx3P
 sounds good

2)  In your proposal is V a synonym for VM with 2 NICs; We should consider 
a possibility of VMs with different NIC number, i.e. to really use V as a 
Virtual NIC, e.g. PVVP in meaning of phy_nic->virt_nic->virt_nic->phy_nic. 
However I can't figure out an intuitive but still flexible way to describe 
complex scenarios, e.g. 1VM with 4NICs in parallel or even 2 VMs in series, 
where 1st VM has 2NICs, but 2nd 4NICs in parallel...
 Just to be clear the proposal suggests V is a virtual NIC not a VNF...  so 
the example for PVP and PVVP was incorrect below... I meant to update that 
before sending out the mail and I forgot... :$

PVP


LS_PV2P


PVVP


LS_PV4P



Best Regards,
Martin

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
Sent: Tuesday, September 06, 2016 11:21 AM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [VSPERF] topology description scheme


Hi folks
I've been thinking about this and I think I have a possible suggestion



Lettering:

It's case sensitive



L - Local

R - Remote

S - vSwitch

P- Physical NIC

V - Virtual NIC

pp - patch port

O - Overlay port - not sure if we need...



Numbering:
Numeric values can follow any of the last S, V, and P or nothing follows them 
which implies a 1.

For ports it implies the number of ports V2 is two virtual ports connected in 
succession.

For switches it actually acts as an Identifier LS2 is local switch 2.





The scheme is really to describe the flows from port to port through the vswitch



so

Current scheme


Proposed scheme


Phy2phy


LS_P2


PVP


LS_PVP


PVVP


LS_PV2P


Multiple VMs in series


LS_PVxP where X is the number


Multiple VMs in Parallel


LS_PVP_x (where X is a number applies to everything surrounded by underscores)


2 local switches doing phy2phy


LS1_P2_LS2_P2


2 local switches patched together


LS1_Ppp_LS2_P


Overlayed -switches on a local and a remote


LS_PO_RS_OP


Overlayed - local switched


LS1_PO_LS2_OP








Not as simple as I would have hoped, but open to any suggestions



BR
Marayam


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

Re: [opnfv-tech-discuss] [Apex] puppet logging for debug

[Tim Rozet]

Hi Peng,
On the jump host you can do opnfv-util debug-stack.  That will print out the 
reason for heat stack failure, including puppet errors.  If that doesn't give 
you enough information, then look at each /var/log/messages on the nodes 
themselves.  That will contain all the puppet and other configuration calls.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Peng Liu" 
To: opnfv-tech-discuss@lists.opnfv.org
Sent: Monday, September 5, 2016 11:18:22 AM
Subject: [opnfv-tech-discuss]  [Apex] puppet logging for debug

Hi Team, 

How can I get the puppet log of overcloud deployment? I made some change in 
dpdk_dataplanes.pp to make ovs-dpdk work, thenI got error when run 'openstack 
overcloud deploy'. 

I try to add '-e 
/usr/share/openstack-tripleo-heat-templates/environments/config-debug.yaml' to 
enable logging for puppet. But I cannot see the folder 
/var/run/heat-config/deployed. 


Thanks, 
-- 
Peng Liu | Senior Software Engineer 

Tel: + 86 10 62608046 (direct) 
Mobile: +86 13801193245 

Red Hat Software (Beijing) Co., Ltd. 
9/F, North Tower C, 
Raycom Infotech Park, 
No.2 Kexueyuan Nanlu, Haidian District, 
Beijing, China, POC 100190 

___
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] [SPC Polestar] Minutes from the OPNFV Polestar Working Group call (September 1, 2016)

[Min Yu]

Attendees: Anthony Soong, Chris Price, Larry Lamers, Margaret Chiosi,
Pierre Lynch, Steven Wright, Tapio Tallgren, Toby Ford, Uli Kleber, Yunjun
Zhang, Min Yu

   -

   Meeting Minutes/Agenda: approved


   -

  There was a suggestion to meet weekly beyond September. A concern was
  raised that a weekly Thursday meeting at 6AM PT will conflict with the
  technical-discuss calls that have been dormant but will become
active soon.

  -

   Review OpenStack Roadmap
   -

  Margaret noted that she likes the visuals in OpenStack Roadmap
  

  from the theme view to release view and down to the project view. In
  particular, the theme-view visual illustrates well what activities are
  happening where. Margaret is hoping that the Aha! tool can facilitate a
  similar visual output for the OPNFV roadmap.
  -

  The group had a discussion if the OpenStack roadmap themes,
  scalability, resiliency, manageability, modularity, and interoperability
  differ from how the same words are understood in the OPNFV community.
  Attendees noted a couple of differences.
  -

 Interoperability in OPNFV refers to the ability to interoperate
 between different functional blocks versus open cloud stacks
in OpenStack.
 -

 Carrier grade in OPNFV is similar to but encompasses more than
 resiliency.
 -

  A discussion followed to further define the initiatives under the
  OPNFV’s goals of reference platform and methodology. A question
was raised
  if several items, such as testing, that are categorized under methodology
  should be grouped under both platform and methodology. A suggestion was
  made to change “initiatives” to “characteristics and methods” to more
  accurately communicate the grouping of these items. Attendees noted both
  the value of continuing the architectural discussion of
characterization of
  themes and the immediate need to focus on defining user stories
in order to
  provide guidance to the technical community.
  -

   User Scenarios of Pain Points and Priorities
   -

  Steven reported that EUAG didn’t discuss the pain points extensively
  at its last call on August 31. They’re aiming to have more refined and
  coherent pain points by the ODL Summit.
  -

  There was a suggestion to jumpstart the process by having a few
  interested members within EUAG create the user stories for VNF
onboarding.
  Uli shared Huawei’s projects related to VNF onboarding and noted they are
  in very early stages. Steven added a few high-level details to consider
  such as inquiring about the existence of VNFs to onboard, how to handle
  proprietary VNFs and measure success from a procedural point of view.
  There was a comment about the need to get down to the next level of
  details. Steven asked Polestar to be sensitive to the time it
may take for
  EUAG to accomplish that.
  -

  Margaret will talk to Ray about scheduling a time and place at the
  ODL Summit for the Polestar WG and the EUAG members to meet F2F to flesh
  out the details and user stories of VNF onboarding.



--
Min Yu
Client Services Coordinator
The Linux Foundation
+1(530) 902-6464 (m)
m...@linuxfoundation.org
Skype: minyudecorah
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [SFQM] contributor request

[Chornyi, TarasX]

Hi all,

I would like to sign up to be a contributor to SFQM.

Thanks,
Taras.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[HU, BIN]

David,

I think we can brainstorm how to better manage those projects that produce docs 
only in D Release, including requirement projects.

For example, when we set up milestones, we can define which milestones are 
applicable to those projects that produce docs only. Just like we defined one 
milestone in Colorado was only applicable to installer projects, and all other 
projects needed to answer “N/A”. “Feature Freeze” could be applicable, because 
those projects should know the outline / toc of the docs they want to produce. 
Other milestones may not be applicable, but documentation-ready is certainly 
applicable.

Regarding other quality metrics, I think the projects should have proofread 
their docs, and validated the technical content in their docs. And each subject 
is a different domain, so it is hard to define other quality metrics. Thus we 
may not need other quality metrics for docs but (1) correct technical content 
(2) proofread and signed off by PTL.

In summary, all I am suggesting is that there is a way to manage those 
projects, and the way is even much easier because there is no code. Based on 
current milestones, we can define a subset of milestones that are applicable to 
them. This way, all projects are included, and it is up to them to produce 
deliverables. If they miss a milestone, for example, if they have no idea what 
to write by feature freeze, probably they may not be able to produce a high 
quality doc with correct technical content by the release date.

Thanks
Bin

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Tuesday, September 06, 2016 1:00 PM
To: HU, BIN 
Cc: SULLIVAN, BRYAN L ; Georg Kunz ; 
Adi Molkho ; Sofia Wallin ; 
Kunzmann, Gerald ; Daniel Smith 
; Christopher Price 
; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Bin,

You hit on a key point:  "meets milestones and other quality metrics".  One 
reason that I question whether requirements projects should join a release is 
that the requirements projects associated with Colorado responded with "N/A" 
for most or all of their milestone reporting.  That's understandable, since the 
milestones are oriented toward projects that are creating or modifying code.  
I'm not aware of any quality metrics that they have been subjected to.

So, that raises the question, should requirements projects be tracked in a 
release?  If so, what milestones or other metrics should be used to track them?

David

On Tue, Sep 6, 2016 at 12:07 PM, HU, BIN 
> wrote:
+1 for Bryan’s point.

If a project requests its docs to be included in release documentation, and it 
meets milestones and other quality metrics and won’t pose any adversary effects 
on release schedule, it should be included.

Many documentation provides “knowledge”, as Heather indicated in a separate 
thread, and is very valuable to industry.

Thanks
Bin

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of SULLIVAN, BRYAN L
Sent: Tuesday, September 06, 2016 9:40 AM
To: Georg Kunz >; Adi 
Molkho >; Sofia Wallin 
>; Kunzmann, Gerald 
>; Daniel Smith 
>; David McBride 
>; 
Christopher Price 
>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
My take is that we have projects, and those projects create documents that are 
optionally (on request of the project) included in the release documentation. 
We need go no further than that. Labelling projects (something I thought we had 
moved away from) or types of documents/focuses (e.g. requirements) and applying 
different policies as to what/how they are included in the release 
documentation, is unnecessary and ultimately confusing to the community.

As an example, my Copper project 
documentation is one 
document (a “design” document but that’s only a repo folder naming convention) 
that 

Re: [opnfv-tech-discuss] [opnfv-tsc] harmonized configuration set for OPNFV

[Daniel Smith]

Hey All

Just as a question of JIRA -  this is/was a defined goal of Genesis, back when 
the original PHAROS specification (which is basically support for the 5 basical 
OStack networks (tagged/untagged), 3 Controller/2Compute Topology and 
supporting either VLAN or VXLAN (so as to support ODL) as the underlay.

This was the compromise and provides the basis for the BareMetal PODs that are 
out there today, demonstratably augemented further in Colorado as components 
have shifted in line with both Openstack changes in Mitaka and other component 
changes (Boron and Neutron IRPs for example). At the Arno, port-B time, 
this issue was visited again within the context of Genesis and we tried to come 
to a common set of simple network naming amongst the installers (so that we 
could have some common ‘installer framework’ established).   The current INFRA 
discussion is key to this as well, since we are now taking about creating some 
tech pieces to allow installer jumphosts to be imaged essentially and swapped 
around – each of these requiring said baseline specification that is common 
across installers.

How would we approach using JIRA to track this issue?  We can write up the 
tickets and do comparison amongst the installers and then as well (we were 
looking at a CR or some process for inclusion of adaptations of this 
specification – which would then be propagated to community labs so as to “farm 
out” for labs that could meet that spec.

Should the tickets be in Genesis or is INFRA/PHAROS now picking up the task of 
communalizing the topologies – which would most likely also play into the 
scenario naming discussion as well.?

What would you like to see in the contents of the JIRA?

Cheers,
D

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Yujun Zhang
Sent: Tuesday, September 06, 2016 10:49 PM
To: SULLIVAN, BRYAN L ; Jack Morgan ; 
TSC OPNFV 
Cc: TECH-DISCUSS OPNFV 
Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] harmonized configuration set for 
OPNFV

I agree. We should track this issue in JIRA. Which project shall we put it in? 
Pharos?

Besides the configuration harmonization, we have also spotted some performance 
deviation between environments deployed by different installers.

Theoretically , a consistent environment should be targeted no matter which 
installer user has chosen.
--
Yujun

On Tue, Sep 6, 2016 at 11:52 PM SULLIVAN, BRYAN L 
> wrote:
I’d suggest a Jira issue be created that we can add details to. I agree that 
this will be a very helpful effort. Right now there is substantial variation in 
the deployed platform e.g. even to such things as:

-  Number and names of networks, routers, etc created by default

-  Default images created in glance

-  Names of projects (e.g. “services” vs “service”)

-  …

These variations add complexity to install and test scripts for features. As we 
eliminate the variations, we do need a process to identify and address  impact 
to existing code and tests.

Thanks,
Bryan Sullivan | AT

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Jack Morgan
Sent: Tuesday, September 06, 2016 8:41 AM
To: TSC OPNFV
Cc: TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV


Yujun,

Thanks for raising this issue. This is a longer term issue to solve but for now 
I've added it as a topic for to the Infra WG weekly meeting. I'm hoping to 
solve this for the D release and been tasked by the TSC to help drive this 
effort. Please join the Infra WG meeting to provide your input.

On 09/05/2016 12:11 AM, Yujun Zhang wrote:
Dear TSC,

We have encountered some issues on the openstack environment configuration for 
some projects and it could not be resolved within the project scope. So I have 
to escalate it to TSC to look for a solution.

Some OPNFV project requires dedicated configuration on common services. But the 
environment deployed by the installers may not always come with a valid 
configuration.

For example, doctor project requires `notifier://?topic=alarm.all` in 
ceilometer event pipeline configuration. But the default deployed environment 
by fuel does not include this configuration. There has been a long debates 
between the two teams on where the modification should be made [1][2]. The 
contradiction is that if we enable this notifier topic, doctor will work, but 
nobody can guarantee that other projects are not affected.

OPNFV is targeting to deliver a "de facto standard open source NFV platform for 
the industry" [3]. The platform on software part includes not only the services 
installed but also a common