date:20170627

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

2017-06-27 Thread Christopher Price

Hi Wenjing,

Thanks for responding.  With regards to my first question, the question was "is 
API testing sufficient for an OPNFV CVP program?".  I had understood from the 
C committee that the answer was no, but thought the TSC might be the right 
place to have a deeper discussion.  IPv6 of course is a good example to discuss.

On the "curating our own" tempest suite derived from RefStack it would be good 
to outline the strategy and approach.  It wasn't purely a documentation 
question.

Cheers,
Chris

Sent from my iPhone

> On Jun 28, 2017, at 02:04, Wenjing Chu  wrote:
> 
> Hi Chris, and Dave, who also raised this question about ipv6 during the TSC 
> call,
> 
> The question of ipv6 data path testing, like a v6ping, was considered and 
> analyzed, but the conclusion was that the data path support in opnfv 
> scenarios is still very weak. The one case that could potentially be 
> supported is to test v6-overlay ping with a v6Router, but that test case was 
> not only done as a manual process, to my knowledge, and was not automated to 
> be regularly run. Folks in ipv6 project, please comment if my understanding 
> is inaccurate in any way. In short, we don't have good options in ipv6 data 
> path testing in Danube. We hope to rectify the problem in E. 
> 
> Partly for this reason, ipv6 is optional in the proposed suite, not mandatory.
> 
> For documentation of RefStack, dovetail's plan was that those would be 
> documented, and I think an initial sample had been started a while ago. I see 
> this as a work item to be completed, not a scope question.
> 
> Regards
> Wenjing
> 
> -Original Message-
> From: Christopher Price [mailto:christopher.pr...@ericsson.com] 
> Sent: Tuesday, June 27, 2017 1:07 AM
> To: Tim Irnich ; Dave Neary ; 
> Wenjing Chu ; Tianhongbo 
> ; Tallgren, Tapio ; 
> Georg Kunz 
> Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 
> 
> Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
> meeting to discuss scope and needs for CVP testing
> 
> Hi Folks,
> 
> Did we come to any conclusions on a couple of outstanding points that come to 
> my mind as things to come to decisions on as they establish our technical 
> scope:
> 1) Is it OK for instance that test cases only evaluate API responses?  I am 
> thinking of suites like the IPv6 where we do not pass any IPv6 traffic in the 
> system as part of our compliance suite at this time.
> 2) Do we intend to document the inherited test cases for RefStack?  If not, 
> and we are not curating those tests in any way ourselves, maybe we should 
> pull them out as explicit tests cases and refer instead to the RefStack 
> documentation and infer that we expect RefStack to be passed on an OPNFV 
> deployed system as a pre-requisite.  
> We need a clear way of handling those test cases, either we curate them 
> ourselves or we have a clear agreement with the OpenStack interop WG on how 
> we leverage that suite.  At this time we list an own curated version but 
> provide no documentation of the test cases, why they were selected and the 
> procedure for selection.
> 
> Cheers,
>Chris
> 
> On 2017-06-23, 11:50, "Tim Irnich"  wrote:
> 
>Hi Dave, all,
> 
>Sorry for misunderstanding your point. In that case, is there any other 
> feedback from other TSC members on the proposal?
> 
>Tapio & Ray, I think we should reserve some time in next week's TSC to go 
> over the suggested test scope (both mandatory and optional parts) for Danube 
> compliance testing once more so that the Dovetail team can be confident about 
> focusing on the right things.
> 
>Regards, Tim
> 
>-Original Message-
>From: Dave Neary [mailto:dne...@redhat.com]
>Sent: Wednesday, June 21, 2017 01:53
>To: Tim Irnich ; Wenjing Chu 
> ; Christopher Price ; 
> Tianhongbo ; Tallgren, Tapio 
> ; Georg Kunz 
>Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 
> 
>Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
> meeting to discuss scope and needs for CVP testing
> 
>Hi Tim,
> 
>On 06/20/2017 09:02 PM, Tim Irnich wrote:
>>> I would like to see us document some of the NFV related requirements
>>> which are common across all RFCs from telcos, and which are available
>>> in all viable VIM products.
>> 
>> This is exactly the intention of the proposal, under the side
>> constraint of drawing from already existing tests. The question to the
>> TSC was if this is enough for an initial release. I think your answer is no.
> 
>On the

[opnfv-tech-discuss] Updated Invitation: OPNFV Release Meeting (ASIA) - IRC Only @ Every 2 weeks from 7:30pm to 8pm on Tuesday (PST) (opnfv-tech-discuss@lists.opnfv.org)

2017-06-27 Thread dmcbride

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20170207T193000
DTEND;TZID=America/Los_Angeles:20170207T20
EXDATE;TZID=America/Los_Angeles:20170418T193000
EXDATE;TZID=America/Los_Angeles:20170613T193000
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU
DTSTAMP:20170628T022335Z
ORGANIZER;CN=dmcbr...@linuxfoundation.org:mailto:dmcbride@linuxfoundation.o
 rg
UID:11kh9s24ihgphd9ufop1045...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=kong.w...@zte.com.cn;X-NUM-GUESTS=0:mailto:kong.w...@zte.com.cn
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=opnfv-project-le...@lists.opnfv.org;X-NUM-GUESTS=0:mailto:opnfv-pro
 ject-le...@lists.opnfv.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=DECLINED;RSVP=TRUE
 ;CN=Zhipeng Huang;X-NUM-GUESTS=0:mailto:zhipengh...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=zhangyujun+...@gmail.com;X-NUM-GUESTS=0:mailto:zhangyujun+...@gmail.co
 m
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=r-m...@cq.jp.nec.com;X-NUM-GUESTS=0:mailto:r-m...@cq.jp.nec.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=joehu...@huawei.com;X-NUM-GUESTS=0:mailto:joehu...@huawei.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=chig...@huawei.com;X-NUM-GUESTS=0:mailto:chig...@huawei.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=hu.zhiji...@zte.com.cn;X-NUM-GUESTS=0:mailto:hu.zhiji...@zte.com.cn
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=hu@zte.com.cn;X-NUM-GUESTS=0:mailto:hu@zte.com.cn
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=huangzhip...@huawei.com;X-NUM-GUESTS=0:mailto:huangzhipeng@huawei.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=dmcbr...@linuxfoundation.org;X-NUM-GUESTS=0:mailto:dmcbride@linuxfounda
 tion.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jean.gaoli...@huawei.com;X-NUM-GUESTS=0:mailto:jean.gaoliang@huawei
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=fuq...@chinamobile.com;X-NUM-GUESTS=0:mailto:fuq...@chinamobile.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gabriel.yuy...@huawei.com;X-NUM-GUESTS=0:mailto:gabriel.yuyang@huaw
 ei.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=zhang.yuj...@zte.com.cn;X-NUM-GUESTS=0:mailto:zhang.yuj...@zte.com.
 cn
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=opnfv-tech-discuss@lists.opnfv.org;X-NUM-GUESTS=0:mailto:opnfv-tech
 -disc...@lists.opnfv.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Jason HU;X-NUM-GUESTS=0:mailto:huzhiji...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Xuan Jia;X-NUM-GUESTS=0:mailto:jason.jiax...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=shang.xiaod...@zte.com.cn;X-NUM-GUESTS=0:mailto:shang.xiaodong@zte.
 com.cn
