from:"Frank Brockners \(fbrockne\)"

Re: [opnfv-tech-discuss] [opnfv-tsc] Red-lined TSC Charter Document

2018-04-10 Thread Frank Brockners (fbrockne)

The discussion hints at a problem that the current proposal in the red-lined 
TSC charter doc has:
The charter refers to a wiki page that anyone with an LF account ID is free to 
edit (remember the early days, where we had folks “changing” the content of 
project proposals post the project approval..)

IMHO we should use the contents of the wiki 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure to create a pdf 
document which would then be posted on opnfv.org. The Charter should refer to 
that document instead of the wiki.
Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
 On Behalf Of Raymond Paik
Sent: Mittwoch, 4. April 2018 17:45
To: Julien 
Cc: opnfv-...@lists.opnfv.org; opnfv-tech-discuss 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] Red-lined TSC Charter Document

Good catch Julien.  I used "organization" as TSC members could come from 
research institutions, universities, etc. that are not (for profit) companies.

Thanks,

Ray

On Wed, Apr 4, 2018 at 7:04 AM, Julien 
mailto:julien...@gmail.com>> wrote:
Hi Ray,

"Cap per company:
·   Each organization can have a maximum of 2 TSC reps." in url: 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure

I would suggest using the same word for company and organization in this 
description, and maybe company here is better.


BR,
Julien

Raymond Paik 
mailto:rp...@linuxfoundation.org>>于2018年4月4日周三 
上午7:49写道：
Just update the wiki page incorporating Wenjing's feedback.  Take a look at the 
TSC Chair election section at 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure and let me know 
if there are other questions/feedback.

Thanks,

Ray

On Mon, Apr 2, 2018 at 1:50 PM, Raymond Paik 
mailto:rp...@linuxfoundation.org>> wrote:
Wenjing:

Good points.  Yes, I'll go ahead and update the wiki in the next few days.

Thanks,

Ray

On Mon, Apr 2, 2018 at 1:35 PM, Wenjing Chu 
mailto:wenjing@huawei.com>> wrote:
In the wiki page: 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure:

The TSC member election is scheduled on “mid-September” with flexibility, but 
the TSC chair wording is still hard-coded to September 7. I think that should 
be modified to be consistent – so that the newly elected TSC members choose the 
Chair, not the outgoing TSC.

If that is indeed the intent here, which I assume so, then we should revise the 
wiki text as soon as possible.

Another problem with the wiki section related to Chair election is its 
reference to the OPNFV By-Law
” (per section 5.5(b) of the OPNFV 
Bylaws)”.
That is no longer valid. We should refer to the OPNFV Technical Charter (or 
LFN’s) instead.

Regards
Wenjing



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Raymond Paik
Sent: Wednesday, March 28, 2018 4:12 PM
To: opnfv-tech-discuss 
mailto:opnfv-tech-discuss@lists.opnfv.org>>;
 opnfv-...@lists.opnfv.org
Subject: [opnfv-tech-discuss] Red-lined TSC Charter Document

All,

Please find attached red-lined TSC Charter document that reflects OPNFV's move 
to a merit-based TSC. The new text was heavily borrowed from OpenDaylight's 
Charter
 as they already migrated to a merit-based TSC.  The details on size, 
eligibility, election timing, etc. will be updated on the wiki if/when 
community decides to make any tweaks.

Please let me know if you have any questions/feedback.  The plan is to vote on 
this during the TSC meeting April 10th (after ~2 week review period).

Thanks,

Ray


___
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] [releng] Committer list per Releng repository

2017-12-11 Thread Frank Brockners (fbrockne)

Hi Fatih,

this was just a suggestion - mostly to keep Releng in line with what other 
projects do in OPNFV - the test-projects are probably the closest comparison 
here. 
I also don't think that there would not be much of a change: You'd have a 
Releng working group with several projects (those 5) participating, i.e. the 
structure would look much like what is done for testing.

Anyway - just do what the contributors and committers feel is best for Releng.

Cheers, Frank

-Original Message-
From: Fatih Degirmenci [mailto:fatih.degirme...@ericsson.com] 
Sent: Montag, 11. Dezember 2017 05:20
To: Frank Brockners (fbrockne) ; Trevor Bramwell 

Cc: Serena Feng ; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

Hi Frank,

Thanks for the feedback.

Splitting Releng is perhaps an option but I personally do not think it will add 
too much value. 
I believe support functions such as what Releng aims to provide is best handled 
as a whole rather than multiple individual projects.
This is important in order to ensure the project provides best service to the 
community and sub teams follow overall direction set by Infra WG in general and 
Releng Project in particular.

With that said, if any Releng committer comes up with a proposal to split 
Releng, resulting in multiple smaller projects, we can put these 2 proposals to 
vote and do accordingly.

Another thing I would like to highlight is that the proposed setup with 
subprojects/teams is pretty similar to how OpenStack Infra project works; top 
level Infra project and multiple sub teams that specialize in certain aspects 
of the infra. [1] We as project need to work on the details if this proposal is 
accepted and approved by the TSC. Until this happens, that link can give an 
idea regarding where we might end up. 

One last point is, Releng will probably not be the only one with this need. We 
are just the first one.

[1] https://docs.openstack.org/infra/system-config/project.html#teams

/Fatih

On 2017-12-11, 03:03, "Frank Brockners (fbrockne)"  wrote:

Hey folks,

Have we considered making these just 5 separate projects (which basically 
what they are)? That'd fit the OPNFV structure, gives each project a dedicated 
repo (which they have already), and a dedicated set of committers plus a PTO...

Frank

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Trevor Bramwell
Sent: Sonntag, 10. Dezember 2017 15:34
To: Fatih Degirmenci 
Cc: Serena Feng ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng 
repository

+1

Giving leaders of subproject the freedom to manage +2 rights on their own 
repository will be very helpful for ensuring patches are reviewed by those with 
the correct competencies and merged in a timely manner.

Perhaps having a 'mini-info' file in each repository would help track this, 
intead of expanding the current INFO file. Simple fields such as:
parent-project, project-name, creation-date, subproject-lead, committers, 
and parent-project-approval-link would work. This is merely a suggestion 
though, and a decision on this shouldn't block us from moving forward. I'm fine 
with things currently being added the INFO file.

Regards,
Trevor Bramwell

On Fri, Dec 08, 2017 at 12:01:34AM +, Fatih Degirmenci wrote:
> Hi Releng Committers,
> 
> During OPNFV Plugfest, we had conversations around having committer list 
per Releng repository/Gerrit Project.
> 
> The reason behind this is that, Releng project currently has 5 
> different repositories as listed below. [1]
> 
> 
>   *   releng
>   *   releng-anteater
>   *   releng-testresults
>   *   releng-utils
>   *   releng-xci
> 
> The work that is done in these repositories require different competence 
profiles. For example for releng repository, the committers need to have 
knowledge in CI, Jenkins, Jenkins Job Builder and so on.
> Apart from the required competence, some developers might not be 
interested in certain parts of Releng but interested in others.
> 
> Having single committer list across all Releng owned repositories 
prevents us from recognizing contributors and promoting them as committers for 
the corresponding repositories since they will perhaps never have enough 
contributions across all of them.
> Another limitation is that, the current review practices followed by 
Releng is not good and we need to improve this. Having right set of committers 
per repo and getting patches reviewed by them properly will help with the 
quality of work we are doing.
> 
> In order to address

Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

2017-12-10 Thread Frank Brockners (fbrockne)

Hey folks,

Have we considered making these just 5 separate projects (which basically what 
they are)? That'd fit the OPNFV structure, gives each project a dedicated repo 
(which they have already), and a dedicated set of committers plus a PTO...

Frank

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Trevor Bramwell
Sent: Sonntag, 10. Dezember 2017 15:34
To: Fatih Degirmenci 
Cc: Serena Feng ; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

+1

Giving leaders of subproject the freedom to manage +2 rights on their own 
repository will be very helpful for ensuring patches are reviewed by those with 
the correct competencies and merged in a timely manner.

Perhaps having a 'mini-info' file in each repository would help track this, 
intead of expanding the current INFO file. Simple fields such as:
parent-project, project-name, creation-date, subproject-lead, committers, and 
parent-project-approval-link would work. This is merely a suggestion though, 
and a decision on this shouldn't block us from moving forward. I'm fine with 
things currently being added the INFO file.

Regards,
Trevor Bramwell

On Fri, Dec 08, 2017 at 12:01:34AM +, Fatih Degirmenci wrote:
> Hi Releng Committers,
> 
> During OPNFV Plugfest, we had conversations around having committer list per 
> Releng repository/Gerrit Project.
> 
> The reason behind this is that, Releng project currently has 5 
> different repositories as listed below. [1]
> 
> 
>   *   releng
>   *   releng-anteater
>   *   releng-testresults
>   *   releng-utils
>   *   releng-xci
> 
> The work that is done in these repositories require different competence 
> profiles. For example for releng repository, the committers need to have 
> knowledge in CI, Jenkins, Jenkins Job Builder and so on.
> Apart from the required competence, some developers might not be interested 
> in certain parts of Releng but interested in others.
> 
> Having single committer list across all Releng owned repositories prevents us 
> from recognizing contributors and promoting them as committers for the 
> corresponding repositories since they will perhaps never have enough 
> contributions across all of them.
> Another limitation is that, the current review practices followed by Releng 
> is not good and we need to improve this. Having right set of committers per 
> repo and getting patches reviewed by them properly will help with the quality 
> of work we are doing.
> 
> In order to address this limitation and have the ability and the possibility 
> to recognize and promote developers who made great contributions to Releng in 
> general in the repositories they worked in, I propose to create committer 
> list per repo.
> 
> Please respond to this mail with +1 and -1 and share questions, comments, 
> concerns if you have any.
> 
> I plan to bring this topic to TSC on December 12th if the vote passes.
> 
> [1] https://gerrit.opnfv.org/gerrit/#/admin/projects/?filter=releng
> 
> /Fatih
___
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] urgent euphrates git tags vote needed

