[opnfv-tech-discuss] Canceled: Pinpoint weekly meeting

[Adi Molkho]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Israel Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1FR;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Adi Molkho:MAILTO:adi.mol...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='opnfv-tec
 h-disc...@lists.opnfv.org':MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=DEBEAU Eri
 c IMT/OLN:MAILTO:eric.deb...@orange.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sharon Ko
 tler':MAILTO:skot...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Srinivas T
 adepalli (srinivas.tadepa...@tcs.com):MAILTO:srinivas.tadepa...@tcs.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ramki_Kri
 sh...@dell.com':MAILTO:ramki_krish...@dell.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Canio Cil
 lis':MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Mario Tor
 recillas Rodriguez':MAILTO:mario.rodrig...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Rodriguez
 , Iben'":MAILTO:iben.rodrig...@spirent.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bhushan B
 harat':MAILTO:bharat.bhus...@freescale.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Rashid Kh
 an':MAILTO:rk...@redhat.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Thomas He
 rbert':MAILTO:therb...@redhat.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Haller, J
 ohn H (John)'":MAILTO:john.hal...@alcatel-lucent.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Randy Ran
 dhawa':MAILTO:rrand...@brocade.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Saxena, V
 inay (HPE Fellow)'":MAILTO:vinay.sax...@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Franck BA
 UDIN':MAILTO:franck.bau...@qosmos.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Smith, Ke
 vin M'":MAILTO:kevin.m.sm...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Brian Bro
 oks':MAILTO:brian.bro...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Skip Boot
 h (ebooth)':MAILTO:ebo...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'DRUTA, DA
 N'":MAILTO:dd5...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ahmed Elb
 ornou (amaged)':MAILTO:ama...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Seiler, G
 lenn'":MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="SHAMIR, Oh
 ad (Ohad)":MAILTO:ohad.sha...@alcatel-lucent.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Piyush Sa
 rwal':MAILTO:psar...@us.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Rooke, Mi
 chael (Nokia - FI/Espoo)'":MAILTO:michael.ro...@nokia.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='최강일
 ':MAILTO:forerun...@etri.re.kr
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Damena, M
 ichael Melesse'":MAILTO:michael.mel.dam...@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Gabor Hal
 ász':MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Winn, Sea
 n'":MAILTO:sean.w...@emc.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Bernier, 
 Daniel (520165)'":MAILTO:daniel.bern...@bell.ca
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Shamir, O
 had (Nokia - IL)'":MAILTO:ohad.sha...@nokia.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hesham ElB
 akoury:MAILTO:hesham.elbako...@huawei.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mishael We
 xler:MAILTO:mishael.wex...@huawei.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Afek, Ifa
 t (Nokia - IL)'":MAILTO:ifat.a...@nokia.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Agarwal, 
 Anshu'":MAILTO:anshu.agar...@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bob Monkm
 an':MAILTO:bob.monk...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Alan McNa
 mee':MAILTO:alan...@openet.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='jamil.cha
 w...@orange.com':MAILTO:jamil.cha...@orange.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Tim Dalto
 n':MAILTO:t.dal...@kyrio.com

[opnfv-tech-discuss] [fuel] Fuel@OPNFV colorado.1.0 release artifacts and meta-data

[Jonas Bjurel]

Fuel@OPNFV is now ready for the OPNFV Colorado 1.0 release; artifacts and 
release info can be found below:



Release: Colorado 1.0

Project: Fuel@OPNFV

Git-tag: colorado.1.0

GIT Repository: https://git.opnfv.org/cgit/fuel/tree/?h=colorado.1.0

Commit-Id:/SHA-1: cc10e9261f6da77f10ac87e1ff4b86c9e0e44b35

Iso: http://artifacts.opnfv.org/fuel/colorado/opnfv-2016-09-21_19-58-55.iso
Documentation:

-Release notes:

o   http://artifacts.opnfv.org/fuel/review/7/releasenotes/index.html

Official link which will be produced after tonight’s daily build:  
http://artifacts.opnfv.org/fuel/colorado/docs/releasenotes/index.html

-Installation procedures:

o   
http://artifacts.opnfv.org/fuel/review/7/installationprocedure/index.html
Official link which will be produced after tonight’s daily build:  
http://artifacts.opnfv.org/fuel/colorado/docs/installationprocedure/index.html

-Build procedures:

o   http://artifacts.opnfv.org/fuel/review/7/buildprocedure/index.html

Official link which will be produced after tonight’s daily build:  
http://artifacts.opnfv.org/fuel/colorado/docs/buildprocedure/index.html


Fuel@OPNFV QA status:

-Functest: 
http://testresults.opnfv.org/reporting/functest/release/colorado/index-status-fuel.html

-Yardstick: 
https://wiki.opnfv.org/display/yardstick/Yardstick+Colorado+CI+Status

The Fuel@OPNFV master branch is since today open for D-release work.
>From September 23, the stable/colorado branch will be open for Colorado 2.0 
>follow-up release work.

I would like to thank all of you: Fuel@OPNFV- contributors, committers, 
plugin/feature developers,  scenario owners, as well as the releng/infra/pharos 
team who have made this possible!
BR/Jonas
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Results of Security Threat Analysis for Colorado.

[Sona Sarmadi]

Well done, Thanks Luke :)