CREATED:20170128T020500Z
DESCRIPTION:This meeting is intended for OPNFV members in Asia who are unab
 le to attend the regular release meeting.  We will meet every two weeks on 
 IRC.  \n\nPlease join me to discuss status\, process\, and to resolve issue
 s related to OPNFV releases.  Questions welcome!\nView your event at https:
 //www.google.com/calendar/event?action=VIEW=MTFraDlzMjRpaGdwaGQ5dWZvcDE
 wNDVyMTAgb3BuZnYtdGVjaC1kaXNjdXNzQGxpc3RzLm9wbmZ2Lm9yZw=MjgjZG1jYnJpZGV
 AbGludXhmb3VuZGF0aW9uLm9yZzk1N2NjNDQzOTQ3YTdiMjYxZDVmODg5OWRmNGY1MDg4NjY1NT
 BkMDg=America/Los_Angeles=en.
LAST-MODIFIED:20170628T022333Z
LOCATION:IRC channel:  OPNFV-Release
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:OPNFV Release Meeting (ASIA) - IRC Only
TRANSP:OPAQUE
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
BEGIN:VALARM
ACTION:NONE
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
X-WR-ALARMUID:46BE7886-8251-47A8-B2F6-DBBD9ED041BD
UID:46BE7886-8251-47A8-B2F6-DBBD9ED041BD
ACKNOWLEDGED:20170628T022332Z
X-APPLE-DEFAULT-ALARM:TRUE
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

2017-06-27 Thread Wenjing Chu

Hi TSC members,

I just realized that the original email with the proposed scope has been cut 
out in this thread. I'm copying it below again as the part of last call for 
feedback regarding to the initial cvp test scope, per today's TSC meeting 
action item.

Please keep in mind that we are requesting your feedback on the *scope* of the 
first cvp release, not the completion of the entire project. The dovetail 
team's work is very challenging, they need your attention and support to close 
on a definitive scope, so the team can focus on getting the agreed scope 
completed. We need a "feature freeze", so to speak, to manage the project. 
Other feedbacks are welcome and valuable too, of course, but we've long past 
the normal "feature freeze" time from a normal project management perspective. 
So we need timeliness in this review process.

As agreed on today's TSC call, TSC members please provide your feedback on the 
proposed Dovetail scope by this Friday, June 30, 2017.

Regards
Wenjing

And here's Tim Irnich's summary email:

--
Hi all,

During the Beijing design summit, the Dovetail team has considered the recent 
feedback from TSC and has identified the following set of actions towards an 
initial CVP release:
-   Have all ongoing documentation-related Gerrit reviews merged, documents 
finalized (no editor's notes, open actions etc.)
-   Move HA tests from optional to mandatory 
o   For information: Current HA suite kills OpenStack service 
process and verifies continuous API availability
-   Make Functest's vPing a mandatory test

We would like to request feedback from TSC if this set of actions is sufficient 
to address the recently provided feedback, or if there is anything else the TSC 
would deem required for the initial release. 

In addition the Dovetail team walked through the list of OPNFV feature projects 
and concluded that currently no other projects than the already included ones 
are advanced enough for compliance verification, due to varying reasons (e.g. 
depending on midstream patches, etc.). 

To provide visibility into what would be coming next, an initial list of work 
items for Euphrates was created:
-   Stress testing
-   Include Doctor (optional/mandatory is tbd)
-   Include Models (the OPNFV project) test cases (launch a sample multi-VM 
VNF) 
o   We need to check these against the test case requirements
-   Incorporate more OPNFV feature projects (e.g. SFC etc.)

Regards,

Tim (on behalf of the entire Dovetail team)

-
-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Wenjing Chu
Sent: Tuesday, June 27, 2017 5:03 PM
To: Christopher Price ; Tim Irnich 
; Dave Neary ; Tianhongbo 
; Tallgren, Tapio ; Georg 
Kunz 
Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
meeting to discuss scope and needs for CVP testing

Hi Chris, and Dave, who also raised this question about ipv6 during the TSC 
call,

The question of ipv6 data path testing, like a v6ping, was considered and 
analyzed, but the conclusion was that the data path support in opnfv scenarios 
is still very weak. The one case that could potentially be supported is to test 
v6-overlay ping with a v6Router, but that test case was not only done as a 
manual process, to my knowledge, and was not automated to be regularly run. 
Folks in ipv6 project, please comment if my understanding is inaccurate in any 
way. In short, we don't have good options in ipv6 data path testing in Danube. 
We hope to rectify the problem in E. 

Partly for this reason, ipv6 is optional in the proposed suite, not mandatory.

For documentation of RefStack, dovetail's plan was that those would be 
documented, and I think an initial sample had been started a while ago. I see 
this as a work item to be completed, not a scope question.

Regards
Wenjing

-Original Message-
From: Christopher Price [mailto:christopher.pr...@ericsson.com] 
Sent: Tuesday, June 27, 2017 1:07 AM
To: Tim Irnich ; Dave Neary ; 
Wenjing Chu ; Tianhongbo 
; Tallgren, Tapio ; Georg 
Kunz 
Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
meeting to discuss scope and needs for CVP testing

Hi Folks,

Did we come to any conclusions on a couple of outstanding points that come to 
my mind as things to come to decisions on as they establish our technical scope:
1) Is it OK for

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

2017-06-27 Thread Wenjing Chu

Hi Chris, and Dave, who also raised this question about ipv6 during the TSC 
call,

The question of ipv6 data path testing, like a v6ping, was considered and 
analyzed, but the conclusion was that the data path support in opnfv scenarios 
is still very weak. The one case that could potentially be supported is to test 
v6-overlay ping with a v6Router, but that test case was not only done as a 
manual process, to my knowledge, and was not automated to be regularly run. 
Folks in ipv6 project, please comment if my understanding is inaccurate in any 
way. In short, we don't have good options in ipv6 data path testing in Danube. 
We hope to rectify the problem in E. 

Partly for this reason, ipv6 is optional in the proposed suite, not mandatory.

For documentation of RefStack, dovetail's plan was that those would be 
documented, and I think an initial sample had been started a while ago. I see 
this as a work item to be completed, not a scope question.

Regards
Wenjing

-Original Message-
From: Christopher Price [mailto:christopher.pr...@ericsson.com] 
Sent: Tuesday, June 27, 2017 1:07 AM
To: Tim Irnich ; Dave Neary ; 
Wenjing Chu ; Tianhongbo 
; Tallgren, Tapio ; Georg 
Kunz 
Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
meeting to discuss scope and needs for CVP testing