2017-09-26 Thread Frank Brockners (fbrockne)

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

Frank

From: Alec Hothan (ahothan)
Sent: Montag, 25. September 2017 21:34
To: opnfv-tech-discuss@lists.opnfv.org
Cc: David McBride ; Fatih Degirmenci 
; Frank Brockners (fbrockne) 
; Tallgren, Tapio (Nokia - FI/Espoo) 

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

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

Please reply with -1, 0 +1

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

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

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

Thank You.

  Alec

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

Re: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

2017-09-25 Thread Frank Brockners (fbrockne)

Ray,

while there are not a ton of river “Fenix” photos, there are some, e.g 
http://www.soberaniachile.cl/archivosdeimagenes/fenix.jpg and 
http://photo500x500.mnstatic.com/f11c1c363de24a0a5ad44bb39046e2da/rio-fenix-grande.jpg
 – there are wiki entries such as… 
https://es.wikipedia.org/wiki/Desv%C3%ADo_del_r%C3%ADo_F%C3%A9nix and 
https://es.wikipedia.org/wiki/R%C3%ADo_F%C3%A9nix_Grande

If you want better photos, do we have any friends in Argentina that fancy a 
trip to lago Buenos Aires? 
http://viento.com.ar/wp-content/uploads/2015/09/desvio-rio-fenix.jpg

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Montag, 25. September 2017 18:25
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

All:

Thanks for voting on the release naming poll.

First, for G-release the winner is Gambia (the first African river for OPNFV).

For the F-release, the top vote getter was Fenix in Argentina.  However, after 
some research it looks this is a tributary of another river 
(Deseado), and I wasn't able to 
find photos of Fenix River on the web (or even find it on Google Maps).

I talked to LF marketing colleagues as we've been using river images for 
release marketing, and they do have concerns about going with a river that is 
not well known.  The second choice was 
Fraser in Canada (the longest river 
in British Columbia) and I suggest going with Fraser as the F-release name.  
Although Fenix sounds cool, I think it's problematic if you can't find it on a 
map.

Let me know if you have any questions.

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] Proposal for LaaS Hardware

2017-08-16 Thread Frank Brockners (fbrockne)

True. A 2port 10GE NIC is ~500 $US. I've already updated the wiki :)

Thanks again, Frank

From: Bryan Sullivan [mailto:bls...@hotmail.com]
Sent: Mittwoch, 16. August 2017 15:36
To: Frank Brockners (fbrockne) ; Fatih Degirmenci 
; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [infra] Proposal for LaaS Hardware

Re budget I don't think 2 or 4 NICs will have much impact given the type of 
servers we are talking about here (datacenter, production-grade servers). Most 
I have seen come with 4 NICs onboard and often dedicated IPMI.

Thanks,
Bryan Sullivan
____
From: Frank Brockners (fbrockne) mailto:fbroc...@cisco.com>>
Sent: Wednesday, August 16, 2017 3:36 AM
To: Bryan Sullivan; Fatih Degirmenci; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: RE: [infra] Proposal for LaaS Hardware

Bryan,

Thanks for raising an important point. IMHO 2 NICs are the minimal setup. This 
allows for performance focused setups (i.e. traffic enters on one NIC and 
leaves on another NIC), and it also allows for setups where you use the NICs 
for different purposes (e.g. dedicate a NIC to the kernel, and another one to 
VPP).

We can of course handle all three "types" of networks (admin, public, 
tenant/private) using VLAN/VLAN-ranges - but for some deployments a physical 
decoupling might ease things.

Per your suggestion: In order to allow for better flexibility, let's plan with 
3 NICs for now. We can always scale back in case there are budget constraints.

Lights-out-management is something that is often vendor specific - and it may, 
or may not require a dedicated port (IPMI 2.0 even runs over VLANs) - but as 
part of the requirements list, we should spell out that lights-out-management 
is something we absolutely require. I'll update the wiki accordingly.

Thanks, Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bryan Sullivan
Sent: Dienstag, 15. August 2017 22:58
To: Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Fatih,

Do "2 x 10 Gbps NICs" suffice for Pharos POD servers? I thought the NIC 
requirements were more substantial. IMO we should require at least IPMI + 3 
NICs (Admin/PXE, Private, Public).

The lab we are building as described at 
https://wiki.opnfv.org/display/joid/MAAS+as+Lab+Admin+Server will be designed 
that way. Our vision for how we will use this lab (initially, for internal 
development/CI activities only) is very similar to your vision for LaaS dynamic 
assignment of server resources. We plan to use MAAS, Ansible, and Jenkins to 
manage the admin and distribution of development/CI/etc activities across these 
servers.

Thanks,
Bryan Sullivan

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>

mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>
Sent: Tuesday, August 15, 2017 1:02 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Hi,

Please see the proposal regarding the number of servers and hardware specs for 
LaaS from the links below.

*   Number of x86 and ARM servers: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaS-NumberofServers
*   Definition of hardware for x86 and ARM: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaSHardware

Please share your thoughts, comments and questions either by replying to this 
mail, directly on Wiki page, or by joining the Infra WG Meeting on August 21st 
where this topic will be discussed.

/Fatih

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

Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

2017-08-16 Thread Frank Brockners (fbrockne)

Bryan,

Thanks for raising an important point. IMHO 2 NICs are the minimal setup. This 
allows for performance focused setups (i.e. traffic enters on one NIC and 
leaves on another NIC), and it also allows for setups where you use the NICs 
for different purposes (e.g. dedicate a NIC to the kernel, and another one to 
VPP).

We can of course handle all three "types" of networks (admin, public, 
tenant/private) using VLAN/VLAN-ranges - but for some deployments a physical 
decoupling might ease things.

Per your suggestion: In order to allow for better flexibility, let's plan with 
3 NICs for now. We can always scale back in case there are budget constraints.

Lights-out-management is something that is often vendor specific - and it may, 
or may not require a dedicated port (IPMI 2.0 even runs over VLANs) - but as 
part of the requirements list, we should spell out that lights-out-management 
is something we absolutely require. I'll update the wiki accordingly.

Thanks, Frank



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bryan Sullivan
Sent: Dienstag, 15. August 2017 22:58
To: Fatih Degirmenci ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Fatih,

Do "2 x 10 Gbps NICs" suffice for Pharos POD servers? I thought the NIC 
requirements were more substantial. IMO we should require at least IPMI + 3 
NICs (Admin/PXE, Private, Public).

The lab we are building as described at 
https://wiki.opnfv.org/display/joid/MAAS+as+Lab+Admin+Server will be designed 
that way. Our vision for how we will use this lab (initially, for internal 
development/CI activities only) is very similar to your vision for LaaS dynamic 
assignment of server resources. We plan to use MAAS, Ansible, and Jenkins to 
manage the admin and distribution of development/CI/etc activities across these 
servers.

Thanks,
Bryan Sullivan

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>
Sent: Tuesday, August 15, 2017 1:02 PM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Hi,

Please see the proposal regarding the number of servers and hardware specs for 
LaaS from the links below.

*   Number of x86 and ARM servers: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaS-NumberofServers
*   Definition of hardware for x86 and ARM: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaSHardware

Please share your thoughts, comments and questions either by replying to this 
mail, directly on Wiki page, or by joining the Infra WG Meeting on August 21st 
where this topic will be discussed.

/Fatih

___
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] [OPNFV] ODL target Release for Euphrates

2017-08-08 Thread Frank Brockners (fbrockne)

Hi Cédric,

is there a way to have a per-scenario functest config file? We could have a 
default file, which we’d modify on a case by case basis. Note that e.g. only a 
subset of the scenarios use NetVirt, hence having Netvirt as a default 
testsuite probably won’t make sense.

Thanks, Frank

From: cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com]
Sent: Dienstag, 8. August 2017 11:17
To: Frank Brockners (fbrockne) ; RICHOMME Morgan IMT/OLN 
; Tim Rozet ; 
narinder.gu...@canonical.com; 'Michal Skalski' ; Chigang 
(Justin) ; hu.zhiji...@zte.com.cn; David McBride 
; Georg Kunz ; Tim 
Irnich ; Manuel Buil ; 
Michael Polenchuk ; HE Ruan IMT/OLS 
; Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at 
Cisco) ; Feng Pan ; Michal Cmarada -X 
(mcmarada - PANTHEON TECHNOLOGIES at Cisco) 
Cc: wangwulin ; opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [OPNFV] ODL target Release for Euphrates

Hello,

I understand your point but Functest requires a default answer to finish the 
containers and to write the testcase config file (suites and dependencies on 
scenarii or installers).
Then we take the decision about the release (the last one seems fine) and if 
the NetVirt test suite is ran by default before the possible harmonization.
I would have thought it was an upper decision as for OpenStack.

Cédric

De : Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Envoyé : mardi 8 août 2017 10:10
À : RICHOMME Morgan IMT/OLN; Tim Rozet; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal 
Skalski'; Chigang (Justin); 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride; Georg 
Kunz; Tim Irnich; Manuel Buil; Michael Polenchuk; HE Ruan IMT/OLS; Juraj Linkes 
-X (jlinkes - PANTHEON TECHNOLOGIES at Cisco); Feng Pan; Michal Cmarada -X 
(mcmarada - PANTHEON TECHNOLOGIES at Cisco)
Cc : OLLIVIER Cédric IMT/OLN; wangwulin; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Objet : RE: [OPNFV] ODL target Release for Euphrates

Hi Morgan,