On 2016-09-21 16:49, Luke Hinds wrote:
> Hello All,
>
> An update on the results of the Security Threat Analysis for Colorado.
>
> All projects were given a cursory scan using our security lint tool
> 'anteater', and I then took an in-depth manual review and released
> individual project reports to the PTL's, with each containing
> recommended code remediation's to address issues that were found.
>
> The whole process resulted in twelve patches being merged into nine
> projects:
>
> https://gerrit.opnfv.org/gerrit/#/c/20751 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21995 master branch
> https://gerrit.opnfv.org/gerrit/#/c/20911 master branch
> https://gerrit.opnfv.org/gerrit/#/c/20693 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21541 master branch
> https://gerrit.opnfv.org/gerrit/#/c/22139 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21997 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21985 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21499 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21799 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21437 master branch
> https://gerrit.opnfv.org/gerrit/#/c/22007 stable/brahmaputra
>
> A vulnerability was also discovered in Brahmaputra release and handled
> under our vulnerability management process. This is now patched in
> c-release and backported to b.
>
> Overall the highlight of the key threats found were:
>
> * Cross site scripting attacks [1]
> * Unsafe use of eval [2]
> * Unsafe yaml handling [3]
> * Possible shell executions [4]
> * Leakage of private keys [5].
> * Running flask in debug mode. [6]
>
> A lot of false positives were also present, what with the OPNFV being
> test oriented.
>
> I personally want to thank everyone involved in the above patches, who
> mobilized with speed and handled the situation with a level head and
> professionalism. Many thanks, you know who you all are.
>
> Also a thanks to Michael Lazar & Alexander of DataArt who contacted me
> with an issue they found while researching OPNFV security.
>
> Looking forward
> --
>
> So the threat analysis has definitely proved very useful, but very time
> consuming too - analyzing thousands of lines of code, over many projects
> meant many a late night. I now have a tool to automate this, so I will
> seek to integrate this as a gerrit / CI gate / job.
>
> However, you can all really help here, by using the gerrit tag
> ‘SecurityImpact’ we have.
>
> All you need to do is mention ‘SecurityImpact’ anywhere in a gerrit
> review and it will automatically notify the Security group members, to
> come in and provide feedback in your gerrit patch. As a general rule,
> use this if ever in doubt on a change (or even not). The group are happy
> to get any requests come in. More details can be found on our secure
> code page:
>
> https://wiki.opnfv.org/display/security/Securecode
>
> One other key point is the use of private keys / passwords in projects.
> This I understand can be challenging, as we automate a lot of black box
> style testing which is hands off. I am of the mind to set up a working
> group to look at this topic and help formulate some guidance on handling
> SSH / TLS keys, certs. Any volunteers, please do let me know.
>
> Last of all, we really need more folk helping in security. A lot of
> 'hand wringing' happens in the industry on security being a top concern,
> but very little are willing to put boots on the ground. It would be
> really nice to see that happen, so if you know of anyone in your
> company, encourage them (or even yourself) to come to our meetings and
> get involved.
>
> References:
>
> [1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
> [2] http://lucumr.pocoo.org/2011/2/1/exec-in-python/
> [3]
> https://security.openstack.org/guidelines/dg_avoid-dangerous-input-parsing-libraries.html
> [4] https://security.openstack.org/guidelines/dg_avoid-shell-true.html
> [5]
> http://security.stackexchange.com/questions/55525/how-can-an-attacker-use-a-leaked-private-key
> [6]
> https://labs.detectify.com/2015/10/02/how-patreon-got-hacked-publicly-exposed-werkzeug-debugger/
> [5]
>
> Regards,
>
> Luke - Security Group PTL
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

Re: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

[Christopher Price]

That should be fine Jonas.
Aric will run through and make sure everything is in order tomorrow morning US 
time, you should be done before that.
/ Chris

From: Jonas Bjurel 
Date: Wednesday 21 September 2016 at 20:39
To: Christopher Price , opnfv-project-leads 
, TECH-DISCUSS OPNFV 

Subject: RE: Labelling your Colorado repo for the release.

My plan was to tag it 4.30 PM CET tomorrow such that we could have a final 
committer review in the fuel project meeting, Chris would that be to late?
BR/Jonas

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Wednesday, September 21, 2016 7:24 PM
To: opnfv-project-le...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

Hi Project leads,

If you have not already done it, now is the right time to make sure you have 
the Colorado 1.0 label correctly applied to your repo.
Please follow the instructions here:  
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release

/ Chris

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

Re: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

[Jonas Bjurel]

My plan was to tag it 4.30 PM CET tomorrow such that we could have a final 
committer review in the fuel project meeting, Chris would that be to late?
BR/Jonas

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Wednesday, September 21, 2016 7:24 PM
To: opnfv-project-le...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

Hi Project leads,

If you have not already done it, now is the right time to make sure you have 
the Colorado 1.0 label correctly applied to your repo.
Please follow the instructions here:  
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release

/ Chris

___
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-project-leads] Labelling your Colorado repo for the release.

[Brady Allen Johnson]

I just got that final doc patch merged.

The SFC project is now labeled for Colorado 1.0:

   $ git tag -am "colorado.1.0" colorado.1.0
   $ git push origin colorado.1.0
   Counting objects: 1, done.
   Writing objects: 100% (1/1), 169 bytes | 0 bytes/s, done.
   Total 1 (delta 0), reused 0 (delta 0)
   remote:
   remote: Processing changes: refs: 1, done
   To ssh://ebrj...@gerrit.opnfv.org:29418/sfc
 * [new tag] colorado.1.0 -> colorado.1.0

Regards,

Brady


On 21/09/16 20:04, Brady Allen Johnson wrote:


Chris,

I understood that we had until Thursday to do the labeling.

I have one minor release notes and scenario doc patch pending that 
should be merged shortly. Once its merged, I'll do the label.


Regards,

Brady


On 21/09/16 19:25, David McBride wrote:
Note that Aric just added some troubleshooting instructions at the 
bottom of the page that Chris just linked.  Please follow those 
instructions if you are having difficulty.


David

On Wed, Sep 21, 2016 at 10:23 AM, Christopher Price 
> wrote:


Hi Project leads,

If you have not already done it, now is the right time to make
sure you have the Colorado 1.0 label correctly applied to your repo.

Please follow the instructions here:

https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release




/ Chris


___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org

https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads





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