Hi Folks,

Did we come to any conclusions on a couple of outstanding points that come to 
my mind as things to come to decisions on as they establish our technical scope:
1) Is it OK for instance that test cases only evaluate API responses?  I am 
thinking of suites like the IPv6 where we do not pass any IPv6 traffic in the 
system as part of our compliance suite at this time.
2) Do we intend to document the inherited test cases for RefStack?  If not, and 
we are not curating those tests in any way ourselves, maybe we should pull them 
out as explicit tests cases and refer instead to the RefStack documentation and 
infer that we expect RefStack to be passed on an OPNFV deployed system as a 
pre-requisite.  
We need a clear way of handling those test cases, either we curate them 
ourselves or we have a clear agreement with the OpenStack interop WG on how we 
leverage that suite.  At this time we list an own curated version but provide 
no documentation of the test cases, why they were selected and the procedure 
for selection.

Cheers,
Chris

On 2017-06-23, 11:50, "Tim Irnich"  wrote:

Hi Dave, all,

Sorry for misunderstanding your point. In that case, is there any other 
feedback from other TSC members on the proposal?

Tapio & Ray, I think we should reserve some time in next week's TSC to go 
over the suggested test scope (both mandatory and optional parts) for Danube 
compliance testing once more so that the Dovetail team can be confident about 
focusing on the right things.

Regards, Tim

-Original Message-
From: Dave Neary [mailto:dne...@redhat.com]
Sent: Wednesday, June 21, 2017 01:53
To: Tim Irnich ; Wenjing Chu 
; Christopher Price ; 
Tianhongbo ; Tallgren, Tapio 
; Georg Kunz 
Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
meeting to discuss scope and needs for CVP testing

Hi Tim,

On 06/20/2017 09:02 PM, Tim Irnich wrote:
>> I would like to see us document some of the NFV related requirements
>> which are common across all RFCs from telcos, and which are available
>> in all viable VIM products.
>
> This is exactly the intention of the proposal, under the side
> constraint of drawing from already existing tests. The question to the
> TSC was if this is enough for an initial release. I think your answer is 
no.

On the contrary - the initial release scope is fine, my comment was on the 
"future plans" piece.

Thanks,
Dave.

--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

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

[opnfv-tech-discuss] UK / London OPNFV meetup

2017-06-27 Thread Luke Hinds

Hi,

I would like to see if there is any interest in having a UK (possibly
London) OPNFV meetup.

This would be an informal event, either in a pub somewhere or some office
space if a kind donor appears. If it goes well, then we can build from
there.

I hope to see at least five + positives, to signify its worth going ahead.

Times are flexible, but I figure September might be good target, as its
outside the summer holiday break period, but we will still have some
daylight kicking around.

Cheers,

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

Re: [opnfv-tech-discuss] [test-wg] [OPNFV] Draft support for presentation to TSC

2017-06-27 Thread SULLIVAN, BRYAN L

Thanks for raising this, Fatih. It echoes some of the perspective I gave at the 
summit, i.e. that we have gotten pretty good at repeating past successes, even 
if fairly thin ones, but not at going beyond them. The problem with that is 
that things always fall apart over time, unless there is a culture of 
continuous, measured improvement and strengthening of contributor resources. 
But without those, the desire to continue the appearance (at least) of success 
results in a lower bar being applied with each release. Thus we need to pursue 
the new successes (as you note) of:

  *   Raising the bar on deployment success, e.g. deepening the test suite 
beyond “API existence” levels etc (raising the sensitivity to “pain” in the 
system)
  *   Implementing CI evolution, especially publication of daily/as-built 
artifacts that have been validated and can thus raise productivity in further 
testing and developer efforts
  *   Measuring where we are on the “pain vs boredom” curve and shifting 
resources (where we are bored) to more challenging tests
  *   Focusing on resiliency tests (stability over days with load and stress 
factors)
  *   Monitoring and expanding (or preserving at least) the contributor 
resources that are necessary for all that

Thanks,
Bryan Sullivan | AT

From: test-wg-boun...@lists.opnfv.org [mailto:test-wg-boun...@lists.opnfv.org] 
On Behalf Of Fatih Degirmenci
Sent: Monday, June 26, 2017 2:08 PM
To: Wenjing Chu ; Beierl, Mark 
Cc: test...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [test-wg] [opnfv-tech-discuss] [OPNFV] Draft support for 
presentation to TSC

Hi,

I just want to stress again that CI is a software development practice, not 
something that is just used for release testing purposes. The CI doesn't start 
and end with daily runs so what we are doing with what we call "CI" is 
fundamentally broken.

As a community, it is past time we take a step back and look at what we've been 
doing.

One of the things that require improvements is how we take our decisions. I 
suppose I'm not terribly wrong if I say our decisions, especially the release 
related ones, are mainly driven by pushing more stuff out and on time rather 
than being on time with quality.
If we look at our past releases, we have successfully been lowering the quality 
by removing testing and limiting the time it takes for testing community to 
troubleshoot/work on issues with developers.
I think 2nd release had the highest quality - we at least took benchmarking 
results into account and gave more time to our testing community. Last release, 
we were almost going to release something that's not even tested.

Due to this, we push more and more stuff out with lower quality. This results 
in long cycle times, lack of resources and queued executions  because we want 
to ensure that that many number of things can be deployed X number of times 
rather than looking at if few of those things can be deployed, providing the 
intended functionality and can stay up for Y number of days under stress, 
giving people confidence in them so they can go ahead with their feature 
integration. Because of this, the integration happens pretty late in release 
cycle, not leaving enough time for people to test things properly.

Apart from that, everything we do changes all the time. Infra, test frameworks, 
test cases, installers, features, upstream components, etc. We need to take 
things under control and limit the number of things that change between 2 runs 
so we can compare apples with apples to see what went wrong when something 
turns red and fix it properly, relieving some pressure from the people and the 
infrastructure by avoiding rerunning/retroubleshooting improperly fixed things 
so we can prevent waste of time and resources.

Some of you know that we have been trying to improve what we are doing but we 
haven't been successful due to different reasons. Some of the examples are 
commit gating, promotion, trust indicator, not putting non-working stuff on 
baremetal, having separate pipelines for test projects, better handling of our 
resources, etc. We will obviously continue trying these and even more as long 
as we get support from the community.

So I personally support this initiative fully and I even think that we should 
cut the number of baremetal deployments in half and dedicate the rest of the 
time to non-functional testing.
This might require us to cut the number of features we release, bring stuff on 
to baremetal when/if they meet certain criteria, or be clever when it comes to 
how we use our limited resources (human and infra) and construct/utilize our CI.

/Fatih

From: 
>
 on behalf of Wenjing Chu >
Date: Monday, 26 June 2017 at 21:36
To: "Beierl, Mark"

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

2017-06-27 Thread Luke Hinds

Thanks Trevor!

Just found a bug in my code now its running, so patch on its way.