it might well be that there is no one answer to your question – especially for 
those scenarios which are leading edge and actively drive development upstream 
(i.e. in ODL and HoneyComb). In addition, given the sister relationship between 
ODL and Honeycomb, model updates go hand in hand – which drive another version 
dependency.
For FDS, we plan for an effort similar to what we’ve done for Danube: Once 
we’re getting closer to the E-release, we’ll try to harmonize on a single 
version of ODL, i.e. we’ll try to harmonize on a pre-release version of 
Nitrogen – but for the time being, you’ll find different scenarios using 
different versions of ODL (sometimes even dedicated builds, e.g. as used for 
the GBP-Netvirt PoC or for the fdio-dvr scenario), also due to the fact that 
Karaf-4 migration isn’t yet done for all the components.

Regards, Frank

From: morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> 
[mailto:morgan.richo...@orange.com]
Sent: Dienstag, 8. August 2017 09:18
To: Tim Rozet mailto:tro...@redhat.com>>; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal 
Skalski' mailto:mskal...@mirantis.com>>; Chigang 
(Justin) mailto:chig...@huawei.com>>; 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride 
mailto:dmcbr...@linuxfoundation.org>>; Georg Kunz 
mailto:georg.k...@ericsson.com>>; Frank Brockners 
(fbrockne) mailto:fbroc...@cisco.com>>; Tim Irnich 
mailto:tim.irn...@ericsson.com>>; Manuel Buil 
mailto:manuel.b...@ericsson.com>>; Michael Polenchuk 
mailto:mpolenc...@mirantis.com>>; HE Ruan IMT/OLPS 
mailto:ruan...@orange.com>>; Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>>
Cc: OLLIVIER Cédric IMT/OLN 
mailto:cedric.olliv...@orange.com>>; wangwulin 
mailto:wangwu...@huawei.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [OPNFV] ODL target Release for Euphrates

Hi,

I did not find the list of the target versions for the main components 
integrated in Euphrates version.
it would make sense to explicitely reference them on one of the wiki pages 
dedicated to the release https://wiki.opnfv.org/display/SWREL/Euphrates

In functest, we need to know it.
Cedric consolidated Functest in order to manage properly the upstream 
dependencies (including clients/tooling/lib needed for testing relatively to 
upstream components) and introduced a clean packetization, which is key for an 
integration project.

At the moment, the only ODL version reference we found was beryllium-sr4, which 
is pretty old.

According to https://wiki.opnfv.org/display/SWREL/Euphrates+Scenario+Status
scenario owners dealing with ODL are:
- Frank (Apex ∩ Fdio)
- Tim Inrich (Apex ∩ bgpvpn)
- Brady (not sure the page is up to date) / Manuel (Apex ∩ Sfc)
- Georg (not sure it is up to dat

Re: [opnfv-tech-discuss] [OPNFV] ODL target Release for Euphrates

2017-08-08 Thread Frank Brockners (fbrockne)

Hi Morgan,

it might well be that there is no one answer to your question – especially for 
those scenarios which are leading edge and actively drive development upstream 
(i.e. in ODL and HoneyComb). In addition, given the sister relationship between 
ODL and Honeycomb, model updates go hand in hand – which drive another version 
dependency.
For FDS, we plan for an effort similar to what we’ve done for Danube: Once 
we’re getting closer to the E-release, we’ll try to harmonize on a single 
version of ODL, i.e. we’ll try to harmonize on a pre-release version of 
Nitrogen – but for the time being, you’ll find different scenarios using 
different versions of ODL (sometimes even dedicated builds, e.g. as used for 
the GBP-Netvirt PoC or for the fdio-dvr scenario), also due to the fact that 
Karaf-4 migration isn’t yet done for all the components.

Regards, Frank

From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com]
Sent: Dienstag, 8. August 2017 09:18
To: Tim Rozet ; narinder.gu...@canonical.com; 'Michal 
Skalski' ; Chigang (Justin) ; 
hu.zhiji...@zte.com.cn; David McBride ; Georg 
Kunz ; Frank Brockners (fbrockne) 
; Tim Irnich ; Manuel Buil 
; Michael Polenchuk ; HE 
Ruan IMT/OLPS ; Frank Brockners (fbrockne) 

Cc: OLLIVIER Cédric IMT/OLN ; wangwulin 
; opnfv-tech-discuss@lists.opnfv.org
Subject: [OPNFV] ODL target Release for Euphrates

Hi,

I did not find the list of the target versions for the main components 
integrated in Euphrates version.
it would make sense to explicitely reference them on one of the wiki pages 
dedicated to the release https://wiki.opnfv.org/display/SWREL/Euphrates

In functest, we need to know it.
Cedric consolidated Functest in order to manage properly the upstream 
dependencies (including clients/tooling/lib needed for testing relatively to 
upstream components) and introduced a clean packetization, which is key for an 
integration project.

At the moment, the only ODL version reference we found was beryllium-sr4, which 
is pretty old.

According to https://wiki.opnfv.org/display/SWREL/Euphrates+Scenario+Status
scenario owners dealing with ODL are:
- Frank (Apex ∩ Fdio)
- Tim Inrich (Apex ∩ bgpvpn)
- Brady (not sure the page is up to date) / Manuel (Apex ∩ Sfc)
- Georg (not sure it is up to date) Apex ∩ gluon
- Tim Rozet (Other Apex scenarios)
- Ruan He (Compass ∩ moon)
- Justin (Other Compass scenarios)
- Zhiang (Daisy ∩ moon)
- Michael (Fuel/MCP)

could you confirm the target version for ODL?


/Morgan

note: no scenario ODL with joid referenced in the page.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [opnfv-tech-discuss] uploading UI code to OPNFV

2017-07-27 Thread Frank Brockners (fbrockne)

Koren,

did you check out https://wiki.opnfv.org/pages/viewpage.action?pageId=10294496 
already?

Frank

From: Koren Lev (korlev)
Sent: Donnerstag, 27. Juli 2017 16:17
To: David McBride ; TECH-DISCUSS OPNFV 
; opnfv-project-leads 

Cc: Raymond Paik ; 
opnfv-helpd...@rt.linuxfoundation.org; Frank Brockners (fbrockne) 
; Yaron Yogev (yayogev) ; Eyal Lapid -T 
(elapid - AMAN COMPUTERS LTD at Cisco) 
Subject: uploading UI code to OPNFV

Hi,

Calipso project includes a UI module, it needs several media files (.jpg .png 
.ico etc) uploaded too (not too big, mostly for css stuff).
Currently Jenkins rejects those (example): “ERROR - Non Whitelisted Binary 
file: /home/opnfv/anteater/calipso/ui/public/cisco-favicon.ico”

How can we request an exception for those types and how long this will take 
please ?
attaching all as we have a MS5 to complete.

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

Re: [opnfv-tech-discuss] [release][announce] RESPONSE REQUIRED / proposed change to release date for Danube 3.0

2017-06-29 Thread Frank Brockners (fbrockne)

+1

Frank

Am 28.06.2017 um 11:12 schrieb David McBride 
mailto:dmcbr...@linuxfoundation.org>>:

TSC,

After examining status and considering various alternatives, Ray and I have 
agreed to propose July 14 as the new release date for Danube 3.  We believe 
that this will give project and installer teams time to overcome current 
issues, as well as allowing us to avoid the 4th of July holiday in the U.S., 
when many community members will be away on vacation.

Assuming that the TSC approves this change, then I would suggest the following 
schedule:

  *   July 12 - complete testing
  *   July 13 - finish document updates / update JIRA
  *   July 14 - tag repos and release
  *   Week of July 17 - download page goes live

TSC members, please respond to this email with your vote on the following by 
EOD PT June 30:

Does the TSC approve moving the Danube 3.0 release date to July 14th? (+1, 0, 
-1)

David

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

Re: [opnfv-tech-discuss] [opnfv-tsc] New meeting time for the TSC call

2017-06-22 Thread Frank Brockners (fbrockne)


+1 for the move to 6am PT
+1 for canceling the call on Jul/4th – unless we have a pressing item on the 
agenda (i.e. this assumes that we have D3.0 released by then – otherwise we 
might want to consider keeping the call).

Frank

From: opnfv-tsc-boun...@lists.opnfv.org 
[mailto:opnfv-tsc-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Mittwoch, 21. Juni 2017 07:03
To: opnfv-tech-discuss@lists.opnfv.org; opnfv-...@lists.opnfv.org
Subject: [opnfv-tsc] New meeting time for the TSC call

All,

As discussed on the TSC call today, I'd like to propose changing the TSC 
meeting time to 6am Pacific Time.  This would make it slightly easier for 
community members in Asia to join the weekly call.  Obviously, an earlier start 
will make things a little painful for people in Pacific Timezone (myself 
included).  However, there were no objections from west coasters when I asked 
people a few months ago.

This change won't take effect right away, but we could start in mid-July.  I 
need to thank the Doctor team for agreeing to move their weekly meeting to make 
this possible.   If you have any major concerns/objections about the proposed 
change, please let me know by the end of this week (23rd).

Speaking of July, the first Tuesday in July is the Independence Day holiday in 
the US and many folks here in the US will be on Holiday that week.  Is everyone 
OK with canceling the TSC call in the first week of July?

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] TSC vote requested for security fix

2017-06-21 Thread Frank Brockners (fbrockne)

Ok for me as long as we’re *not* affecting our LF Pharos PODs.

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Mittwoch, 21. Juni 2017 00:08
To: opnfv-...@lists.opnfv.org
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] TSC vote requested for security fix

OPNFV TSC Members:

Sorry for the short notice, but earlier today the Linux Foundation IT team has 
been made aware of a high priority security issue (see 
https://access.redhat.com/security/vulnerabilities/stackguard) and need to 
apply package errata and perform systems reboot as soon as possible.  We 
tentatively scheduled 1-hour window on June 24th @01:00 - 02:00 UTC for this 
work, but if the TSC agrees, we'd like fix this sooner.

I realize the timing is not ideal as people are working on Danube 3.0, but two 
options I'd like to propose are 22:00 - 23:00 UTC on June 21st or June 22nd.

Could I ask the TSC members to send your votes on the following as soon as 
possible?

  *   Do you approve an earlier security fix window? (Y/N)
  *   If you answered Y above, are you OK with June 21st, June 22nd, or are you 
OK with either?
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] Vote for the new Danube 3.0 release date

2017-06-08 Thread Frank Brockners (fbrockne)

+1

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci
Sent: Donnerstag, 8. Juni 2017 08:24
To: Raymond Paik 
Cc: opnfv-...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Vote for the new Danube 3.0 release date

+1

/Fatih

On 8 Jun 2017, at 03:04, Raymond Paik 
mailto:rp...@linuxfoundation.org>> wrote:
TSC members,

Apologies for a little delay on this.

As David 
communicated 
yesterday, he is recommending postponing the Danube 3.0 release date to June 
23rd (2-week delay) as community members experienced technical issues over the 
weekend.

I'd like to start an email vote among the TSC members on the following:

"Does the TSC approve changing the Danube 3.0 release date to June 23, 2017?  
(+1, 0, -1)"

Could you send me your vote by 6pm Pacific Time on June 8th (Thursday)?

Thanks,

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

Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - Milestone 2 - test case documentation - May 22

2017-05-19 Thread Frank Brockners (fbrockne)

David,

http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases/fds
http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases/fds_stack_integrity
http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases/fds_dvr
http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases/fds_odl_split_rejoin
http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases/fds_odl_stress


Frank

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Freitag, 19. Mai 2017 19:14
To: Frank Brockners (fbrockne) 
Cc: TECH-DISCUSS OPNFV ; 
opnfv-project-leads ; Juraj Linkes -X 
(jlinkes - PANTHEON TECHNOLOGIES at Cisco) 
Subject: Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - 
Milestone 2 - test case documentation - May 22

Frank,

Please add the test cases that you have to the DB and send me the link.  The 
milestone does not preclude you from modifying/adding test cases later.  Thanks.

David

On Thu, May 18, 2017 at 11:48 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
David,

for FDS, we’ve so far just noted the test-cases with “pen and paper”: 
https://wiki.opnfv.org/display/fds/FDS+Testing+Euphrates
Once things are a bit more settled, we’ll also add them to the Database.

Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of David McBride
Sent: Donnerstag, 18. Mai 2017 20:27
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>;
 opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - 
Milestone 2 - test case documentation - May 22

REMINDER - MS2 is on Monday, May 22.  I've only heard from a few projects, so 
far. Please send me the link to your test cases in the test case database.  See 
the links in my previous mail for links to instructions and an example.

On Mon, May 15, 2017 at 11:00 AM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
OPNFV Feature Project Owners,

Test case documentation (MS2) is due in 1 week (May 
22).<https://wiki.opnfv.org/download/attachments/8689511/OPNFV%20Release%20%2522Euphrates%2522%20r5.pdf?version=1&modificationDate=1491949074000&api=v2>
  Please register your project with functest and document your test cases in 
the test case database, as described 
here<https://wiki.opnfv.org/pages/viewpage.action?pageId=6825128>.