Skype: davidjmcbride1
IRC: dmcbride


___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads




___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads


___
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-project-leads] [release] D-release schedule

[Jonas Bjurel]

I really think this is unnecessary governance from the release projects, if a 
project secure resources them self and push relevant patches to releng to 
enable branch verification I have very hard time to see that anyone else should 
bother.
I also don’t see the point with the resources, I do understand that there is 
less resources need when only verifying master, but where does the resources 
come from when we eventually branch and do both master and stable verification, 
they just don’t pop up, infact they come from the pool of HW resources that has 
largely been unutilized during the early project cycle!
In the way proposed we will not utilize the human resources in an optimal way, 
as they will idle at the end of the project, not being allowed to move forward. 
Infact this already happened in Colorado, we could have pushed much harder!
BR/Jonas

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Wednesday, September 21, 2016 7:25 PM
To: Jonas Bjurel 
Cc: Christopher Price ; 
opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

Jonas,

There may not be sufficient resources available prior to the opening of the 
window.  So, this is a signal to the infra/CI team to be prepared to support CI 
on both master and stable branch.  However, perhaps we could consider expanding 
the window from 1 week to, say 2 weeks.

David

On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel 
> wrote:
I don’t see why we need a OPNFV policy on when earliest a stable branch could 
happen – please explain!
BR/Jonas

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of David McBride
Sent: Tuesday, September 13, 2016 8:58 PM
To: Christopher Price >
Cc: 
opnfv-project-le...@lists.opnfv.org;
 TECH-DISCUSS OPNFV 
>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

I think that we've reduced the branch-related overhead in 'Danube' by closing 
the stable branch window just 10 days before the release, as opposed to about a 
month with Colorado.  My concern about individual projects deciding whether to 
branch is that I think that it creates some confusion about the location of the 
candidate release.  I think it's simpler and more predictable if we have a 
common process for all projects participating in the release.

David

On Tue, Sep 13, 2016 at 8:21 AM, Christopher Price 
> wrote:
We are making some progress.

While I do agree with this: “I think projects should have autonomy over when 
branches are created.”.
I also think it is up to the release project to set the projects with the 
latest date to do it if they want to participate in any given release.  I think 
that’s essentially what we are trying to tune and optimize for everyone in this 
dialog.

/ Chris

On 13/09/16 16:10, "Dave Neary" 

 on behalf of dne...@redhat.com> wrote:

Hi,

On 09/13/2016 06:42 AM, Frank Brockners (fbrockne) wrote:
> one thing that we’ve not closed on in the discussion last Tuesday is the
> stable-branching milestone. Per what Morgan and I elaborated on:
> Branching occurs a lot of unnecessary overhead for projects which have a
> single development stream only. Hence I’d like to propose that
>
> ·   the branching milestones **prior** to the release should
> **only** be applied to projects which do parallel development.
>
> ·   All other projects would branch on the release date – so that we
> have a proper maintenance branch.
>
> Thoughts?

I'm in favour of anything that removes process overhead from projects -
I think projects should have autonomy over when branches are created.

Thanks,
Dave.

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





--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 

Re: [opnfv-tech-discuss] [opnfv-project-leads] Labelling your Colorado repo for the release.

[Brady Allen Johnson]

Chris,

I understood that we had until Thursday to do the labeling.

I have one minor release notes and scenario doc patch pending that 
should be merged shortly. Once its merged, I'll do the label.


Regards,

Brady


On 21/09/16 19:25, David McBride wrote:
Note that Aric just added some troubleshooting instructions at the 
bottom of the page that Chris just linked. Please follow those 
instructions if you are having difficulty.


David

On Wed, Sep 21, 2016 at 10:23 AM, Christopher Price 
> wrote:


Hi Project leads,

If you have not already done it, now is the right time to make
sure you have the Colorado 1.0 label correctly applied to your repo.

Please follow the instructions here:

https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release




/ Chris


___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org

https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads





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


Skype: davidjmcbride1
IRC: dmcbride


___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads


___
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-project-leads] Labelling your Colorado repo for the release.

[David McBride]

Note that Aric just added some troubleshooting instructions at the bottom
of the page that Chris just linked.  Please follow those instructions if
you are having difficulty.

David

On Wed, Sep 21, 2016 at 10:23 AM, Christopher Price <
christopher.pr...@ericsson.com> wrote:

> Hi Project leads,
>
>
>
> If you have not already done it, now is the right time to make sure you
> have the Colorado 1.0 label correctly applied to your repo.
>
> Please follow the instructions here:  https://wiki.opnfv.org/
> display/SWREL/Git+Tagging+Instructions+for+Colorado+Release
>
>
>
> / Chris
>
>
>
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
>


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

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[David McBride]

Jonas,

There may not be sufficient resources available prior to the opening of the
window.  So, this is a signal to the infra/CI team to be prepared to
support CI on both master and stable branch.  However, perhaps we could
consider expanding the window from 1 week to, say 2 weeks.

David

On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel 
wrote:

> I don’t see why we need a OPNFV policy on when earliest a stable branch
> could happen – please explain!
>
> BR/Jonas
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *David McBride
> *Sent:* Tuesday, September 13, 2016 8:58 PM
> *To:* Christopher Price 
> *Cc:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject:* Re: [opnfv-tech-discuss] [opnfv-project-leads] [release]
> D-release schedule
>
>
>
> I think that we've reduced the branch-related overhead in 'Danube' by
> closing the stable branch window just 10 days before the release, as
> opposed to about a month with Colorado.  My concern about individual
> projects deciding whether to branch is that I think that it creates some
> confusion about the location of the candidate release.  I think it's
> simpler and more predictable if we have a common process for all projects
> participating in the release.
>
>
>
> David
>
>
>
> On Tue, Sep 13, 2016 at 8:21 AM, Christopher Price 
> wrote:
>
> We are making some progress.
>
> While I do agree with this: “I think projects should have autonomy over
> when branches are created.”.
> I also think it is up to the release project to set the projects with the
> latest date to do it if they want to participate in any given release.  I
> think that’s essentially what we are trying to tune and optimize for
> everyone in this dialog.
>
> / Chris
>
>
> On 13/09/16 16:10, "Dave Neary"  lists.opnfv.org on behalf of dne...@redhat.com> wrote:
>
> Hi,
>
> On 09/13/2016 06:42 AM, Frank Brockners (fbrockne) wrote:
> > one thing that we’ve not closed on in the discussion last Tuesday is
> the
> > stable-branching milestone. Per what Morgan and I elaborated on:
> > Branching occurs a lot of unnecessary overhead for projects which
> have a
> > single development stream only. Hence I’d like to propose that
> >
> > ·   the branching milestones **prior** to the release should
> > **only** be applied to projects which do parallel development.
> >
> > ·   All other projects would branch on the release date – so
> that we
> > have a proper maintenance branch.
> >
> > Thoughts?
>
> I'm in favour of anything that removes process overhead from projects -
> I think projects should have autonomy over when branches are created.
>
> Thanks,
> Dave.
>
> --
> 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
>
>
>
>
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>



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

[opnfv-tech-discuss] Labelling your Colorado repo for the release.

[Christopher Price]

Hi Project leads,

If you have not already done it, now is the right time to make sure you have 
the Colorado 1.0 label correctly applied to your repo.
Please follow the instructions here:  
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release

/ Chris

___
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 Jenkins Restart

[Fatih Degirmenci]

Hi,

Jenkins has been restarted and some jobs were aborted during the process. We 
will keep an eye on it to make sure it stays alive until the release is done 
and increase the memory afterwards.

/Fatih

From:  on behalf of Fatih 
Degirmenci 
Date: Wednesday, 21 September 2016 at 18:28
To: "opnfv-tech-discuss@lists.opnfv.org" 
Subject: [opnfv-tech-discuss] OPNFV Jenkins Restart

Hi,

Jenkins is having memory issues and all the jobs are hanging. We need to 
restart Jenkins in order to get things moving again.

This will result in failures for ongoing jobs and we will retrigger failed 
patch verification jobs once the restart is done. Daily jobs should be 
triggered via timer or you need to trigger them manually depending on the job.

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

[opnfv-tech-discuss] Technical Community Discussion Canceled Tomorrow (9/22)

[HU, BIN]

Hello community,



There is no new project proposal in the backlog. And there is not urgent issue 
to discuss either.



So I propose to cancel our technical discussion tomorrow (9/22) so that 
everyone can focus on the last sprint of Colorado release, which is targeted 
for tomorrow 9/22.



We re-convene our discussion on some other topics after Colorado is shipped.



Thank you

Bin

___
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] Results of Security Threat Analysis for Colorado.

[Ash]

Thanks for all your hard work, Luke!

On Wed, Sep 21, 2016 at 7:49 AM, Luke Hinds  wrote:

> Hello All,
>
> An update on the results of the Security Threat Analysis for Colorado.
>
> All projects were given a cursory scan using our security lint tool
> 'anteater', and I then took an in-depth manual review and released
> individual project reports to the PTL's, with each containing
> recommended code remediation's to address issues that were found.
>
> The whole process resulted in twelve patches being merged into nine
> projects:
>
> https://gerrit.opnfv.org/gerrit/#/c/20751 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21995 master branch
> https://gerrit.opnfv.org/gerrit/#/c/20911 master branch
> https://gerrit.opnfv.org/gerrit/#/c/20693 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21541 master branch
> https://gerrit.opnfv.org/gerrit/#/c/22139 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21997 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21985 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21499 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21799 master branch
> https://gerrit.opnfv.org/gerrit/#/c/21437 master branch
> https://gerrit.opnfv.org/gerrit/#/c/22007 stable/brahmaputra
>
> A vulnerability was also discovered in Brahmaputra release and handled
> under our vulnerability management process. This is now patched in
> c-release and backported to b.
>
> Overall the highlight of the key threats found were:
>
> * Cross site scripting attacks [1]
> * Unsafe use of eval [2]
> * Unsafe yaml handling [3]
> * Possible shell executions [4]
> * Leakage of private keys [5].
> * Running flask in debug mode. [6]
>
> A lot of false positives were also present, what with the OPNFV being
> test oriented.
>
> I personally want to thank everyone involved in the above patches, who
> mobilized with speed and handled the situation with a level head and
> professionalism. Many thanks, you know who you all are.
>
> Also a thanks to Michael Lazar & Alexander of DataArt who contacted me
> with an issue they found while researching OPNFV security.
>
> Looking forward
> --
>
> So the threat analysis has definitely proved very useful, but very time
> consuming too - analyzing thousands of lines of code, over many projects
> meant many a late night. I now have a tool to automate this, so I will
> seek to integrate this as a gerrit / CI gate / job.
>
> However, you can all really help here, by using the gerrit tag
> ‘SecurityImpact’ we have.
>
> All you need to do is mention ‘SecurityImpact’ anywhere in a gerrit
> review and it will automatically notify the Security group members, to
> come in and provide feedback in your gerrit patch. As a general rule,
> use this if ever in doubt on a change (or even not). The group are happy
> to get any requests come in. More details can be found on our secure
> code page:
>
> https://wiki.opnfv.org/display/security/Securecode
>
> One other key point is the use of private keys / passwords in projects.
> This I understand can be challenging, as we automate a lot of black box
> style testing which is hands off. I am of the mind to set up a working
> group to look at this topic and help formulate some guidance on handling
> SSH / TLS keys, certs. Any volunteers, please do let me know.
>
> Last of all, we really need more folk helping in security. A lot of
> 'hand wringing' happens in the industry on security being a top concern,
> but very little are willing to put boots on the ground. It would be
> really nice to see that happen, so if you know of anyone in your
> company, encourage them (or even yourself) to come to our meetings and
> get involved.
>
> References:
>
> [1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
> [2] http://lucumr.pocoo.org/2011/2/1/exec-in-python/
> [3]
> https://security.openstack.org/guidelines/dg_avoid-
> dangerous-input-parsing-libraries.html
> [4] https://security.openstack.org/guidelines/dg_avoid-shell-true.html
> [5]
> http://security.stackexchange.com/questions/55525/how-can-
> an-attacker-use-a-leaked-private-key
> [6]
> https://labs.detectify.com/2015/10/02/how-patreon-got-
> hacked-publicly-exposed-werkzeug-debugger/
> [5]
>
> Regards,
>
> Luke - Security Group PTL
> --
> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
> t: +44 12 52 36 2483
>
> ___
> 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

[opnfv-tech-discuss] Results of Security Threat Analysis for Colorado.

[Luke Hinds]

Hello All,

An update on the results of the Security Threat Analysis for Colorado.

All projects were given a cursory scan using our security lint tool
'anteater', and I then took an in-depth manual review and released
individual project reports to the PTL's, with each containing
recommended code remediation's to address issues that were found.

The whole process resulted in twelve patches being merged into nine
projects:

https://gerrit.opnfv.org/gerrit/#/c/20751 master branch
https://gerrit.opnfv.org/gerrit/#/c/21995 master branch
https://gerrit.opnfv.org/gerrit/#/c/20911 master branch
https://gerrit.opnfv.org/gerrit/#/c/20693 master branch
https://gerrit.opnfv.org/gerrit/#/c/21541 master branch
https://gerrit.opnfv.org/gerrit/#/c/22139 master branch
https://gerrit.opnfv.org/gerrit/#/c/21997 master branch
https://gerrit.opnfv.org/gerrit/#/c/21985 master branch
https://gerrit.opnfv.org/gerrit/#/c/21499 master branch
https://gerrit.opnfv.org/gerrit/#/c/21799 master branch
https://gerrit.opnfv.org/gerrit/#/c/21437 master branch
https://gerrit.opnfv.org/gerrit/#/c/22007 stable/brahmaputra

A vulnerability was also discovered in Brahmaputra release and handled
under our vulnerability management process. This is now patched in
c-release and backported to b.

Overall the highlight of the key threats found were:

* Cross site scripting attacks [1]
* Unsafe use of eval [2]
* Unsafe yaml handling [3]
* Possible shell executions [4]
* Leakage of private keys [5].
* Running flask in debug mode. [6]

A lot of false positives were also present, what with the OPNFV being
test oriented.

I personally want to thank everyone involved in the above patches, who
mobilized with speed and handled the situation with a level head and
professionalism. Many thanks, you know who you all are.

Also a thanks to Michael Lazar & Alexander of DataArt who contacted me
with an issue they found while researching OPNFV security.

Looking forward
--

So the threat analysis has definitely proved very useful, but very time
consuming too - analyzing thousands of lines of code, over many projects
meant many a late night. I now have a tool to automate this, so I will
seek to integrate this as a gerrit / CI gate / job.

However, you can all really help here, by using the gerrit tag
‘SecurityImpact’ we have.

All you need to do is mention ‘SecurityImpact’ anywhere in a gerrit
review and it will automatically notify the Security group members, to
come in and provide feedback in your gerrit patch. As a general rule,
use this if ever in doubt on a change (or even not). The group are happy
to get any requests come in. More details can be found on our secure
code page:

https://wiki.opnfv.org/display/security/Securecode

One other key point is the use of private keys / passwords in projects.
This I understand can be challenging, as we automate a lot of black box
style testing which is hands off. I am of the mind to set up a working
group to look at this topic and help formulate some guidance on handling
SSH / TLS keys, certs. Any volunteers, please do let me know.

Last of all, we really need more folk helping in security. A lot of
'hand wringing' happens in the industry on security being a top concern,
but very little are willing to put boots on the ground. It would be
really nice to see that happen, so if you know of anyone in your
company, encourage them (or even yourself) to come to our meetings and
get involved.

References:

[1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[2] http://lucumr.pocoo.org/2011/2/1/exec-in-python/
[3]
https://security.openstack.org/guidelines/dg_avoid-dangerous-input-parsing-libraries.html
[4] https://security.openstack.org/guidelines/dg_avoid-shell-true.html
[5]
http://security.stackexchange.com/questions/55525/how-can-an-attacker-use-a-leaked-private-key
[6]
https://labs.detectify.com/2015/10/02/how-patreon-got-hacked-publicly-exposed-werkzeug-debugger/
[5]

Regards,

Luke - Security Group PTL
-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
t: +44 12 52 36 2483


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [SFC] Agenda for today's meeting, Sep 21

[Brady Allen Johnson]

Here are the minutes of meeting from today's meeting:

http://ircbot.wl.linuxfoundation.org/meetings/opnfv-sfc/2016/opnfv-sfc.2016-09-21-14.02.html

Regards,

Brady


On 21/09/16 12:39, Brady Allen Johnson wrote:


Hello,

Lets cover the following in today's weekly meeting:

  * Scope for Colorado 2.0
  o what's the status of the Tacker plug-in for FUEL? Should we
spend time registering the service in the proxy or better wait
for the plug-in?
  * Help debugging Netvirt issue
  o OPNFV SFC needs to be deployed multiple times.
  o In the first deployment, Netvirt OpenFlow tables are not written.
  * Testing multi-compute


Regards,

Brady



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

[Taseer Ahmed]

Hi I had want to contribute to the Qtip Project.[0]

My Linux Foundation account is 'linux_geek'.

Besides code patches, would I also be able to get reviews for changes in
documentations as well ?

[0]. https://gerrit.opnfv.org/gerrit/#/q/Qtip

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

[opnfv-tech-discuss] [tech-discuss][fuel] master is open for D-release

[Jonas Bjurel]

The master branch is now open for D-release work.
Fixes relevant to both master and stable/colorado should still be 
cherry-picked, while fixes to stable/colorado not relevant to master are pushed 
directly to stable/colorado.
BR/Jonas
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Security Advisory] Private key `vtep-privkey.pem` resides in ansible files directory for open-contrail role in Compass4NFV.

[Luke Hinds]

Private key `vtep-privkey.pem` resides in ansible files directory for
open-contrail role in Compass4NFV.
---

Date: Sep 21, 2016

CVE #: Pending

### Affects ###

Brahmaputra release.

### Description ###

A private key ‘vtep-privkey.pem’ was discovered in the ansible role for
open-contrail in Compass4NFV project folders. With this key being in the
public domain (git repository), if implemented by a user it could result
in man-in-the-middle type attacks between the Open vSwitch Database
(OVSDB) and Tor (top of the rack) switch.

### Patches ###

https://gerrit.opnfv.org/gerrit/#/c/21997 master branch
https://gerrit.opnfv.org/gerrit/#/c/22007 stable/brahmaputra

### Steps to patch ###

 Brahmaputra 

Users of Brahmaputra should follow the steps outlined below to patch
this issue.

1. Update compass4nfv code

If you don't have local compass4nfv code, then directly get latest
brahmaputra branch code.

$ git clone https://git.opnfv.org/cgit/compass4nfv/
$ git checkout remotes/origin/stable/brahmaputra

If you have local compass4nfv code, change to compass4nfv code directory
and perform:

$ git branch --set-upstream-to=origin/stable/brahmaputra stable/brahmaputra
$ git pull

or

$ rm -rf deploy/adapters/ansible/roles/open-contrail/files/provision

2. Follow the installation guide [1] to deploy openstack (Skip if you
already deployed openstack)

3. Clean vtep-privkey.pem key in compass-core

ssh login to compass-core(192.168.200.2) as root, and then run below
command:

# find / -name vtep-privkey.pem | xargs rm

 Colorado 

No action is required for Colorado release users, as the fix has been
applied directly into the master branch pre-release.

### Contact and References ###

Reported by: Luke Hinds, Red Hat
Contact: opnfv-secur...@lists.opnfv.org
This Advisory: https://wiki.opnfv.org/pages/viewpage.action?pageId=7768349
[1]
http://artifacts.opnfv.org/compass4nfv/brahmaputra/docs/configguide/index.html
http://www.juniper.net/techpubs/en_US/junos16.1/topics/task/installation/sdn-ovsdb-ssl-files-installing.html




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [SFC] Agenda for today's meeting, Sep 21

[Brady Allen Johnson]

Hello,

Lets cover the following in today's weekly meeting:

 * Scope for Colorado 2.0
 o what's the status of the Tacker plug-in for FUEL? Should we
   spend time registering the service in the proxy or better wait
   for the plug-in?
 * Help debugging Netvirt issue
 o OPNFV SFC needs to be deployed multiple times.
 o In the first deployment, Netvirt OpenFlow tables are not written.
 * Testing multi-compute


Regards,

Brady

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

[opnfv-tech-discuss] [bottlenecks] bottlenecks weekly meeting 09-22 (1:00-2:00 UTC, Thursday, 9:00-10:00 Beijing Time, Thursday, PDT 18:00-19:00 Wednesday )

[Yuyang (Gabriel)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Australia Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Yuyang (Gabriel):MAILTO:gabriel.yuy...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Tianhongbo
 :MAILTO:hongbo.tianhon...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Lijun (Mat
 thew):MAILTO:matthew.li...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=liangqi (D
 ):MAILTO:liang...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liyiting:M
 AILTO:liyit...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=mrebellon@
 sandvine.com:MAILTO:mrebel...@sandvine.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=wangyaogua
 ng (A):MAILTO:sunshine.w...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=michael.a.
 ly...@intel.com:MAILTO:michael.a.ly...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=limingjian
 g:MAILTO:limingji...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=邓灵莉/
 Lingli Deng:MAILTO:denglin...@chinamobile.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=qwyang0126
 @gmail.com:MAILTO:qwyang0...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Prakash Ra
 mchandran:MAILTO:prakash.ramchand...@huawei.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=zh-CN:Hi\,\n\nThe Bottlenecks weekly meeting will be h
 eld at 1:00-2:00 UTC\, Thursday\, 9:00-10:00 Beijing Time\, Thursday\, PDT
  18:00-19:00 Wednesday.\nWelcome to join our discussion. Details of this m
 eeting are shown below.\n[X]\nAgenda:\n1.  Bottlenecks Colorado Discus
 sion\n2.  Report of the Release Meeting\n3.  Test Results Discussi
 on for the proposed (Posca) Testsuite\n4.  Test Cases Discussion for t
 he proposed (Posca) Testsuit\n\nMeeting Resources\n\nPlease join the meeti
 ng from your computer\, tablet or smartphone.\nhttps://global.gotomeeting.
 com/join/882532573\n\nYou can also dial in using your phone.\nUnited State
 s (Toll-free): 1 877 309 2070\nUnited States : +1 (312) 757-3119\n\n\nAcce
 ss Code: 882-532-573\n[X]\nBest\,\nYang\n\n\n\n\n\n
SUMMARY;LANGUAGE=zh-CN:[bottlenecks] bottlenecks weekly meeting 09-22 (1:00
 -2:00 UTC\, Thursday\, 9:00-10:00 Beijing Time\, Thursday\, PDT 18:00-19:0
 0 Wednesday )
DTSTART;TZID=W. Australia Standard Time:20160922T09
DTEND;TZID=W. Australia Standard Time:20160922T10
UID:04008200E00074C5B7101A82E008202A972F2F14D201000
 01000CCFC62D83A1FEE49BBEA44BB1E036ADE
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160921T094004Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=zh-CN:https://global.gotomeeting.com/join/882532573
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:1351981024
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [ovsnfv] [vsperf] Analysis of Microburst on VSwitch

[O Mahony, Billy]

Hi Chunghan,

Thanks for your presentation on Monday 
(https://wiki.opnfv.org/download/attachments/5046510/0919_ovsnfv.pdf?version=1=1474280389000=v2
 ). It was very interesting to see where packets are lost when OVS is 
overloaded.

There is a vSwitch testing project in OPNFV - vsperf 
https://wiki.opnfv.org/display/vsperf/?s[]=vsperf

This has a set of standardized tests that can be run on vSwitches - currently 
it supports OVS and OVS-DPDK. The tests have been defined and codified in an 
IETF draft 
https://wiki.opnfv.org/display/vsperf/Vswitchperf+Ietf+Draft+Submission , 
though not all those tests are supported yet. It currently supports IXIA (h/w) 
and Moongen (s/w) traffic generators.

Hope you find that info useful, 
/Billy.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [multisite] Secgroup syncing Approach

[joehuang]

Hello team,

Last year, use case 4 was discussed, some network related requirements were 
identified: 
https://etherpad.opnfv.org/p/multisite_centralized_servic


  *   global view for tenant level IP address / mac address space management

  *   If a tenant has networks in multiple region, and these networks are 
routable (for example, connected with VPN), then, IP address may be duplicated. 
Need a global view for IP address space management

  *   If IP v4 used, this issue needs to be considered. For IPv6, it should not 
be a problem. IR - disagree with this statement. This requirement is important 
not just for prevention of duplicate address.

  *   For security and other reasons it's important to know which IP Addresses 
(IPv4 and IPv6) are used in which region.

  *   Can we also extend such requirement to MAC address tracking?

  *   Can we also extend such requirement to mapping for floating and public IP 
Addresses

  *   A service to clone security groups across regions

  *   No appropriate service to security groups across multiple region if the 
tenant has resources distributed, has to set the security groups in different 
region manually.

And during the discussion thread with netready, one more issue identified 
http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2016-July/011499.html:

  *VxLAN pool cross site management for VxLAN segmentation allocation

All these issues needs to be addressed, we can discuss them together.

Tricircle( now Tricircle team is working on the cleaning to make Tricircle 
dedicated for networking automation across Neutron, mentioned below) could be 
the reference, the design blueprint has just been updated for your reference: 
https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/,
 local network and shared VLAN network and L3 has been implemented in Newton 
release. Of course, in NFV area, L2 networking should be enough in most 
scenario.

And the spec for Tricircle Local Neutron Plugin is in review: 
https://review.openstack.org/#/c/368529/

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 09 September 2016 16:59
To: Ashish singh; opnfv-tech-discuss; caizhiyuan (A); Meimei; Sama, Malla 
Reddy; Zhipeng Huang; Dimitri Mazmanov; Ashish Singh7
Subject: RE: [opnfv-tech-discuss][multisite] Secgroup syncing Approach

Hello,  Ashish,

I think sync itself (if excluding the remote sec-group) is not complex, the 
complexity is to ensure the rules set in different region of Neutron will not 
conflict with each other. Otherwise, it'll become mess.

So I agree with you "We must use neutron to perform all our operations as with 
neutron we have total control over it." (Is my understanding correct?)

That's the way of Tricircle(please forgive me to explain a little: Tricircle 
now is only a project about networking automation across Neutron. And the 
Nova/Cinder API-Gateway part will be moved to Trio2o, a new created project: 
https://docs.google.com/presentation/d/1kpVo5rsL6p_rq9TvkuczjommJSsisDiKJiurbhaQg7E/edit),And
 the SEG sync has been implemented in the Tricircle, and we are now doing the 
tricircle splitting and cleaning.

If we implement seg sync in Kingbird, we have to write lots of duplicated code 
which has already done in Neutron, for example, SEG CRUD, rule CRUD, 
validation, rule checking, default rule management, etc.

Best Regards
Chaoyi Huang(joehuang)


From: Ashish singh [ashishsingh...@gmail.com]
Sent: 08 September 2016 23:57
To: opnfv-tech-discuss; caizhiyuan (A); Meimei; Sama, Malla Reddy; Zhipeng 
Huang; Ashish singh; Dimitri Mazmanov; joehuang; Ashish Singh7
Subject: [opnfv-tech-discuss][multisite] Secgroup syncing Approach

Hi All,

I have drafted a basic approach for security group synching in release D and it 
is as follows.

- Get list of secgroups  with rules for a tenant from all the regions which do 
not have remote group references(currently, we ignore remote secgroup 
references as there can be lot nested dependencies).
- Traverse each region and do the following
- Get the list of secgroup which are present in all the regions except 
the current region, These are the secgroups which we need to sync in current 
region: say it GRP_TO_BE_SYNCED
- There can be case where the secgroup from GRP_TO_BE_SYNCED may have 
the same rules as the secgroup in current region(If not initially but which 
will obviously happen after a sync job).
- Traverse through the GRP_TO_BE_SYNCED and check if there are such 
secgroups(rules overlapping groups), if there, ignore it. After this filtering, 
the remaining secgroup will be the final list of secgroup which should be 
created for the current region.
- Create the secgroup with the final list of secgroups in the region.
- Repeat the process for all the tenant in batches.
The default security group is not syned, as I feel 

Re: [opnfv-tech-discuss] [Doctor] Reset Server State and alarms in general

[Yujun Zhang]

After reading the whole message, I could not agree more on the conclusion,
IIUC, we should probably raise a deducted alarm in inspector instead of
requesting the controller to reset server state.

On Wed, Sep 21, 2016 at 2:51 PM Juvonen, Tomi (Nokia - FI/Espoo) <
tomi.juvo...@nokia.com> wrote:

> Hi,
>
> I had a lively discussion yesterday with OpenStack Nova cores about the
> reset server state. At first how to have that by one API call for all VMs
> on a host (hypervisor) as discussed in DOCTOR-78. But then it came to a
> question why we actually want the reset server state in the first place. It
> is not something that need to do if force down a host. If we want a
> notification about effected VMs and further an alarm, then that is another
> thing. So if we want that kind of notification, it is then something we
> should make a spec.
>

This sounds like a job of the inspector like vitrage, i.e. deduct a VM
error from host error and raise a deducted alarm.

Not to reset state to error for each VM on a host that we should not be
> doing in the first place if error was not on VM, but host level (yes before
> you ask, Nova can have the working VM state unchanged if host is down. You
> do not touch VM state if you do not want to do something for the VM or if
> it was actually the one having error. Yes and you do not want to do
> anything for the VM itself in all scenarios, but just be happy it comes up
> again on same host when host comes back.)
>

Agree


> Again I realize here and what I have said a long ago before we had
> anything. It will not be possible to make alarms correctly by changing
> state in Nova and other controllers and then triggering alarm from the
> notification about those state changes. That will never have what we want
> for the alarms, while otherwise we sure need to correct states. Even for
> things we get a notification triggered by state change, we will not have
> information needed in alarm and surely we do not call APIs in vain, just to
> have alarm (like reset server state) .
>
> We want tenant/VNFM specific alarms to tells which his VMs (virtual
> resources) are effected by fault and a cause (and surely alarms about
> physical faults that will not be consumed by tenant/VNFM and other fields
> needed by ETSI spec). Only way of having this correct for each kind of
> fault that can appear, is to form all the alarms (notification to form
> alarm) in the Inspector (Congress or Vitrage).
>

I have exactly the same understanding.

It is the only place that has all the information needed in different
> scenarios and can make this right and has the minimum delay that is crucial
> in Telco fault management. Also if looking to have OPNFV used in production
> and one would need to be OPNFV compliant, it means we need to make things
> right. I strongly suggest that while we have the way we make alarm as a
> great step we have achieved so far as proof of concept (changing states and
> having alarm under 1 second), let’s make next steps to go towards having
> conceptually correct way to achieve this and have correct alarms.
>
> Br,
> Tomi
>
>
>
> ___
> 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] [Doctor] Reset Server State and alarms in general

[Juvonen, Tomi (Nokia - FI/Espoo)]

Hi,

I had a lively discussion yesterday with OpenStack Nova cores about the reset 
server state. At first how to have that by one API call for all VMs on a host 
(hypervisor) as discussed in DOCTOR-78. But then it came to a question why we 
actually want the reset server state in the first place. It is not something 
that need to do if force down a host. If we want a notification about effected 
VMs and further an alarm, then that is another thing. So if we want that kind 
of notification, it is then something we should make a spec. Not to reset state 
to error for each VM on a host that we should not be doing in the first place 
if error was not on VM, but host level (yes before you ask, Nova can have the 
working VM state unchanged if host is down. You do not touch VM state if you do 
not want to do something for the VM or if it was actually the one having error. 
Yes and you do not want to do anything for the VM itself in all scenarios, but 
just be happy it comes up again on same host when host comes back.)

Again I realize here and what I have said a long ago before we had anything. It 
will not be possible to make alarms correctly by changing state in Nova and 
other controllers and then triggering alarm from the notification about those 
state changes. That will never have what we want for the alarms, while 
otherwise we sure need to correct states. Even for things we get a notification 
triggered by state change, we will not have information needed in alarm and 
surely we do not call APIs in vain, just to have alarm (like reset server 
state) .

We want tenant/VNFM  specific alarms to tells which his VMs (virtual resources) 
are effected by fault and a cause (and surely alarms about physical faults that 
will not be consumed by tenant/VNFM and other fields needed by ETSI spec). Only 
way of having this correct for each kind of fault that can appear, is to form 
all the alarms (notification to form alarm) in the Inspector (Congress or 
Vitrage). It is the only place that has all the information needed in different 
scenarios and can make this right and has the minimum delay that is crucial in 
Telco fault management. Also if looking to have OPNFV used in production and 
one would need to be OPNFV compliant, it means we need to make things right. I 
strongly suggest that while we have the way we make alarm as a great step we 
have achieved so far as proof of concept (changing states and having alarm 
under 1 second), let's make next steps to go towards having conceptually 
correct way to achieve this and have correct alarms.

Br,
Tomi



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

[opnfv-tech-discuss] [SFC] Nominating Manuel Buil as committer

[Brady Allen Johnson]

Hello,

I would like to nominate Manuel Buil as committer for the OPNFV SFC project.

Since OPNFV isnt really about commits, I wont bother listing his 
commits, although he has done alot of them for SFC in Fuel, Yardstick, 
ODL SFC, and Functest.


Manuel has been very active this release, and has achieved at least the 
following for OPNFV SFC:


1. Completed and fixed the Yardstick SFC test cases
2. Wrote new Functest SFC test cases
3. Created a cool, working SFC demo for the OPNFV summit in Berlin
4. Performed all of the troubleshooting and testing on the new Yi Yang
   OVS NSH patches for SFC
5. Created an even cooler SFC demo for the ODL summit in Seattle
 * You'll have to wait until the summit to see how this demo
   leverages NSH metadata


Can I please get a vote (-1, 0, +1) from the rest of the OPNFV SFC 
committers.


Want to meet him in person? He'll be at the ODL summit next week in 
Seattle demoing OPNFV SFC :)


Regards,

Brady


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