On Tue, Jun 27, 2017 at 8:14 PM, Trevor Bramwell <
tbramw...@linuxfoundation.org> wrote:

> Hey Luke,
>
> Thanks for the reviews! It looks like the patch[1] fixed the
> verification[2] and anteater is running again.
>
> Regards,
> Trevor Bramwell
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/36601/
> [2] https://build.opnfv.org/ci/job/opnfv-security-audit-
> verify-master/148/console
>
> On Tue, Jun 27, 2017 at 05:15:40PM +0100, Luke Hinds wrote:
> > Hi Trevor,
> >
> > I am ok with going for #1
> >
> > If should not really be me approving patches in releng, so will let the
> > other cores chime in.
> >
> > For #2 I looked at your log and see what you mean. I cannot spot why a
> > normal user is allowed to install.
> >
> > This is what I get when trying to install on my home PC (arch linux):
> >
> > [Errno 13] Permission denied: '/usr/lib/python2.7/site-packages/
> >
> > Regards,
> >
> > Luke
> >
> >
> >
> > On Tue, Jun 27, 2017 at 5:04 PM, Trevor Bramwell <
> > tbramw...@linuxfoundation.org> wrote:
> >
> > > Hey Luke,
> > >
> > > I'm definitely opting for #1 and have a patch here[1]. This change can
> > > be moved into the docker container later to resolve your concerns about
> > > path changes.
> > >
> > > Unrelated to the specific change, there are two questions this raises
> > > which speak to the nature of our CI infra:
> > >
> > > 1. Why are docker build results not part of the verification for
> patchsets?
> > >
> > >If we don't provide feedback for docker builds (and also have the
> > >build/publish steps seperate) how will the community know when their
> > >Dockefile changes break builds?
> > >
> > > 2. How did the Docker build work for me locally but not on
> ericsson-build3?
> > >
> > >I've attached my build log and compared it to the last build[2], but
> > >no major differences jump out to me. The only differences I saw
> > >between the docker environments was a newer version of Go running on
> > >ericsson-build3.
> > >
> > > Regards,
> > > Trevor Bramwell
> > >
> > > [1] https://gerrit.opnfv.org/gerrit/#/c/36601/
> > > [2] https://build.opnfv.org/ci/job/releng-anteater-docker-
> > > build-push-master/14/console
> > >
> > > On Tue, Jun 27, 2017 at 01:50:15PM +0100, Luke Hinds wrote:
> > > > Hi,
> > > >
> > > > Patch [1] resulted in docker build failing due to a non root user not
> > > > having permissions to write to /usr/lib/python2.7, as seen in job
> [2]. To
> > > > address this I opened [3] and pushed patch [4] which implements a
> > > > virtualenv, but this now fails as the anteater path is not known.
> > > >
> > > > There are two ways to resolve this.
> > > >
> > > > 1. We hardcode the path to anteater in anteaters jjb scripts.
> > > > 2. We revert back to running docker as before (root) user.
> > > >
> > > > I guess 1 makes sense, but has some risk if the POSIX path were to
> > > change.
> > > > For '2' I am not opposed as I don't see any security risk running the
> > > > commands as root in the container. As I understand, this is a create
> /
> > > > destroy scenario with no data persisting in any volumes or pulled in
> > > > externally. Looking around others such as functest also run as root
> to
> > > > create their needed env.
> > > >
> > > > [1] https://gerrit.opnfv.org/gerrit/#/c/36325/
> > > > [2]
> > > > https://build.opnfv.org/ci/job/releng-anteater-docker-
> > > build-push-master/14/console
> > > > [3] https://jira.opnfv.org/browse/RELENG-260
> > > > [4] https://gerrit.opnfv.org/gerrit/#/c/36571
> > > > [5]
> > > > https://build.opnfv.org/ci/job/opnfv-security-audit-
> > > verify-master/133/console
> > > >
> > > > --
> > > > Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> > > > e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84
> |
> > > t: +44
> > > > 12 52 36 2483
> > >
> >
> >
> >
> > --
> > Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> > e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
> t: +44
> > 12 52 36 2483
>



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

Re: [opnfv-tech-discuss] [APEX] Apex virtual deployment install fails with error

2017-06-27 Thread Srikanth Vavilapalli

Hi Feng

I finally managed to bring up “os-nosdn-nofeature-noha” scenario using 
4.0-20170620 version RPMs. Initially I was able to login to undercloud and 
overcloud and create nova instances and neutron networks within overcloud. 
However, after keeping that setup idle for a day or two, I noticed that I am 
not able to login to those VMs anymore. I still have all the VMs running.

[root@jumphost2 vagrant]# virsh list --all
IdName   State

1 undercloud running
4 baremetal1 running
5 baremetal0 running
[root@jumphost2 vagrant]# sudo opnfv-util undercloud
ssh: Could not resolve hostname : Name or service not known

Seems like the reason for this error is there is no corresponding ARP entry to 
the MAC address of the undercloud/overcloud VMs in ARP table. For some reason, 
all the ARP entries on that hosts are in “incomplete” state (as shown below). 
Are u aware of any condition where we may hit this type of issue? Is there any 
way to recover from this state?