In order to verify compliance, please respond to this email with a link to your 
test case documentation (e.g., for 
FDS<http://testresults.opnfv.org/test/api/v1/projects/fastdatastacks/cases>).  
Note:  please send the link even if you are not changing your test cases from 
the previous release.

David

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



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



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

Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - Milestone 2 - test case documentation - May 22

2017-05-18 Thread Frank Brockners (fbrockne)

David,

for FDS, we’ve so far just noted the test-cases with “pen and paper”: 
https://wiki.opnfv.org/display/fds/FDS+Testing+Euphrates
Once things are a bit more settled, we’ll also add them to the Database.

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Donnerstag, 18. Mai 2017 20:27
To: TECH-DISCUSS OPNFV ; 
opnfv-project-leads 
Subject: Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - 
Milestone 2 - test case documentation - May 22

REMINDER - MS2 is on Monday, May 22.  I've only heard from a few projects, so 
far. Please send me the link to your test cases in the test case database.  See 
the links in my previous mail for links to instructions and an example.

On Mon, May 15, 2017 at 11:00 AM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
OPNFV Feature Project Owners,

Test case documentation (MS2) is due in 1 week (May 
22).
  Please register your project with functest and document your test cases in 
the test case database, as described 
here.

In order to verify compliance, please respond to this email with a link to your 
test case documentation (e.g., for 
FDS).  
Note:  please send the link even if you are not changing your test cases from 
the previous release.

David

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



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

Re: [opnfv-tech-discuss] [release][danube] Danube 3.0 - June 8

2017-05-16 Thread Frank Brockners (fbrockne)

Thanks David.

A minor points: Below you probably refer to D3.0. In addition, did we move the 
release date to June/9 now (instead of June/8 as listed on 
https://wiki.opnfv.org/display/SWREL/Danube?preview=/6827418/8689182/OPNFV%20Release%20%2522Danube%2522%20r4.pdf)

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 15. Mai 2017 20:29
To: TECH-DISCUSS OPNFV ; 
opnfv-project-leads 
Subject: [opnfv-tech-discuss] [release][danube] Danube 3.0 - June 8

Team,

Our final release for OPNFV Danube is just 3 1/2 weeks away.  We will start 
daily meetings for this release beginning May 29.

Scenario owners - please take a moment and make sure that the 
"intent-to-release" column on the scenario status 
page is up to date 
for your scenario.

The schedule for the D2.0 release is as follows:

  *   June 6 - complete formal testing
  *   June 7 - complete documentation / JIRA cleanup
  *   June 9 - tag projects / release
David

--
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] New project proposal: NFVbench

2017-04-17 Thread Frank Brockners (fbrockne)

Hi Trevor,

fully agreed. Let's discuss this in the proposal review during the technical 
meeting on Thursday.
Are you coming to the hackfest next week?

Thanks, Frank

From: Cooper, Trevor [mailto:trevor.coo...@intel.com]
Sent: Montag, 17. April 2017 08:22
To: Frank Brockners (fbrockne) ; TSC OPNFV 
; TECH-DISCUSS OPNFV 

Cc: Carsten Rossenhoevel ; Alec Hothan (ahothan) 

Subject: RE: New project proposal: NFVbench

Hi Frank

I think that your proposal aligns with some of the stress testing concepts that 
we have been developing in the Testing Working Group. Re. While VSPERF does not 
utilize the full stack (with Open Stack), the test cases can provide a baseline 
for any NFVI data-plane suite ... i.e. Throughput Tests, Packet and Frame Delay 
Tests, Stream Performance Tests, Request/Response Performance Tests, Packet 
Delay Tests, Scalability Tests, Control Path and Datapath Coupling Tests, CPU 
and Memory Consumption Tests, Time to Establish Flows Tests, Noisy Neighbor 
Tests. We should try to maintain consistency of methods/metrics form component 
level tests to system level where possible. It will be good to discuss this 
further.

/Trevor

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Wednesday, April 12, 2017 9:40 AM
To: TSC OPNFV mailto:opnfv-...@lists.opnfv.org>>; 
TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Cc: Carsten Rossenhoevel mailto:cr...@eantc.de>>; Alec Hothan 
(ahothan) mailto:ahot...@cisco.com>>
Subject: [opnfv-tech-discuss] New project proposal: NFVbench

Hi OPNFV,

over the past few weeks we've distilled a proposals to create a toolkit to 
allow for black-box performance testing of NFVI with a network focus:
NFVbench: https://wiki.opnfv.org/display/nfvbench/NFVbench+Project+Proposal

The NFVbench project is to develop a toolkit that allows developers, 
integrators, testers and customers to measure and assess the L2/L3 forwarding 
performance of an NFV-infrastructure solution stack (i.e. OPNFV scenario) using 
a black-box approach.

We're hoping for a discussion in the technical community meeting on April/20, 
and are also asking for an official TSC review post the technical community 
review on May/2, so that NFVbench can participate in Euphrates. Consequently, 
NFVbench asks for tentative inclusion into Euphrates.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank, Carsten, Alec


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

[opnfv-tech-discuss] New project proposal: NFVbench

2017-04-12 Thread Frank Brockners (fbrockne)

Hi OPNFV,

over the past few weeks we've distilled a proposals to create a toolkit to 
allow for black-box performance testing of NFVI with a network focus:
NFVbench: https://wiki.opnfv.org/display/nfvbench/NFVbench+Project+Proposal

The NFVbench project is to develop a toolkit that allows developers, 
integrators, testers and customers to measure and assess the L2/L3 forwarding 
performance of an NFV-infrastructure solution stack (i.e. OPNFV scenario) using 
a black-box approach.

We're hoping for a discussion in the technical community meeting on April/20, 
and are also asking for an official TSC review post the technical community 
review on May/2, so that NFVbench can participate in Euphrates. Consequently, 
NFVbench asks for tentative inclusion into Euphrates.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank, Carsten, Alec


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

Re: [opnfv-tech-discuss] [release][danube] MS6 compliance assessment

2017-02-27 Thread Frank Brockners (fbrockne)

David,

for FDS, please see inline...

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Mittwoch, 22. Februar 2017 21:30
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

Subject: [opnfv-tech-discuss] [release][danube] MS6 compliance assessment

Team,

I'd like to request that the PTLs for projects participating in Danube respond 
to the following questions, designed to assess compliance with MS6.

...FB: FDS does feature development (upstream), system integration and test – 
hence is a bit hard to fit into the below categories. Still, please find 
answers inline where they “kind of” fit.
Feature Projects
1. Please provide a list of commits for the following:
a. Enabling testing for your project in the Functest repo (or other test 
framework repo if you are not using functest)
b. Test case implementation in your project repo.
...FB: Tests were directly added to FuncTest for security groups testing: 
https://gerrit.opnfv.org/gerrit/#/c/28883/
2. Please indicate whether the scenarios with which your project is 
integrated are visible on the Functest dashboard.  If not, why?
...FB: The above patch isn’t merged yet.
Test Framework Projects
1. Please provide a list of commits for your self-validation tests.
Preliminary Documentation Requirement
1. Please provide a link to the preliminary documentation for your project.
...FB: See
https://git.opnfv.org/fds/tree/docs/scenarios/os-odl_l2-fdio-ha
https://git.opnfv.org/fds/tree/docs/scenarios/os-odl_l3-fdio-noha

Let me know if you have any questions.

David

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

Re: [opnfv-tech-discuss] [release] E-release schedule

2017-02-22 Thread Frank Brockners (fbrockne)

That makes sense.  The whole point of micro-releases would be to release 
scenarios once they are ready - and it falls into the responsibility of a 
scenario owner to shepherd the process. Micro-releases should *not* be a 
vehicle to push other teams to go out of their way.

Frank

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Mittwoch, 22. Februar 2017 15:53
To: Ulrich Kleber 
Cc: Randy Levensalor ; Frank Brockners (fbrockne) 
; David McBride ; 
TECH-DISCUSS OPNFV ; 
opnfv-project-le...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [release] E-release schedule

I think having maintenance releases makes sense.  From an installer 
perspective, if folks want to add a new scenario for a maintenance release then 
they need to carry most of the weight of integrating it.  It is hard for a 
small team like Apex to juggle adding features for a previous release while 
rushing to get the next version of OS to work for the following release.  Bug 
fixing and documentation updates I think we are fine with for maintenance 
releases.

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Ulrich Kleber" 
To: "Randy Levensalor" , "Frank Brockners 
(fbrockne)" , "David McBride" 
, "TECH-DISCUSS OPNFV" 
, opnfv-project-le...@lists.opnfv.org
Sent: Wednesday, February 22, 2017 8:00:09 AM
Subject: Re: [opnfv-tech-discuss] [release] E-release schedule



Hi, 

what Randy explains would mean that we should move to a very strict concept of 
maintenance releases. 

That would mean we carry through our milestones properly to get the 1.0 release 
out. After that we should only do bug fixing. Not a single feature. 

If we do that, 2.0 and 3.0 will not take big efforts, but each provide better 
stability. It shouldn’t even be a problem to do 4.0 if there are urgent fixes. 

But we should be strict then: Every feature that misses the 1.0, has to wait 
for the next major release. 

Just my 2 cents. 

Cheers, 

Uli 






From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Randy 
Levensalor
Sent: Friday, 17 February, 2017 00:16
To: Frank Brockners (fbrockne); David McBride; TECH-DISCUSS OPNFV; 
opnfv-project-le...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [release] E-release schedule 




Frank, +1 on your suggestions. 

David, I applaud your effort to reduce the overhead for the community. 



TL;DR Today I spend > 80% of my time getting OPNFV to run and I’d prefer to 
spend > 80% of my time running VNFs on OPNFV. 



As a frequent user, use case 1 that Frank defined aligns with my primary goal 
for OPNFV. “(1) User/consumer of a readily integrated NFV stack.” The need for 
a working platform currently outweigh the need for additional features. I 
suspect that as the platform and our use cases mature, some of the incremental 
features will become a higher priority. 



With the one release every 6 months, I fear that I would have to carry a large 
patch set or something to have a functioning platform. 



To add a little context to my reservations about the reduced number of 
releases, I’d like to share my experience below as an example of how the 
release cycle can impact users. Please don’t read this as a complaint or 
detracting from the project’s progress and achievement. The fact that we can 
run a 100% open source VIM and NFVI with a very limited staff is a minor 
miracle. There may some other clever solutions. Fatih and Jack have mentions 
some options that could help. 



With the Arno, Brahmaputra and Colorado releases we would start downloading 
release candidates and kick the tires. We try and look at multiple installers, 
but most of our time has been spent on Apex. 



The RC installs almost never work. About 1/3 rd of these failures are due to 
hardware or user error that are not easy to debug. For instance, a bad NIC on a 
compute node can cause the controller install to fail. The rest are defects or 
documentation issues. 



The1.0 release goes better. I can usually get a few patches into the first 
release to resolve critical issue and the community is working day and night to 
get the release out the door. 



By the 2.0 release, most of the defects are fixed. There are inevitably a few 
issues that take more than a month to root cause. Some of these more 
challenging defects, which are often related to platform stability, cannot be 
fixed until the next release. Resources are already focused on adding new 
features and do not have the time nor desire to backport these fixes. 



The longest that I have kept an OPNFV Colorado instance running was 32 days. 
That required the Colorado 3.0 release, manually applying a few patches that 
will be in Danube and limiting the type activities. 



Now we are preparing to kick the tires on Danube continue with difficulties 
keeping our lab running long enough to deploy an interesting use case. In the 
meant

Re: [opnfv-tech-discuss] [release] E-release schedule

2017-02-16 Thread Frank Brockners (fbrockne)

David,

thanks for the summary. Let’s remind ourselves, that in OPNFV we’re really 
trying to meet the needs of two different audiences: (1) User/consumer of a 
readily integrated NFV stack – as well as marketing operations (2) 
Developer/tester of an NFV stack. Audience #1 is mostly interested in 
stability, even if that means that things are released a little later (i.e. you 
build on long released components). Audience #2 is pushing the envelope and 
requires the ability to evolve/develop and integrate the latest set of 
components; once working they desire to release things to allow others to build 
on top; and move on/start over.

The current 1.0/2.0/3.0 was an effort to meet the needs of both audiences, i.e.

·   Have a “major” release.

·   Allow developers to release scenarios when they are ready and evolve, 
without too much of a maintenance burden.
This is also why we typically did not fix component versions for a release, but 
said: Based or ODL Boron or later.

I agree that releases are not free – especially the “major” release, because it 
comes with significant documentation and coordination needs. That said, it is 
mostly the “major” release with a lot of central coordination which creates 
efforts. Labeling and pushing an updated version of test results and 
documentation is relatively low effort – and can even be done by a scenario 
team. It does not even require central coordination. And our pipeline is now 
mature enough to do these things with low/moderate overhead.

So rather than move back in history and go back to a single release every 6 
months, which will make OPNFV a very inflexible organization for developers, I 
would strongly suggest that we rather consider evolving the current release 
process. IMHO we should be ready to have monthly micro-releases (scenario 
owners publish those scenarios which are “ready”, i.e. have docs ready and pass 
testing), and every 6 months we do a macro-release (with marketing/press 
announcement) which includes the set of scenarios which are “ready” by then. 
Macro-releases can be coupled to certain upstream component versions (as 
selection criteria for what is in/out of a macro release) – whereas 
micro-release would enjoy complete freedom.

Thoughts?

Thanks, Frank



From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Mittwoch, 15. Februar 2017 20:26
To: TECH-DISCUSS OPNFV ; 
opnfv-project-le...@lists.opnfv.org
Cc: Frank Brockners (fbrockne) ; Tapio Tallgren 

Subject: [release] E-release schedule

Greetings,

During the TSC call, yesterday, I took an action to start an email discussion 
about the schedule for the 
E-release<https://wiki.opnfv.org/display/SWREL/E-River>.

Specifically, I suggested that we just plan for a single release, rather than 
three releases, as we've done in the past.  Then, when the release date 
approaches, we evaluate whether we need a point release, then schedule it at 
that time.

Why?

  *   Scheduling three releases has created a lot of confusion with the project 
teams  The purpose of the three releases is to give project teams time to debug 
and fix scenarios that are not ready for 1.0.  They are not separate 
development timelines with separate release milestones.  However, many believe 
that it isn't necessary to meet release milestones, because they will simply 
shift to the 2.0 or 3.0 release.
  *   In the past two releases, the new content released in 2.0 has been 
minimal.  For example, for Colorado 2.0, just two new scenarios were released.  
Human nature is such that, given the opportunity for a later deadline, many 
will take it.
  *   Releases are not free.  In addition to the overhead required for 
labeling, creating ISOs, and updating documentation, projects that released in 
previous releases, are required to update their code for subsequent releases to 
resolve any issues, even if they weren't intending to do any additional work on 
that major release.  For example, let's say that a project releases in Danube 
1.0, they're satisfied with their effort, so they shift their focus to the 
E-release.  However, changes after 1.0 break their scenario.  So, suddenly, 
they find themselves working on Danube 2.0, even though they aren't releasing 
any new scenarios. This process repeats for Danube 3.0.
During the TSC call, it was suggested that a 2.0 or 3.0 release provides an 
opportunity to integrate a late release of a major upstream component (e.g. 
ODL).  However, this is counter to our previous agreement not to change major 
upstream components after the 1.0 release.  Unfortunately, this happened in 
Colorado and created significant disruption, including a slip in the 2.0 
release.

Per our discussion on Tuesday, I've created a wiki 
page<https://wiki.opnfv.org/display/SWREL/E-Release+Schedule+discussion> to 
capture pros and cons of various schedule options.  Feel free to edit it and 
add your thoughts.

David

--
David McBride
Relea

[opnfv-tech-discuss] Project proposals for adding analytics to OPNFV

2017-02-07 Thread Frank Brockners (fbrockne)

Hi OPNFV,

over the past few weeks we've distilled two proposals to add analytics and more 
diagnostic capabilities to OPNFV and OPNFV scenarios. We've published the two 
new project proposals on the wiki:

*   Bamboo: https://wiki.opnfv.org/display/bamboo/Bamboo+Project+Proposal

*   VINA: https://wiki.opnfv.org/display/vina/VINA+Project+Proposal

Bamboo is to introduce the analytics infrastructure provided by PNDA.io to 
OPNFV. VINA is to offer discovery and system health status for VIMs. Both 
projects are to work and in hand and are expected to integrate with both 
Barometer, VES, Qtip, etc. - as well as integrate with the testresults 
post-processing that we already do.

We're hoping for a discussion in the technical community meeting on Feb/23, and 
are also asking for an official TSC review post the technical community review. 
Target would be the TSC call on March/7.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank

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

Re: [opnfv-tech-discuss] Interpretation of yardstick test results

2016-10-06 Thread Frank Brockners (fbrockne)

Hi folks,

is there anyone around who can help with interpreting Yardstick's test results? 
I.e. what do all the numbers that we see created and submitted into the 
InfluxDB mean - i.e. how do I know whether a number is "good", "good enough", 
"not good"? In Grafana you see some nice graphs - but how do you interpret 
them? I scanned the user-guide but did not find any guidance - and from talking 
to other folks, I don't seem to be alone in struggling to understand the 
results.

Would greatly appreciate if someone could either explain the results (see e.g. 
Juraj's email below) or point us to a document that does so.

Many thanks!

Frank

From: Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco)
Sent: Dienstag, 4. Oktober 2016 16:23
To: Gaoliang (kubi) ; limingjiang 

Cc: opnfv-tech-discuss@lists.opnfv.org; Frank Brockners (fbrockne) 
; Andrej Vanko -X (avanko - PANTHEON TECHNOLOGIES at Cisco) 

Subject: Interpretation of yardstick test results

Hi Kubi,

Can you help us with interpreting yardstick results? I've attached data from 
four runs produced by yardstick, but I have no idea what they mean - how do I 
know what is a good result and what is not?

Thanks,
Juraj
___
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.

2016-09-22 Thread Frank Brockners (fbrockne)

Chris,

Juraj just completed tagging for FDS: 
https://git.opnfv.org/cgit/fds/tag/?h=colorado.1.0 (thanks Juraj!)

Frank

From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 21. September 2016 19:24
To: opnfv-project-le...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-project-leads] 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] [release] D-release schedule

2016-09-13 Thread Frank Brockners (fbrockne)

+1 – that sounds like a really simple resolution to the problem: “Unless you’re 
on the release branch and the release runs are done using the branch, you 
cannot participate in the release”.

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 21:06
To: David McBride 
Cc: Dave Neary ; Frank Brockners (fbrockne) 
; opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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

I would suggest a simple rule is that a release candidate can only be produced 
from the release branch.

From: David McBride 
mailto:dmcbr...@linuxfoundation.org>>
Date: Tuesday 13 September 2016 at 20:57
To: Christopher Price mailto:chrispric...@gmail.com>>
Cc: Dave Neary mailto:dne...@redhat.com>>, "Frank Brockners 
(fbrockne)" mailto:fbroc...@cisco.com>>, 
opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
mailto: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 
mailto:chrispric...@gmail.com>> 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" 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 on behalf of dne...@redhat.com<mailto: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<mailto: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<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

2016-09-13 Thread Frank Brockners (fbrockne)

Hi Chris,

we can pull stable once projects are done with the work on the release (i.e. 
release criteria is met) – i.e. it does not have to be the release date itself, 
but whenever a project feels like “ready”. One week prior to the release sounds 
reasonable – assuming you know when you’ll release ;-).

BTW/ - Releng already adopts this “don’t branch” principle – they didn’t even 
branch for Colorado.

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 13:19
To: Frank Brockners (fbrockne) ; David McBride 
; opnfv-project-le...@lists.opnfv.org; 
TECH-DISCUSS OPNFV 
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

Hi Frank,

I’m not sure the release date is realistic.
Given the way we use stable branch in our CI and release processes it has been 
apparent that it takes around a week or more for the labels and artefacts to be 
generated from stable.

I do think using a “window” for projects to progress to D release or not is 
valuable.
I would suggest having the CI team provide guidance on the latest possible date 
to branch to stable for any release.  (This depends on project adherence to CI 
processes and the processes themselves.)

/ Chris

From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Tuesday 13 September 2016 at 12:42
To: David McBride 
mailto:dmcbr...@linuxfoundation.org>>, 
opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

David,

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?

Thanks, Frank

From: 
opnfv-project-leads-boun...@lists.opnfv.org<mailto:opnfv-project-leads-boun...@lists.opnfv.org>
 [mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: 
opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>;
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-project-leads] [release] D-release schedule

Reminder... if you haven't yet reviewed the schedule, please do so before the 
TSC and release meetings on Tuesday, where it will likely be discussed.

David

On Thu, Sep 8, 2016 at 3:45 PM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule<https://wiki.opnfv.org/download/attachments/6827418/OPNFV%20Release%20%2522D%2522%20r2.pdf?version=1&modificationDate=1473367413338&api=v2>.
  Please review and provide feedback.

Note:  during the release meeting on Tuesday, we discussed removing the JIRA 
milestone, since it was not considered release gating.  Since then, I've 
changed my mind.  For the D-release, I expect that we will have implemented our 
JIRA processes sufficiently that we will be able to rely on JIRA to understand 
project status.  Therefore, it is appropriate to believe that if we still have 
unresolved JIRA issues assigned to the release, then the release is not 
complete.  We will be discussing exactly how this will be accomplished in the 
coming weeks.

David


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



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

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

2016-09-13 Thread Frank Brockners (fbrockne)

David,

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?

Thanks, Frank

From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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

Reminder... if you haven't yet reviewed the schedule, please do so before the 
TSC and release meetings on Tuesday, where it will likely be discussed.

David

On Thu, Sep 8, 2016 at 3:45 PM, David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule.
  Please review and provide feedback.

Note:  during the release meeting on Tuesday, we discussed removing the JIRA 
milestone, since it was not considered release gating.  Since then, I've 
changed my mind.  For the D-release, I expect that we will have implemented our 
JIRA processes sufficiently that we will be able to rely on JIRA to understand 
project status.  Therefore, it is appropriate to believe that if we still have 
unresolved JIRA issues assigned to the release, then the release is not 
complete.  We will be discussing exactly how this will be accomplished in the 
coming weeks.

David


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



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

Re: [opnfv-tech-discuss] [release][jira] OPNFV JIRA status

2016-09-12 Thread Frank Brockners (fbrockne)

David,

Several of the unplanned issues in FDS are Epics. When checking for unplanned 
issues, it might make sense to not count Epics because e.g. in FDS we don’t 
apply them to a single release (like Colorado 1.0).

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 22:32
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

Subject: [opnfv-tech-discuss] [release][jira] OPNFV JIRA status

Team,

See attachment for the latest OPNFV JIRA report.

We still have 235 unresolved issues assigned to Colorado 1.0.  Given that we 
are less than two weeks from the Colorado 1.0 release, these should be 
reassigned to future releases, unless you are confident that they will be 
resolved and closed this week.

In addition, we still have 144 unplanned issues (i.e. issues not assigned to a 
release in the "fix version" field.  Please continue to work to get these issue 
assigned to releases as soon as possible. Unplanned issues create ambiguity in 
understanding release status and for release planning.

Thanks and let me know if you have questions.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
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

2016-09-08 Thread Frank Brockners (fbrockne)

s/now a page/not a page/

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Donnerstag, 8. September 2016 17:28
To: Christopher Price ; Raymond Paik 

Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Hi Chris,

thanks – as long as we clearly position this effort as one of “trying to drive 
proper metrics”, we should be fine. I’m just concerned that once we have these 
toy metrics that people will start to rely on them and read things into them 
that are just not reflecting reality.  This should obviously be avoided.
I just updated the title of the wiki to reflect that this is a discussion page 
– and now a page with health metrics…

Thanks, Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Donnerstag, 8. September 2016 15:57
To: Frank Brockners (fbrockne) mailto:fbroc...@cisco.com>>; 
Raymond Paik mailto:rp...@linuxfoundation.org>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>; 
Dave Neary mailto:dne...@redhat.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Hi Frank,

I’m not sure I would equate the “rough metrics” implied in the current project 
lifecycle as providing significant guidance or establishing a meaningful 
measure of a projects maturity.  I might argue that they are sorely lacking on 
community discussion and agreement.

I see this dialog on community metrics as one vehicle for our community to 
chime in and help set these guidelines with the TSC.  I would not propose we 
stop doing this because we feel the lifecycle metrics are sufficient, rather 
the opposite in that this work may help us find meaningful lifecycle metrics as 
a community.

/ Chris

From: "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Thursday 8 September 2016 at 15:28
To: Raymond Paik mailto:rp...@linuxfoundation.org>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>, 
Christopher Price mailto:chrispric...@gmail.com>>, Dave 
Neary mailto:dne...@redhat.com>>, "SULLIVAN, BRYAN L" 
mailto:bs3...@att.com>>, TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Ray,

thanks – in which case, let’s first try to get the overall project lifecycle 
concept adopted. Once done – and we have experiences with the project life 
cycle, we can look into whether we need to create additional metrics etc. We 
could do that as another iteration of the project lifecycle doc – but for now, 
it would be key to get the lifecycle really adopted by projects. Let’s do one 
step after the other.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 15:23
To: Frank Brockners (fbrockne) mailto:fbroc...@cisco.com>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>; 
Christopher Price mailto:chrispric...@gmail.com>>; Dave 
Neary mailto:dne...@redhat.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Frank,

It's in the same spirit as the project lifecycle you mentioned earlier.  For 
example, I'd like to use it as one of the data points for guidance (as you 
noted) to highlight projects that are not doing as well

Thanks,

Ray