[root@jumphost2 vagrant]# arp -an
? (192.168.122.45) at  on virbr0
? (192.168.122.42) at  on virbr0
? (192.168.122.35) at  on virbr0
? (192.168.122.24) at  on virbr0
? (192.168.122.17) at  on virbr0
? (192.168.122.14) at  on virbr0
? (192.168.122.7) at  on virbr0
? (192.168.122.252) at  on virbr0
? (192.168.122.245) at  on virbr0
? (192.168.122.242) at  on virbr0
? (192.168.122.235) at  on virbr0
? (192.168.122.224) at  on virbr0
? (192.168.122.217) at  on virbr0
? (192.168.122.214) at  on virbr0
? (192.168.122.207) at  on virbr0
? (192.168.122.196) at  on virbr0
? (192.168.121.1) at 52:54:00:48:67:32 [ether] on eth0
? (192.168.122.49) at  on virbr0
? (192.168.122.46) at  on virbr0
? (192.168.122.39) at  on virbr0
? (192.168.122.28) at  on virbr0
? (192.168.122.21) at  on virbr0
? (192.168.122.18) at  on virbr0
? (192.168.122.11) at  on virbr0
? (192.168.122.249) at  on virbr0
? (192.168.122.246) at  on virbr0
? (192.168.122.239) at  on virbr0
? (192.168.122.228) at  on virbr0
? (192.168.122.221) at  on virbr0
? (192.168.122.218) at  on virbr0
? (192.168.122.211) at  on virbr0
? (192.168.122.200) at  on virbr0
? (192.168.122.193) at  on virbr0
? (192.168.122.190) at  on virbr0
? (192.168.122.50) at  on virbr0
? (192.168.122.43) at  on virbr0
? (192.168.122.32) at  on virbr0
? (192.168.122.25) at  on virbr0
? (192.168.122.22) at  on virbr0
? (192.168.122.15) at  on virbr0
? (192.168.122.4) at  on virbr0
? (192.168.122.253) at  on virbr0
? (192.168.122.250) at  on virbr0
? (192.168.122.243) at  on virbr0
? (192.168.122.232) at  on virbr0
? (192.168.122.225) at  on virbr0
? (192.168.122.222) at  on virbr0
? (192.168.122.215) at  on virbr0
? (192.168.122.204) at  on virbr0
? (192.168.122.197) at  on virbr0
? (192.168.122.194) at  on virbr0
? (192.168.122.47) at  on virbr0
? (192.168.122.36) at  on virbr0
? (192.168.122.29) at  on virbr0
? (192.168.122.26) at  on virbr0
? (192.168.122.19) at  on virbr0
? (192.168.122.8) at  on virbr0
? (192.168.122.254) at  on virbr0
? (192.168.122.247) at  on virbr0
? (192.168.122.236) at  on virbr0
? (192.168.122.229) at  on virbr0
? (192.168.122.226) at  on virbr0
? (192.168.122.219) at  on virbr0
? (192.168.122.208) at  on virbr0
? (192.168.122.201) at  on virbr0
? (192.168.122.198) at  on virbr0
? (192.168.122.191) at  on virbr0
? (192.168.122.51) at  on virbr0
? (192.168.122.40) at  on virbr0
? (192.168.122.33) at  on virbr0
? (192.168.122.30) at  on virbr0
? (192.168.122.23) at  on virbr0
? (192.168.122.12) at  on virbr0
? (192.168.122.5) at  on virbr0
? (192.168.122.2) at  on virbr0
? (192.168.122.251) at  on virbr0
? (192.168.122.240) at  on virbr0
? (192.168.122.233) at  on virbr0
? (192.168.122.230) at  on virbr0
? (192.168.122.223) at  on virbr0
? (192.168.122.212) at  on virbr0
? (192.168.122.205) at  on virbr0
? (192.168.122.202) at  on virbr0
? (192.168.122.195) at  on virbr0
? (192.168.122.44) at  on virbr0
? (192.168.122.37) at  on virbr0
? (192.168.122.34) at  on virbr0
? (192.168.122.27) at  on virbr0
? (192.168.122.16) at  on virbr0
? (192.168.122.9) at  on virbr0
? (192.168.122.6) at  on virbr0
? (192.168.122.244) at  on virbr0
? (192.168.122.237) at  on virbr0
? (192.168.122.234) at  on virbr0
? (192.168.122.227) at  on virbr0
? (192.168.122.216) at  on virbr0
? (192.168.122.209) at  on virbr0
? (192.168.122.206) at  on virbr0
? (192.168.122.199) at  on virbr0
? (192.168.122.48) at  on virbr0
? (192.168.122.41) at  on virbr0
? (192.168.122.38) at  on virbr0
? (192.168.122.31) at  on virbr0
? (192.168.122.20) at  on virbr0
? (192.168.122.13) at  on virbr0
? (192.168.122.10) at  on virbr0
? (192.168.122.3) at  on virbr0
? (192.168.122.248) at  on virbr0
? (192.168.122.241) at  on virbr0
? (192.168.122.238) at  on virbr0
? (192.168.122.231) at  on virbr0
? (192.168.122.220) at  on virbr0
? (192.168.122.213) at  on virbr0
? (192.168.122.210) at  on virbr0

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

2017-06-27 Thread Luke Hinds

Hi Trevor,

I am ok with going for #1

If should not really be me approving patches in releng, so will let the
other cores chime in.

For #2 I looked at your log and see what you mean. I cannot spot why a
normal user is allowed to install.

This is what I get when trying to install on my home PC (arch linux):

[Errno 13] Permission denied: '/usr/lib/python2.7/site-packages/

Regards,

Luke



On Tue, Jun 27, 2017 at 5:04 PM, Trevor Bramwell <
tbramw...@linuxfoundation.org> wrote:

> Hey Luke,
>
> I'm definitely opting for #1 and have a patch here[1]. This change can
> be moved into the docker container later to resolve your concerns about
> path changes.
>
> Unrelated to the specific change, there are two questions this raises
> which speak to the nature of our CI infra:
>
> 1. Why are docker build results not part of the verification for patchsets?
>
>If we don't provide feedback for docker builds (and also have the
>build/publish steps seperate) how will the community know when their
>Dockefile changes break builds?
>
> 2. How did the Docker build work for me locally but not on ericsson-build3?
>
>I've attached my build log and compared it to the last build[2], but
>no major differences jump out to me. The only differences I saw
>between the docker environments was a newer version of Go running on
>ericsson-build3.
>
> Regards,
> Trevor Bramwell
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/36601/
> [2] https://build.opnfv.org/ci/job/releng-anteater-docker-
> build-push-master/14/console
>
> On Tue, Jun 27, 2017 at 01:50:15PM +0100, Luke Hinds wrote:
> > Hi,
> >
> > Patch [1] resulted in docker build failing due to a non root user not
> > having permissions to write to /usr/lib/python2.7, as seen in job [2]. To
> > address this I opened [3] and pushed patch [4] which implements a
> > virtualenv, but this now fails as the anteater path is not known.
> >
> > There are two ways to resolve this.
> >
> > 1. We hardcode the path to anteater in anteaters jjb scripts.
> > 2. We revert back to running docker as before (root) user.
> >
> > I guess 1 makes sense, but has some risk if the POSIX path were to
> change.
> > For '2' I am not opposed as I don't see any security risk running the
> > commands as root in the container. As I understand, this is a create /
> > destroy scenario with no data persisting in any volumes or pulled in
> > externally. Looking around others such as functest also run as root to
> > create their needed env.
> >
> > [1] https://gerrit.opnfv.org/gerrit/#/c/36325/
> > [2]
> > https://build.opnfv.org/ci/job/releng-anteater-docker-
> build-push-master/14/console
> > [3] https://jira.opnfv.org/browse/RELENG-260
> > [4] https://gerrit.opnfv.org/gerrit/#/c/36571
> > [5]
> > https://build.opnfv.org/ci/job/opnfv-security-audit-
> verify-master/133/console
> >
> > --
> > Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> > e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
> t: +44
> > 12 52 36 2483
>



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

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

2017-06-27 Thread Trevor Bramwell

Hey Luke,

I'm definitely opting for #1 and have a patch here[1]. This change can
be moved into the docker container later to resolve your concerns about
path changes.

Unrelated to the specific change, there are two questions this raises
which speak to the nature of our CI infra:

1. Why are docker build results not part of the verification for patchsets?
   
   If we don't provide feedback for docker builds (and also have the
   build/publish steps seperate) how will the community know when their
   Dockefile changes break builds?

2. How did the Docker build work for me locally but not on ericsson-build3?

   I've attached my build log and compared it to the last build[2], but
   no major differences jump out to me. The only differences I saw
   between the docker environments was a newer version of Go running on
   ericsson-build3.

Regards,
Trevor Bramwell

[1] https://gerrit.opnfv.org/gerrit/#/c/36601/
[2] 
https://build.opnfv.org/ci/job/releng-anteater-docker-build-push-master/14/console

On Tue, Jun 27, 2017 at 01:50:15PM +0100, Luke Hinds wrote:
> Hi,
> 
> Patch [1] resulted in docker build failing due to a non root user not
> having permissions to write to /usr/lib/python2.7, as seen in job [2]. To
> address this I opened [3] and pushed patch [4] which implements a
> virtualenv, but this now fails as the anteater path is not known.
> 
> There are two ways to resolve this.
> 
> 1. We hardcode the path to anteater in anteaters jjb scripts.
> 2. We revert back to running docker as before (root) user.
> 
> I guess 1 makes sense, but has some risk if the POSIX path were to change.
> For '2' I am not opposed as I don't see any security risk running the
> commands as root in the container. As I understand, this is a create /
> destroy scenario with no data persisting in any volumes or pulled in
> externally. Looking around others such as functest also run as root to
> create their needed env.
> 
> [1] https://gerrit.opnfv.org/gerrit/#/c/36325/
> [2]
> https://build.opnfv.org/ci/job/releng-anteater-docker-build-push-master/14/console
> [3] https://jira.opnfv.org/browse/RELENG-260
> [4] https://gerrit.opnfv.org/gerrit/#/c/36571
> [5]
> https://build.opnfv.org/ci/job/opnfv-security-audit-verify-master/133/console
> 
> -- 
> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
> 12 52 36 2483
Sending build context to Docker daemon 557.1 kB
Sending build context to Docker daemon 1.114 MB
Sending build context to Docker daemon 1.671 MB
Sending build context to Docker daemon 2.228 MB
Sending build context to Docker daemon 2.387 MB

Step 1 : FROM centos:latest
 ---> 3bee3060bfc8
Step 2 : MAINTAINER Luke Hinds 
 ---> Running in 3e11fd6f84ad
 ---> 2944e8e383ac
Removing intermediate container 3e11fd6f84ad
Step 3 : LABEL version "0.1" description "Anteater - OPNFV Gerrit Security Gate 
Checks"
 ---> Running in bf54a2254494
 ---> e79b0ed24b8e
Removing intermediate container bf54a2254494
Step 4 : ARG BRANCH=master
 ---> Running in a73f88a89aeb
 ---> 6fcb680e9870
Removing intermediate container a73f88a89aeb
Step 5 : ARG ANTEATER_USER=opnfv
 ---> Running in ac164ca9a605
 ---> db37c87201b9
Removing intermediate container ac164ca9a605
Step 6 : RUN useradd -U -m -s /bin/bash ${ANTEATER_USER}
 ---> Running in b08b1be8adce
 ---> 69b9edd3438d
Removing intermediate container b08b1be8adce
Step 7 : ENV HOME /home/${ANTEATER_USER}
 ---> Running in 7e787bb71210
 ---> 38ede80cdfdd
Removing intermediate container 7e787bb71210
Step 8 : ENV ANTEATER_HOME ${HOME}/anteater
 ---> Running in 32e5b6070b13
 ---> 4b734b100bb7
Removing intermediate container 32e5b6070b13
Step 9 : RUN yum -y install epel-release
 ---> Running in cee33ef966ac
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
 * base: mirrors.kernel.org
 * extras: centos.sonn.com
 * updates: ftp.osuosl.org
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-9 will be installed
--> Finished Dependency Resolution

Dependencies Resolved


 PackageArch Version RepositorySize

Installing:
 epel-release   noarch   7-9 extras14 k

Transaction Summary

Install  1 Package