On Thu, Sep 8, 2016 at 2:28 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik 
[mailto:rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith mailto:daniel.sm...@ericsson.com>>
Cc: Christopher Price mailto:chrispric...@gmail.com>>; 
Dave Neary mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

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

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work

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

2016-09-08 Thread Frank Brockners (fbrockne)

Hi Chris,

thanks – as long as we clearly position this effort as one of “trying to drive 
proper metrics”, we should be fine. I’m just concerned that once we have these 
toy metrics that people will start to rely on them and read things into them 
that are just not reflecting reality.  This should obviously be avoided.
I just updated the title of the wiki to reflect that this is a discussion page 
– and now a page with health metrics…

Thanks, Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Donnerstag, 8. September 2016 15:57
To: Frank Brockners (fbrockne) ; Raymond Paik 

Cc: Daniel Smith ; Dave Neary ; 
SULLIVAN, BRYAN L ; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Hi Frank,

I’m not sure I would equate the “rough metrics” implied in the current project 
lifecycle as providing significant guidance or establishing a meaningful 
measure of a projects maturity.  I might argue that they are sorely lacking on 
community discussion and agreement.

I see this dialog on community metrics as one vehicle for our community to 
chime in and help set these guidelines with the TSC.  I would not propose we 
stop doing this because we feel the lifecycle metrics are sufficient, rather 
the opposite in that this work may help us find meaningful lifecycle metrics as 
a community.

/ Chris

From: "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Thursday 8 September 2016 at 15:28
To: Raymond Paik mailto:rp...@linuxfoundation.org>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>, 
Christopher Price mailto:chrispric...@gmail.com>>, Dave 
Neary mailto:dne...@redhat.com>>, "SULLIVAN, BRYAN L" 
mailto:bs3...@att.com>>, TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Ray,

thanks – in which case, let’s first try to get the overall project lifecycle 
concept adopted. Once done – and we have experiences with the project life 
cycle, we can look into whether we need to create additional metrics etc. We 
could do that as another iteration of the project lifecycle doc – but for now, 
it would be key to get the lifecycle really adopted by projects. Let’s do one 
step after the other.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 15:23
To: Frank Brockners (fbrockne) mailto:fbroc...@cisco.com>>
Cc: Daniel Smith mailto:daniel.sm...@ericsson.com>>; 
Christopher Price mailto:chrispric...@gmail.com>>; Dave 
Neary mailto:dne...@redhat.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Frank,

It's in the same spirit as the project lifecycle you mentioned earlier.  For 
example, I'd like to use it as one of the data points for guidance (as you 
noted) to highlight projects that are not doing as well

Thanks,

Ray

On Thu, Sep 8, 2016 at 2:28 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik 
[mailto:rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith mailto:daniel.sm...@ericsson.com>>
Cc: Christopher Price mailto:chrispric...@gmail.com>>; 
Dave Neary mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

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

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work is being done upstream) I doubt the activities in OPNFV repo or other 
tools would be zero over a period of 3-6 months.  So I think having a regular 
metrics (composite or otherwise) would be helpful in identifying projects that 
are either in need of help or are candidates for "archiving"

My 2 cents

Ray

On Wed, Sep 7, 2016 at 9:42 PM, Daniel Smith 
mailto:daniel.sm...@ericsson.com>> wrote:
Hello All.

My take on this and sorry maybe a bit blunt, but I don’t see what the purpose 
is here?

While guideline, guidance and such are good things, the discussion below seems 
awfully

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

2016-09-08 Thread Frank Brockners (fbrockne)

Ray,

thanks – in which case, let’s first try to get the overall project lifecycle 
concept adopted. Once done – and we have experiences with the project life 
cycle, we can look into whether we need to create additional metrics etc. We 
could do that as another iteration of the project lifecycle doc – but for now, 
it would be key to get the lifecycle really adopted by projects. Let’s do one 
step after the other.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 15:23
To: Frank Brockners (fbrockne) 
Cc: Daniel Smith ; Christopher Price 
; Dave Neary ; SULLIVAN, BRYAN L 
; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Frank,

It's in the same spirit as the project lifecycle you mentioned earlier.  For 
example, I'd like to use it as one of the data points for guidance (as you 
noted) to highlight projects that are not doing as well

Thanks,

Ray

On Thu, Sep 8, 2016 at 2:28 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik 
[mailto:rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith mailto:daniel.sm...@ericsson.com>>
Cc: Christopher Price mailto:chrispric...@gmail.com>>; 
Dave Neary mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

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

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work is being done upstream) I doubt the activities in OPNFV repo or other 
tools would be zero over a period of 3-6 months.  So I think having a regular 
metrics (composite or otherwise) would be helpful in identifying projects that 
are either in need of help or are candidates for "archiving"

My 2 cents

Ray

On Wed, Sep 7, 2016 at 9:42 PM, Daniel Smith 
mailto:daniel.sm...@ericsson.com>> wrote:
Hello All.

My take on this and sorry maybe a bit blunt, but I don’t see what the purpose 
is here?

While guideline, guidance and such are good things, the discussion below seems 
awfully heavy and very boxed in.

As Chris in the evaluation on how to improve the community, I am not sure how 
we could ever resolve what one person thinks is an adequate measure of 
something over another (i.e endless debate), since metrics, improvements - 
unless we are talking about something quantifiable - and that would mean taking 
this to code optimization level ultimately - are subjective based and 
implement/reaction based measured over time in the case of adjustment.

As well +1 to doing our own assessments - since it should be us that outlines 
what we want to say about how we feel we have improved, and this only makes 
sense I would think as we are the only ones who have the context to see where 
we came from to where we are and what we are talking about doing next.

I would say however, that I am really concerned at that level of discussion 
across all meetings on project handling and process and such - release and 
otherwise - while this shows we are active and "moving" sure - there is a lot 
of dissonance in the communication, mixed messages and again, lots of 
information overflow.   I would like to see the "Operational" parts of OPNFV 
(Release Project, INFRA, TSC) focus more on how we support the projects in 
terms of day to day pain points - that is a solid, referable release process, a 
solid, regularly maintained method of publish,  a solid Change process (for 
anything) that ensures that we don’t discuss and move from one week to another 
- not because an idea is good or bad, but simply cause we need to recognize 
that there are more than the 25 or so regular attendees in the groups / this 
mailing list.

Would there be a market for such publishing outside our domain I would wonder?  
For Code stats and fun numbers those are nice to have, but a qualitative review 
of how we have improved our processes as a community, im not sure?  I would 
vouchsafe that our work in the projects themselves are what OPNFV is pushing 
out, the operational aspects of "how we are doing things" - while nice to 
outline, against the backdrop of every growing laundry list of things to 
"Decide" is really n

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

2016-09-08 Thread Frank Brockners (fbrockne)

Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith 
Cc: Christopher Price ; Dave Neary ; 
Frank Brockners (fbrockne) ; SULLIVAN, BRYAN L 
; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work is being done upstream) I doubt the activities in OPNFV repo or other 
tools would be zero over a period of 3-6 months.  So I think having a regular 
metrics (composite or otherwise) would be helpful in identifying projects that 
are either in need of help or are candidates for "archiving"

My 2 cents

Ray

On Wed, Sep 7, 2016 at 9:42 PM, Daniel Smith 
mailto:daniel.sm...@ericsson.com>> wrote:
Hello All.

My take on this and sorry maybe a bit blunt, but I don’t see what the purpose 
is here?

While guideline, guidance and such are good things, the discussion below seems 
awfully heavy and very boxed in.

As Chris in the evaluation on how to improve the community, I am not sure how 
we could ever resolve what one person thinks is an adequate measure of 
something over another (i.e endless debate), since metrics, improvements - 
unless we are talking about something quantifiable - and that would mean taking 
this to code optimization level ultimately - are subjective based and 
implement/reaction based measured over time in the case of adjustment.

As well +1 to doing our own assessments - since it should be us that outlines 
what we want to say about how we feel we have improved, and this only makes 
sense I would think as we are the only ones who have the context to see where 
we came from to where we are and what we are talking about doing next.

I would say however, that I am really concerned at that level of discussion 
across all meetings on project handling and process and such - release and 
otherwise - while this shows we are active and "moving" sure - there is a lot 
of dissonance in the communication, mixed messages and again, lots of 
information overflow.   I would like to see the "Operational" parts of OPNFV 
(Release Project, INFRA, TSC) focus more on how we support the projects in 
terms of day to day pain points - that is a solid, referable release process, a 
solid, regularly maintained method of publish,  a solid Change process (for 
anything) that ensures that we don’t discuss and move from one week to another 
- not because an idea is good or bad, but simply cause we need to recognize 
that there are more than the 25 or so regular attendees in the groups / this 
mailing list.

Would there be a market for such publishing outside our domain I would wonder?  
For Code stats and fun numbers those are nice to have, but a qualitative review 
of how we have improved our processes as a community, im not sure?  I would 
vouchsafe that our work in the projects themselves are what OPNFV is pushing 
out, the operational aspects of "how we are doing things" - while nice to 
outline, against the backdrop of every growing laundry list of things to 
"Decide" is really not high on a list?I didn’t understand from below the 
"why" and "who" for this fully.


Cheers and thank you
D




-Original Message-
From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of Christopher Price
Sent: Wednesday, September 07, 2016 9:20 PM
To: Dave Neary mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
mailto:bs3...@att.com>>; Raymond Paik 
mailto:rp...@linuxfoundation.org>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Good comments Dave and everyone, I’d like to share my take on it is this.

I don’t see any problem in looking at the metrics we already publish and using 
them to help us create a better understanding across our community on how we go 
about getting things done.  (Maybe also helping find ways of improving 
ourselves.)

As was mentioned we publish all these metrics today.  I would prefer to see the 
OPNFV community drawing it’s own assessments of what that means rather than 
leaving it up to the imagination o

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

2016-09-06 Thread Frank Brockners (fbrockne)

+1.