Total download size: 14 k
Installed size: 24 k
Downloading packages:
[91mwarning: 
/var/cache/yum/x86_64/7/extras/packages/epel-release-7-9.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
[0mPublic key for epel-release-7-9.noarch.rpm is not installed
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
[91mImporting GPG key 0xF4A80EB5:
 Userid : "CentOS-7 Key (CentOS 7 Official Signing Key)

[opnfv-tech-discuss] Weekly Technical Discussion #93

2017-06-27 Thread HU, BIN

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="HU, BIN":MAILTO:bh5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:https://global.gotomeeting.com/join/819733085\n+
 1 (312) 757-3126 / Access Code: 819-733-085\n\nHello\,\n\nThis is our 93rd
  weekly technical discussion at 6am PDT / 9am EDT Thursday June 29th\, 201
 7\, which is 13:00 UTC.\n\nWe will discuss OPNFV Testing Strategy by Morgan Richomme.\n\nYou can find your
  local time here http://www.timeanddate.com/worldclock/fixedtime.html?msg=
 OPNFV-Technical-Discussion=20170629T13=1.\n\nPlease refer to https:
 //wiki.opnfv.org/display/PROJ/Weekly+Technical+Discussion for details of d
 ialing logistics and tentative agenda.\n\nPlease let me know if you want t
 o add anything to agenda for discussion in the community.\n\nFor your conv
 enience:\n-   GoTo Meeting: https://global.gotomeeting.com/join/819733
 085\n-   You can also dial in using your phone:\no   United States
  (Long distance): +1 (312) 757-3126 / Access Code: 819-733-085\no   Mo
 re phone numbers: https://global.gotomeeting.com/819733085/numbersdisplay.
 html\n\nThanks\nBin\n\n\n
SUMMARY;LANGUAGE=en-US:Weekly Technical Discussion #93
DTSTART;TZID=Pacific Standard Time:20170629T06
DTEND;TZID=Pacific Standard Time:20170629T07
UID:04008200E00074C5B7101A82E008108122D2AAEBD201000
 0100033BA62D20DB93246B852CE5074B1FEFC
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170627T151432Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:2
LOCATION;LANGUAGE=en-US: +1 (312) 757-3126 / Access Code: 819-733-085
X-MICROSOFT-CDO-APPT-SEQUENCE:2
X-MICROSOFT-CDO-OWNERAPPTID:538339297
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Infra] Laas wiki page updates on OPNFV+ONAP

2017-06-27 Thread SULLIVAN, BRYAN L

Hi all,

I updated the page https://wiki.opnfv.org/display/INF/Lab+as+a+Service with 
additional use cases and updated diagrams for the two main classes of use cases:
* Use Case: OPNFV Developer Access to On-Demand POD
* Use Case: ONAP Developer Access to On-Demand OPNFV+ONAP POD

Unless there's a lot of comment on the lab sharing proposal for OPNFV+ONAP, I 
recommend that we verify internal consensus on it and give someone the action 
item to take this to ONAP as a concrete proposal, for their feedback. I think 
that role (reaching out to ONAP) would be best taken on by someone most active 
in the Infra team. 

It's also possible that OPNFV would not be able to achieve this without some 
OPNFV/LF-sponsored developer resources (e.g. intern or contractor). I do not 
assume the development/maintenance of this capability with be fully 
contribution-driven, especially from the currently overworked Infra team. But 
if there's OPNFV consensus on the value (or really, essential nature) of 
offering ability of ONAP developers to access various OPNFV scenarios as part 
of their ONAP developer experience, OPNFV should make this happen one way or 
another.

Thanks,
Bryan Sullivan | AT

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

[opnfv-tech-discuss] [SFC] stepping down as committer

2017-06-27 Thread Paul Quinn (paulq)

Hi,

I haven't been active in OPNFC SFC in some time and would like to step down as 
a committer.

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

[opnfv-tech-discuss] [infra] Docker changes in Anteater

2017-06-27 Thread Luke Hinds

Hi,

Patch [1] resulted in docker build failing due to a non root user not
having permissions to write to /usr/lib/python2.7, as seen in job [2]. To
address this I opened [3] and pushed patch [4] which implements a
virtualenv, but this now fails as the anteater path is not known.

There are two ways to resolve this.

1. We hardcode the path to anteater in anteaters jjb scripts.
2. We revert back to running docker as before (root) user.

I guess 1 makes sense, but has some risk if the POSIX path were to change.
For '2' I am not opposed as I don't see any security risk running the
commands as root in the container. As I understand, this is a create /
destroy scenario with no data persisting in any volumes or pulled in
externally. Looking around others such as functest also run as root to
create their needed env.

[1] https://gerrit.opnfv.org/gerrit/#/c/36325/
[2]
https://build.opnfv.org/ci/job/releng-anteater-docker-build-push-master/14/console
[3] https://jira.opnfv.org/browse/RELENG-260
[4] https://gerrit.opnfv.org/gerrit/#/c/36571
[5]
https://build.opnfv.org/ci/job/opnfv-security-audit-verify-master/133/console

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

Re: [opnfv-tech-discuss] [dovetail] Email vote on merge of SDNVPN test cases

2017-06-27 Thread Lincoln Lavoie

+1

On Tue, Jun 27, 2017 at 1:33 AM, Zenghui Shi  wrote:

> +1
>
> zenghui
>
> On Mon, Jun 26, 2017 at 4:34 PM, Georg Kunz 
> wrote:
>
>> Hi Dovetailers,
>>
>>
>>
>> You are all well aware of the accidental merge of the SDNVPN test case
>> scope and description [1] without a +1 vote from a majority of the
>> committers. We have discussed how to handle this already a few times, but
>> we have not yet reached an officially documented conclusion. Since I caused
>> the mishap, I’d like to work towards a clean resolution of the situation by
>> calling for an official vote. We couldn’t have a vote on IRC during the
>> last call due to a lack of quorum, so we agreed to move to an email-based
>> vote.
>>
>>
>>
>> There are basically two options for resolving situation:
>>
>>
>>
>> i)Revert the merged patchset. This includes creating
>> an inverse patchset which again needs to be voted on by committers in order
>> to get it merged
>>
>> ii)   Approve the patchset post-merge
>>
>>
>>
>> There are currently 9 committers in Dovetail. I won’t vote myself for
>> obvious reasons. So, I propose the following procedure:
>>
>>
>>
>> Please cast your vote on the following question:
>>
>>
>>
>> “Do the Dovetail committers approve the merge of the SDNVPN test case
>> scope and description [patchset 34343]? (-1, 0, +1)”
>>
>>
>>
>> If at least 5 committers (not counting myself) vote +1, the patchset is
>> considered approved and we’ll keep it. If less than 5 committers vote +1 or
>> there are -1 votes, I’ll prepare an inverse patch.
>>
>>
>>
>> [1] https://gerrit.opnfv.org/gerrit/#/c/34343/
>>
>>
>>
>> Sorry for causing extra effort.
>>
>>
>>
>> Thanks,
>>
>> Georg
>>
>> ___
>> 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
>
>


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


www.iol.unh.edu
21 Madbury Rd., Ste. 100, Durham, NH 03824
Mobile: +1-603-674-2755
lylav...@iol.unh.edu
   


Ars sine scientia nihil est! -- Art without science is nothing.
Scientia sine ars est vacua! -- Science without art is empty.
***
___
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] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

2017-06-27 Thread morgan.richomme

Hi,

my view is that the difficulty we have to converge to a clear consensus 
is directly linked to what we are producing

I fully agree with Fatih's comment on the mail 
https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-June/016799.html
Second release had probably the best quality in term of release, since 
the second release we deal with a wild rush forward "more everything" 
and releases are somehow snapshots of current scenarios more or less 
(usely less) tested - that is one of the reasons why the testing group 
is proposing a new way for resiliency/stress testing - discussion 
planned during the TSC meeting today -

So it is not surprising to see several interpretations of what 
certification should be.

If we were able to say clearly "an OPNFV release is X, Y and Z" it would 
be much easier.
But we are dealing with a composite object with lots of possible 
combinations, features (even mature ones) have installer/scenario 
constraints.

The second difficult point I see then is that due to the complexity of 
the combinations, we reduced the initial scope, which is fine, but then 
the question of the delta compared to OpenStack can be raised.
Adding features that are supported only by a subset of 
installers/scenarios is a way to differentiate but as it is only a 
subset, does it make sense to consider it for an OPNFV certification?

CVP WG and Dovetail projects have been working hard for a long time and 
the last proposal is surely the best we can have regarding the context 
if we consider OPNFV as a product but is it a product?

If we consider OPNFV as a framework and want to focus on NFVI/VIM, 
running yardstick and be sure that the NFVI reached all the defined SLAs 
makes sense for me.
In Brahmaputra we were able to successfully test the deployment of a 
vIMS on several scenarios/installers (more than 1000 CI run done), this 
test case was complete to test VIM/NFVI and went far beyond a check of 
the OpenStack API/Interface.
Since Colorado due to the problem mentioned earlier it is unfortunately 
not so stable and it was poorly tested in Danube (wait for a weekly job 
we were not able to reach / test/scenario promotion, trust indicator,...)

/Morgan

On 27/06/2017 01:46, Wenjing Chu wrote:

I updated the document wiki page with the scope summarized in this 
email and the latest test spec documents: 
https://wiki.opnfv.org/display/dovetail/Dovetail+Documentation+for+Review.

Is there any other feedback from tsc members?

Tapio,
I'll be on the tsc call tomorrow to answer any questions about the 
proposal. Can we have some time on the agenda? Thanks.

Wenjing

On Fri, Jun 23, 2017 at 2:50 AM, Tim Irnich > wrote:

Hi Dave, all,

Sorry for misunderstanding your point. In that case, is there any
other feedback from other TSC members on the proposal?

Tapio & Ray, I think we should reserve some time in next week's
TSC to go over the suggested test scope (both mandatory and
optional parts) for Danube compliance testing once more so that
the Dovetail team can be confident about focusing on the right things.