Also note that when we defined the project lifecycle we used metrics like the 
ones mentioned only as guidance rather than something to compute a composite 
value – and even there, we did not constrain things to metrics in OPNFV only.

Frank

From: SULLIVAN, BRYAN L [mailto:bs3...@att.com]
Sent: Dienstag, 6. September 2016 18:48
To: Frank Brockners (fbrockne) ; Raymond Paik 
; opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

I’m unsure of the overall value of this exercise. Simply ask the PTLs what the 
“health” of the project is. An honest PTL will tell you, and that’s the only 
type we should elect.

Publish metrics if you want (we already do), but I would avoid trying to draw 
conclusions from them. We do not have the luxury (if you can even call it 
that!) of creating and maintaining a project-introspection framework ala what 
you might see in corporate development shops. Even considering what metrics are 
“useful” for specific purposes (e.g. what “useful”/reliable implications can 
you draw from them) takes too much time away from the real work.

Thanks,
Bryan Sullivan | AT&T

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Tuesday, September 06, 2016 7:39 AM
To: Raymond Paik; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

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>
 [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<mailto: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] Following up on Project Health metrics discussion

2016-09-06 Thread 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] Evolution of OPNFV mailing lists

2016-09-02 Thread Frank Brockners (fbrockne)

Hi Ray, Chris,

makes sense to me. Minor correction on what you state below: fds-dev is a 
project specific mailing list and has folks from a variety of upstream 
communities up it (mostly ODL, FD.io, OpenStack). Hence we likely need a 
fdio-...@opnfv.org.

Frank


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Montag, 29. August 2016 18:57
To: Raymond Paik ; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Evolution of OPNFV mailing lists

Hi Ray,

One thing, as the url is lists.opnfv.org I find the “opnfv-“ at the start of 
the identities to be somewhat unnecessary.

Maybe we could use something like:
infra...@lists.opnfv.org
test...@lists.opnfv.org
mano...@lists.opnfv.org
and
openstack-...@lists.opnfv.org
odl-...@lists.opnfv.org
fds-...@lists.opnfv.org

For example.

/ Chris

From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Raymond Paik 
mailto:rp...@linuxfoundation.org>>
Date: Monday 29 August 2016 at 18:41
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] Evolution of OPNFV mailing lists

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 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)
  *   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
  *   Create new mailing lists for upstream discussions with OpenStack 
(opnfv-openstack) and OpenDaylight (opnfv-odl) communities

 *   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] Configuring LF POD with 2 RQs on VIC profiles

2016-08-29 Thread Frank Brockners (fbrockne)

Hi Tim,

+1 on the config change. 

Background: If one wants to switch to Rx scatter mode for 1 queue or use more 
than 1 RQ, one really does have to configure on the VNIC 2x the number needed 
by the DPDK app. There is no way around this in the current implementation and 
is the way Rx scatter works on the VIC, where Rx Scatter spill-over buffers are 
on a 2nd RQ .  Hence the general advice is to configure 2x the number of RQs 
needed. This will also be reflected in the next revision of the ENIC driver 
documentation. Longer term, there is a plan to eliminate the 2nd RQ in general 
(not just for 1 RQ) when Rx scatter is disabled but this is probably happening 
post the 16.11 DPDK release.

Frank


-Original Message-
From: fds-dev-boun...@lists.opnfv.org [mailto:fds-dev-boun...@lists.opnfv.org] 
On Behalf Of Tim Rozet
Sent: Montag, 29. August 2016 18:17
To: infra-steer...@lists.opnfv.org
Cc: Gregory Elkinbard ; Sean Chandler (sechandl) 
; fds-...@lists.opnfv.org; OPNFV Tech 

Subject: [Fds-dev] Configuring LF POD with 2 RQs on VIC profiles

Hi,
We need to configure 2 RQs on VIC profiles in the UCS manager for DPDK to work. 
 From what I understand we can make the configuration change and it won't take 
effect until the blades are rebooted.  For Apex, we need POD 1 to have this 
configuration for FDIO/and OVS DPDK to daily jobs to pass.  Before I make the 
change, just want to make sure no one is against it.  Also, do you want me to 
make the same configuration change for LF POD2 for Fuel?

Thanks,

Tim Rozet
Red Hat SDN Team

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

[opnfv-tech-discuss] [genesis] Genesis in Colorado

2016-08-18 Thread Frank Brockners (fbrockne)

Hi David, team,

FYI: Given that Genesis did not document any additional requirements for 
deployment tools beyond what had already been defined for Brahmaputra and the 
fact that we still haven't arrived at defining and adopting common 
configuration files across all installers, the Genesis project decided to not 
participate in the upcoming Colorado release. I've updated the Colorado project 
release page accordingly.

Regards,
Frank


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

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

2016-08-10 Thread Frank Brockners (fbrockne)

Hi Chris,

thanks – at least with the instructions provided (I did not scrub the deploy 
script) – things also don’t work for the entire project (it looks as if the 
script needs to be run at top level – but even then it comes back and moans 
that “docs” does not exist). Cc’ing Ryota. So am back to using rst2html…

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Mittwoch, 10. August 2016 14:16
To: Frank Brockners (fbrockne) ; Christopher Price 
; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] Working with the docs toolchain locally on 
your laptop.

Hi Frank,

That’s not possible with the instructions/scripts provided.  There may be some 
black magic that could be done but I am really not familiar enough to provide 
it.

In general though, the docs rendering is not a heavyweight activity and it 
should not take more than a few seconds to run the project rather than just one 
document.

/ Chris

From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Wednesday 10 August 2016 at 13:28
To: Christopher Price 
mailto:christopher.pr...@ericsson.com>>, 
TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] Working with the docs toolchain locally on 
your laptop.

Hi Chris,

thanks for the pointer. Is there a way to just check whether a single file 
builds/parses correctly – rather than always building the entire project?

Thanks, Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 10. August 2016 12:29
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] Working with the docs toolchain locally on your 
laptop.

Hi Community,

While our CI system provides a complete docs renderer that gives you up to date 
links to your documentation when you push a patch for review it may be useful 
for you to work with the toolchain locally while doing you Colorado 
documentation.

This has been made rather simple by our champion of docs scripting Ryota and 
the procedure is kept up to date and relevant at this link:
http://artifacts.opnfv.org/opnfvdocs/docs/how-to-use-docs/documentation-example.html#testing

If you would like to render your docs as you go, please try the toolchain above.
If you prefer you can also simply push a docs patch and follow the links 
provided on the review page.

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

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

2016-08-10 Thread Frank Brockners (fbrockne)

Just to clarify: I’d like to use the OPNFV tool chain on a set of specific 
files only and see whether they render correctly – as opposed to just use 
rst2html (which is what I currently do).

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Mittwoch, 10. August 2016 13:28
To: Christopher Price ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] Working with the docs toolchain locally on 
your laptop.

Hi Chris,

thanks for the pointer. Is there a way to just check whether a single file 
builds/parses correctly – rather than always building the entire project?

Thanks, Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 10. August 2016 12:29
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] Working with the docs toolchain locally on your 
laptop.

Hi Community,

While our CI system provides a complete docs renderer that gives you up to date 
links to your documentation when you push a patch for review it may be useful 
for you to work with the toolchain locally while doing you Colorado 
documentation.

This has been made rather simple by our champion of docs scripting Ryota and 
the procedure is kept up to date and relevant at this link:
http://artifacts.opnfv.org/opnfvdocs/docs/how-to-use-docs/documentation-example.html#testing

If you would like to render your docs as you go, please try the toolchain above.
If you prefer you can also simply push a docs patch and follow the links 
provided on the review page.

Regards,
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] Working with the docs toolchain locally on your laptop.

2016-08-10 Thread Frank Brockners (fbrockne)

Hi Chris,

thanks for the pointer. Is there a way to just check whether a single file 
builds/parses correctly – rather than always building the entire project?

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 10. August 2016 12:29
To: TECH-DISCUSS OPNFV 
Subject: [opnfv-tech-discuss] Working with the docs toolchain locally on your 
laptop.

Hi Community,

While our CI system provides a complete docs renderer that gives you up to date 
links to your documentation when you push a patch for review it may be useful 
for you to work with the toolchain locally while doing you Colorado 
documentation.

This has been made rather simple by our champion of docs scripting Ryota and 
the procedure is kept up to date and relevant at this link:
http://artifacts.opnfv.org/opnfvdocs/docs/how-to-use-docs/documentation-example.html#testing

If you would like to render your docs as you go, please try the toolchain above.
If you prefer you can also simply push a docs patch and follow the links 
provided on the review page.

Regards,
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] About testapi doesn't work in testresults.opnfv.org due to 'No space left on the device'

2016-08-04 Thread Frank Brockners (fbrockne)

Serena,

could you create a ticket with helpdesk to get the disksize increased (just 
send email to 
opnfv-helpd...@rt.linuxfoundation.org)?

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
feng.xiao...@zte.com.cn
Sent: Donnerstag, 4. August 2016 09:19
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] About testapi doesn't work in 
testresults.opnfv.org due to 'No space left on the device'

Hi,

Now testapi in testresults.opnfv.org doesn't work due to no space left,
thus all the test results will be discarded, I check the disk space,
only 10G is assigned to testresults.opnfv.org, too small to be a data
collector server. Can someone help us fix it?

Disk info is shown below:
[serena@gce-opnfv-sandbox-fbrockners ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 10G 10G 23M 100% /
devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs 3.7G 0 3.7G 0% /dev/shm
tmpfs 3.7G 581M 3.1G 16% /run
tmpfs 3.7G 0 3.7G 0% /sys/fs/cgroup
tmpfs 749M 0 749M 0% /run/user/1012
tmpfs 749M 0 749M 0% /run/user/0
tmpfs 749M 0 749M 0% /run/user/1020

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

42 matches

Mail list logo