Regards, Tim

-Original Message-
From: Dave Neary [mailto:dne...@redhat.com ]
Sent: Wednesday, June 21, 2017 01:53
To: Tim Irnich >; Wenjing Chu
>;
Christopher Price >; Tianhongbo
>; Tallgren, Tapio
>; Georg
Kunz >
Cc: TSC OPNFV >; TECH-DISCUSS OPNFV
>
Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and
DoveTail meeting to discuss scope and needs for CVP testing

Hi Tim,

On 06/20/2017 09:02 PM, Tim Irnich wrote:
>> I would like to see us document some of the NFV related
requirements
>> which are common across all RFCs from telcos, and which are
available
>> in all viable VIM products.
>
> This is exactly the intention of the proposal, under the side
> constraint of drawing from already existing tests. The question
to the
> TSC was if this is enough for an initial release. I think your
answer is no.

On the contrary - the initial release scope is fine, my comment
was on the "future plans" piece.

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

Re: [opnfv-tech-discuss] [fuel][plugins][odl] HA for ODL Controller in OpenStack

2017-06-27 Thread Michael Polenchuk

Hi,

Fuel ODL plugin supports only one odl controller.
ODL driver could be opted via UI settings of plugin.
There are no plans to continue developing of this plugin but ... HA feature
will be in MCP/Ocata soon.


On Sun, Jun 25, 2017 at 2:36 PM, Raúl Alvarez Pinilla <
ralva...@walhalladcs.com> wrote:

> Hi all,
>
> I am testing OpenDaylight Plugin with Fuel 10.0 (Newton) and I have
> noticed that you cannot create several ODL controllers in the same
> environment, only it is possible to create only one ODL controller.
>
> Currently, with this plugin version, which version of ODL Driver is it
> used? v1? v2? I am asking this because it seems that with v2 you can handle
> several ODL controllers with HAProxy, am I right? Is there technical
> documentation to deploy manually this feature?
>
> I would like to know if it is planned to continue developing this plugin
> with OpenStack Ocata and resolve this HA limitation. With other installer
> (Compass, TripleO, Juju) this feature is available?
>
> Thank you very much.
>
> Best regards,
> [image: logowalhalladcs]
> *Raúl Álvarez Pinilla*
>
> ralva...@walhalladcs.com www.walhalladcs.com
>
> --
> *Nota Legal*: Este correo electronico puede contener informacion
> estrictamente confidencial y es de uso exclusivo del destinatario, quedando
> prohibida a cualquier otra persona su revelacion, copia, distribucion, o el
> ejercicio de cualquier accion relativa a su contenido. Si ha recibido este
> correo electronico por error, por favor, conteste al remitente, y
> posteriormente proceda a borrarlo de su sistema. Gracias por su
> colaboracion.
>
> *Confidentiality notice*: This e-mail message may contain confidential
> and/or legally privileged information and is solely for the attention and
> use of the intended recipient. Any disclosure, copying, distribution or the
> taking of any action with relation to the contents of this e-mail by any
> other person is strictly prohibited. If you believe that this e-mail has
> been mistakenly sent to you, please reply to the sender from whom you
> received the message in error and then delete the original e-mail from your
> system. Thank you for your co-operation.
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>


-- 
  Michael Polenchuk
  Private Cloud / Mirantis Inc.
___
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] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

2017-06-27 Thread Christopher Price

Hi Folks,

Did we come to any conclusions on a couple of outstanding points that come to 
my mind as things to come to decisions on as they establish our technical scope:
1) Is it OK for instance that test cases only evaluate API responses?  I am 
thinking of suites like the IPv6 where we do not pass any IPv6 traffic in the 
system as part of our compliance suite at this time.
2) Do we intend to document the inherited test cases for RefStack?  If not, and 
we are not curating those tests in any way ourselves, maybe we should pull them 
out as explicit tests cases and refer instead to the RefStack documentation and 
infer that we expect RefStack to be passed on an OPNFV deployed system as a 
pre-requisite.  
We need a clear way of handling those test cases, either we curate them 
ourselves or we have a clear agreement with the OpenStack interop WG on how we 
leverage that suite.  At this time we list an own curated version but provide 
no documentation of the test cases, why they were selected and the procedure 
for selection.

Cheers,
Chris

On 2017-06-23, 11:50, "Tim Irnich"  wrote:

Hi Dave, all,

Sorry for misunderstanding your point. In that case, is there any other 
feedback from other TSC members on the proposal?

Tapio & Ray, I think we should reserve some time in next week's TSC to go 
over the suggested test scope (both mandatory and optional parts) for Danube 
compliance testing once more so that the Dovetail team can be confident about 
focusing on the right things.

Regards, Tim

-Original Message-
From: Dave Neary [mailto:dne...@redhat.com]
Sent: Wednesday, June 21, 2017 01:53
To: Tim Irnich ; Wenjing Chu 
; Christopher Price ; 
Tianhongbo ; Tallgren, Tapio 
; Georg Kunz 
Cc: TSC OPNFV ; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail 
meeting to discuss scope and needs for CVP testing

Hi Tim,

On 06/20/2017 09:02 PM, Tim Irnich wrote:
>> I would like to see us document some of the NFV related requirements
>> which are common across all RFCs from telcos, and which are available
>> in all viable VIM products.
>
> This is exactly the intention of the proposal, under the side
> constraint of drawing from already existing tests. The question to the
> TSC was if this is enough for an initial release. I think your answer is 
no.

On the contrary - the initial release scope is fine, my comment was on the 
"future plans" piece.

Thanks,
Dave.

--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

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

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

[opnfv-tech-discuss] Updated Invitation: OPNFV Release Meeting (ASIA) - IRC Only @ Every 2 weeks from 7:30pm to 8pm on Tuesday (PST) (opnfv-tech-discuss@lists.opnfv.org)

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

[opnfv-tech-discuss] UK / London OPNFV meetup

Re: [opnfv-tech-discuss] [test-wg] [OPNFV] Draft support for presentation to TSC

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

Re: [opnfv-tech-discuss] [APEX] Apex virtual deployment install fails with error

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

Re: [opnfv-tech-discuss] [infra] Docker changes in Anteater

[opnfv-tech-discuss] Weekly Technical Discussion #93

[opnfv-tech-discuss] [Infra] Laas wiki page updates on OPNFV+ONAP

[opnfv-tech-discuss] [SFC] stepping down as committer

[opnfv-tech-discuss] [infra] Docker changes in Anteater

Re: [opnfv-tech-discuss] [dovetail] Email vote on merge of SDNVPN test cases

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

Re: [opnfv-tech-discuss] [fuel][plugins][odl] HA for ODL Controller in OpenStack

Re: [opnfv-tech-discuss] [opnfv-tsc] [dovetail] TSC and DoveTail meeting to discuss scope and needs for CVP testing

18 matches

Site Navigation

Mail list logo

Footer information