[opnfv-tech-discuss] [dovetail]New dovetail.cvp.0.4.0 draft release notes

[Tianhongbo]

Hi all:

Continue to update the dovetail dovetail.cvp test suite。

As you may have noticed, we have started to prepare weekly TAGs for the draft 
dovetail.cvp test suite, and the latest this week is 0.4.0. The "User Guide" 
document draft has also been updated to reflect the changes. 
http://artifacts.opnfv.org/dovetail/docs/testing_user_userguide/index.html。

If you are testing with dovetail or keeping an eye on its progress, please 
refer to the latest software and info. We will continue to update in this way 
in a week fashion going forward. Let us know if you have any feedback in any 
part of the draft artifacts/software or process.

Regards
Hongbo

dovetail cvp.0.4.0 release notes
1. docker images used:
opnfv/dovetail:cvp.0.4.0 (commit ID a8d7665ca783684bc10d7c3dbbc606e30f083bc7)
opnfv/yardstick:danube.3.1
opnfv/functest:cvp.0.2.0 (commit ID 3d03bbcfc45d00d4ce995d8aabff5808accb0687)
opnfv/testapi:cvp.0.4.0
opnfv/bottlenecks:cvp.0.4.0 (commit ID 3592f9016821a603930ebda7f4112abf732e6750)
2. changes compared to cvp.0.3.0

2.1  opnfv/dovetail:cvp.0.4.0 mainly changes compared to cvp.0.3.0

1)Add docs about vping test cases (test scope and test specification)
https://gerrit.opnfv.org/gerrit/#/c/36253/

2)Add 2 vping test cases (vping.tc001->vping_userdata, 
vping.tc002->vping_ssh) into proposed_tests
JIRA: DOVETAIL-446 
https://gerrit.opnfv.org/gerrit/#/c/37853/

3)Bugfix: Build docker image failed because of lacking of packages
JIRA: DOVETAIL-475 
https://gerrit.opnfv.org/gerrit/#/c/38573/

4)Add resiliency.tc001 into proposed_tests
JIRA: DOVETAIL-474 
https://gerrit.opnfv.org/gerrit/#/c/38713/

2.2  For Functest, still use opnfv/functest:cvp.0.2.0, nothing changed

2.3  For Yardstick, still use opnfv/yardstick:danube.3.1, nothing changed

2.4  opnfv/testapi:cvp.0.4.0 mainly changes compared to opnfv/testapi:cvp.0.3.0

1)Add Linux Foundation ID as account provider

2)Upload multi results in one time

3)Submit results to CVP to review

4)Results are grouped by test id

5)Add details for each test

2.5  opnfv/bottlenecks:cvp.0.4.0


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

[opnfv-tech-discuss] SampleVNF Weekly meeting (Re-scheduled)

[S, Deepak]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:India Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="S, Deepak":MAILTO:deepa...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='opnfv-tec
 h-disc...@lists.opnfv.org':MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Jindal, So
 nika":MAILTO:sonika.jin...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Jyoti, Ana
 nd B":MAILTO:anand.b.jy...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='fbrockne@
 cisco.com':MAILTO:'fbroc...@cisco.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='shang.xia
 od...@zte.com.cn':MAILTO:'shang.xiaod...@zte.com.cn'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Deepak S 
 (Intel,'":MAILTO:deepa...@linux.intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rudramuni,
  Vishwesh M":MAILTO:vishwesh.m.rudram...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Narayan, B
 indya":MAILTO:bindya.nara...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Gunaseela
 n Venkatachary (HCL,'":MAILTO:gunaseel...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Anandaram
 an Viswanathan (HCL,'":MAILTO:anandaram...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Rajaraman
  Balasubramanian (HCL,'":MAILTO:rajarama...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ramia, Kan
 nan Babu":MAILTO:kannan.babu.ra...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Vasantha 
 kumar Godithi (HCL,'":MAILTO:vasanthakum...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bob Monkm
 an':MAILTO:bob.monk...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Elzur, Uri"
 :MAILTO:uri.el...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Vul, Alex":
 MAILTO:alex@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Marco Var
 lese':MAILTO:marco.varl...@suse.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Andrew Ve
 itch':MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kedalagudd
 e, Meghashree Dattatri":MAILTO:meghashree.dattatri.kedalagu...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Shai Tsur
 ':MAILTO:shai.t...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lawrence 
 Lamers':MAILTO:ljlam...@vmware.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Maria Toe
 roe':MAILTO:maria.toe...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'GUPTA, AL
 OK'":MAILTO:ag1...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Pierre Ly
 nch':MAILTO:ply...@ixiacom.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Cathy Zha
 ng':MAILTO:cathy.h.zh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Canio Cil
 lis':MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Seiler, Gl
 enn (Wind River)":MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ahmed Elb
 ornou (amaged)':MAILTO:ama...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Gabor Hal
 ász':MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Alan McNa
 mee':MAILTO:alan...@openet.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='yunchao h
 u':MAILTO:yunchao...@huawei.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Shobhan A
 yyadevaraSesha (sayyadev)':MAILTO:sayya...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Carlos Br
 avo':MAILTO:carlos.br...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bathula, N
 avyaX":MAILTO:navyax.bath...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Nadathur, 
 Sundar":MAILTO:sundar.nadat...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Paladugula
 , ShravaniX":MAILTO:shravanix.paladug...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Yerrumsett
 y, RajithaX":MAILTO:rajithax.yerrumse...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Gundarapu,
  ReddyX":MAILTO:reddyx.gundar...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pavan.gupt
 a...@c

Re: [opnfv-tech-discuss] [OPNFV Helpdesk #43942] RE: [barometer] contributor promotion

[Aric Gardner via RT]

Hi Maryam,

I will send them all invites.

-Aric


On Fri, Aug 4, 2017 at 12:05 PM, maryam.tah...@intel.com via RT
 wrote:
>
> Fri Aug 04 12:05:02 2017: Request 43942 was acted upon.
>  Transaction: Ticket created by maryam.tah...@intel.com
>Queue: OPNFV Helpdesk
>  Subject: RE: [barometer] contributor promotion
>Owner: Nobody
>   Requestors: maryam.tah...@intel.com
>   Status: new
>  Ticket https://rt.linuxfoundation.org/Ticket/Display.html?id=43942 >
>
>
> Hello TSC
> With a majority vote of 2 to 0 (out of the current barometer committers). The 
> following folks have been successfully nominated as project committers for 
> barometer.
>
> Al Morton acmor...@att.com
> Aaron Smith aasm...@redhat.com
> Emma Foley emma.l.fo...@intel.com
> Calin Gherghe Gherghe, Calin 
>
> Al and Aaron have contributed greatly with requirements, guidance, code 
> reviews and ETSI alignment
> Emma has been our main OpenStack plugin integrator and developer. And Calin 
> is our functest expert.
>
> Aric, can you make sure these folks get committer rights, and I will update 
> the INFO file as well as the project wiki?
>
> Thanks in advance
> Maryam
>
>
>> -Original Message-
>> From: Richardson, Bruce
>> Sent: Friday, August 4, 2017 4:55 PM
>> To: Tahhan, Maryam ; opnfv-tech-
>> disc...@lists.opnfv.org; thomas.monja...@6wind.com
>> Cc: Gherghe, Calin 
>> Subject: RE: [barometer] contributor promotion
>>
>>
>>
>> > -Original Message-
>> > From: Tahhan, Maryam
>> > Sent: Friday, August 4, 2017 4:53 PM
>> > To: opnfv-tech-discuss@lists.opnfv.org; Richardson, Bruce
>> > ; thomas.monja...@6wind.com
>> > Cc: Gherghe, Calin 
>> > Subject: [barometer] contributor promotion
>> >
>> > Hi barometer committers,
>> > I would like to nominate the following folks to be promoted from
>> > barometer contributors to barometer committers, can you please reply with
>> your vote.
>> >
>> > Al Morton acmor...@att.com
>> > Aaron Smith aasm...@redhat.com
>> > Emma Foley emma.l.fo...@intel.com
>> > Calin Gherghe Gherghe, Calin 
>> >
>> > My vote is +1.
>> >
>> +1
>

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

[opnfv-tech-discuss] [Auto] Seeking input to the Auto project creation review

[SULLIVAN, BRYAN L (BRYAN L)]

FYI I added a summary of the points below to the Auto project proposal at 
https://wiki.opnfv.org/pages/viewpage.action?pageId=12387216

The Auto project supporters would like to get started ASAP on the project’s 
goals. While in principle I think the consensus is that a combined project 
(Opera+Auto) has some potential advantages, we would need to address the 
questions as noted on the wiki, as:

  *   The Opera project may not get re-started with the necessary resources to 
complete the Open-O to ONAP transition, or at least soon enough. The Auto 
project supporters would thus like to proceed with minimal (as possible) 
dependency upon the evolved Opera project plans in the F release.
  *   We may find that the technical approach to ONAP integration (e.g. how are 
the components deployed and integrated into tests) varies, for the different 
purposes of (1) deploying ONAP as a platform component on OPNFV PODs (Opera 
project scope), and (2) verifying specific ONAP component interop with OPNFV 
generic or scenario-specific features.

If we can’t resolve the key question here soon enough (what are the Opera 
project’s plans for the F release, e.g. who Is committed to support that work 
and is that enough for success), we may just delay efforts to get organized 
around the Auto projects’ goals for the F release.

I expect this to be a topic on this week’s TSC call (part of the creation 
review), and I request that anyone with an opinion on this (especially those 
that intend to support Auto or Opera in the F release) to provide input via 
this thread ahead of the call.

Thanks,
Bryan Sullivan | AT&T

From: SULLIVAN, BRYAN L
Sent: Thursday, August 03, 2017 8:19 AM
To: 'Yunxia Chen' mailto:helen.c...@huawei.com>>; 'Tina 
Tsou' mailto:tina.t...@arm.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [OPNFV confluence] Ulrich Kleber mentioned you on "Tc Agenda 
20170803"

Helen,

We had a discussion today on the takeaways from the call yesterday, to try to 
come to a broader consensus on the plan for how to achieve the Auto project’s 
proposed scope and the Opera project’s scope for F (ONAP integration). Here are 
the key questions I recommended we discuss over email before the TSC meeting:

  1.  As noted by Uli there may be a dependency of Auto on Opera. What Opera 
project resources (developers) will be available in F to complete the ONAP 
integration (the “ONAP integration team” as I refer to them below)?
 *   In Auto we had not planned to necessarily deploy ONAP as a complete 
platform, but rather if possible to deploy the components that are needed to 
test the interop use cases in Auto’s scope.
 *   If we find that approach (partial ONAP install) is infeasible/unable 
to meet our goals, we will depend upon a complete ONAP platform install 
instead, either through Opera or as described for the LaaS proposal integrating 
ONAP and OPNFV into a multi-lab testbed 
environment. In this case, 
who from the Opera team would be available to work with us on one of those 
approaches?
  2.  My overall recommendation is to keep the project overhead low, progress 
agile, and the approach flexible. Given ability to meet those goals, I don’t 
care where the work is done. Here are some questions that will help us in the 
decision per those goals:
 *   Can a combined project be organized as multiple, potentially loosely 
connected tracks?

   i.  We need 
regular project meetings in order to make rapid progress. Would the ONAP 
integration team prefer to have their own meetings? Although we know there was 
a lot of work done on Open-O integration, we don’t see a lot of record of those 
meetings on the wiki etc. That’s OK, if the team (e.g. led by Harry) can 
deliver ONAP integration without a lot of involvement from the Auto project 
team (mostly US based). We want people to work the way they need to, to be 
successful. But given that we would still need calls for the progress on Auto 
scope, would you have any concerns that we have at least two tracks in the 
combined project?

 *   Here is how I view the three (at least) distinct focuses in the 
overall project. These will likely require different developers with different 
skill sets. Who will be available to support the first two?

   i.  ONAP 
integration per current Opera: OPNFV installer support (if needed), or 
post-deploy install process (preferred)

 ii.  VNF use 
case integration into Functest etc, ala vIMS, vCPE, etc

   iii.  detailed 
functional interop test cases per the Auto proposal, using the Opera-installed 
ONAP, or discrete ONAP component install tools, or the cross-lab LaaS as above

   

[opnfv-tech-discuss] [Auto] Seeking input to the Auto project creation review

[SULLIVAN, BRYAN L (BRYAN L)]

FYI I added a summary of the points below to the Auto project proposal at 
https://wiki.opnfv.org/pages/viewpage.action?pageId=12387216

The Auto project supporters would like to get started ASAP on the project’s 
goals. While in principle I think the consensus is that a combined project 
(Opera+Auto) has some potential advantages, we would need to address the 
questions as noted on the wiki, as:

  *   The Opera project may not get re-started with the necessary resources to 
complete the Open-O to ONAP transition, or at least soon enough. The Auto 
project supporters would thus like to proceed with minimal (as possible) 
dependency upon the evolved Opera project plans in the F release.
  *   We may find that the technical approach to ONAP integration (e.g. how are 
the components deployed and integrated into tests) varies, for the different 
purposes of (1) deploying ONAP as a platform component on OPNFV PODs (Opera 
project scope), and (2) verifying specific ONAP component interop with OPNFV 
generic or scenario-specific features.

If we can’t resolve the key question here soon enough (what are the Opera 
project’s plans for the F release, e.g. who Is committed to support that work 
and is that enough for success), we may just delay efforts to get organized 
around the Auto projects’ goals for the F release.

I expect this to be a topic on this week’s TSC call (part of the creation 
review), and I request that anyone with an opinion on this (especially those 
that intend to support Auto or Opera in the F release) to provide input via 
this thread ahead of the call.

Thanks,
Bryan Sullivan | AT&T

From: SULLIVAN, BRYAN L
Sent: Thursday, August 03, 2017 8:19 AM
To: 'Yunxia Chen' ; 'Tina Tsou' 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [OPNFV confluence] Ulrich Kleber mentioned you on "Tc Agenda 
20170803"

Helen,

We had a discussion today on the takeaways from the call yesterday, to try to 
come to a broader consensus on the plan for how to achieve the Auto project’s 
proposed scope and the Opera project’s scope for F (ONAP integration). Here are 
the key questions I recommended we discuss over email before the TSC meeting:

  1.  As noted by Uli there may be a dependency of Auto on Opera. What Opera 
project resources (developers) will be available in F to complete the ONAP 
integration (the “ONAP integration team” as I refer to them below)?
 *   In Auto we had not planned to necessarily deploy ONAP as a complete 
platform, but rather if possible to deploy the components that are needed to 
test the interop use cases in Auto’s scope.
 *   If we find that approach (partial ONAP install) is infeasible/unable 
to meet our goals, we will depend upon a complete ONAP platform install 
instead, either through Opera or as described for the LaaS proposal integrating 
ONAP and OPNFV into a multi-lab testbed 
environment. In this case, 
who from the Opera team would be available to work with us on one of those 
approaches?
  2.  My overall recommendation is to keep the project overhead low, progress 
agile, and the approach flexible. Given ability to meet those goals, I don’t 
care where the work is done. Here are some questions that will help us in the 
decision per those goals:
 *   Can a combined project be organized as multiple, potentially loosely 
connected tracks?

   i.  We need 
regular project meetings in order to make rapid progress. Would the ONAP 
integration team prefer to have their own meetings? Although we know there was 
a lot of work done on Open-O integration, we don’t see a lot of record of those 
meetings on the wiki etc. That’s OK, if the team (e.g. led by Harry) can 
deliver ONAP integration without a lot of involvement from the Auto project 
team (mostly US based). We want people to work the way they need to, to be 
successful. But given that we would still need calls for the progress on Auto 
scope, would you have any concerns that we have at least two tracks in the 
combined project?

 *   Here is how I view the three (at least) distinct focuses in the 
overall project. These will likely require different developers with different 
skill sets. Who will be available to support the first two?

   i.  ONAP 
integration per current Opera: OPNFV installer support (if needed), or 
post-deploy install process (preferred)

 ii.  VNF use 
case integration into Functest etc, ala vIMS, vCPE, etc

   iii.  detailed 
functional interop test cases per the Auto proposal, using the Opera-installed 
ONAP, or discrete ONAP component install tools, or the cross-lab LaaS as above

 *   There will be multiple (in detail) ways to (1) deploy ONAP; (2) manage 
VNFs using it. While a 

Re: [opnfv-tech-discuss] [Auto] Seeking input to the Auto project creation review

[Yunxia Chen]

Sorry Bryan I missed your initial emails. Please see comments inline.

Regards,

Helen Chen

From: "SULLIVAN, BRYAN L (BRYAN L)" 
Date: Monday, August 7, 2017 at 10:41 AM
To: "opnfv-...@lists.opnfv.org" 
Cc: "'opnfv-tech-discuss@lists.opnfv.org'" 
, Helen Chen 00725961 
, Tina Tsou 
Subject: [Auto] Seeking input to the Auto project creation review

FYI I added a summary of the points below to the Auto project proposal at 
https://wiki.opnfv.org/pages/viewpage.action?pageId=12387216

The Auto project supporters would like to get started ASAP on the project’s 
goals. While in principle I think the consensus is that a combined project 
(Opera+Auto) has some potential advantages, we would need to address the 
questions as noted on the wiki, as:

  1.  The Opera project may not get re-started with the necessary resources to 
complete the Open-O to ONAP transition, or at least soon enough. The Auto 
project supporters would thus like to proceed with minimal (as possible) 
dependency upon the evolved Opera project plans in the F release.
[HELEN] We currently have Huawei, China Mobile committed. Potentially we will 
have Orange, ZTE, and hopefully AT&T as well in this project. But right now, 
since we don’t have ANY stable ONAP image yet, we are focusing on a successful 
ONAP release. (Hope this make sense to you)

  1.  We may find that the technical approach to ONAP integration (e.g. how are 
the components deployed and integrated into tests) varies, for the different 
purposes of (1) deploying ONAP as a platform component on OPNFV PODs (Opera 
project scope), and (2) verifying specific ONAP component interop with OPNFV 
generic or scenario-specific features.
 [HELEN] Please give more clarification on (2).
If we can’t resolve the key question here soon enough (what are the Opera 
project’s plans for the F release, e.g. who Is committed to support that work 
and is that enough for success), we may just delay efforts to get organized 
around the Auto projects’ goals for the F release.
 [HELEN] If there’re more resource who are interested in this, could they come 
to help ONAP integration team at this moment? We currently need help on ONAP 
Developer Lab (any tools from OPNFV could help us to daily deployment on ONAP 
in developer lab?) ☺

I expect this to be a topic on this week’s TSC call (part of the creation 
review), and I request that anyone with an opinion on this (especially those 
that intend to support Auto or Opera in the F release) to provide input via 
this thread ahead of the call.

Thanks,
Bryan Sullivan | AT&T

From: SULLIVAN, BRYAN L
Sent: Thursday, August 03, 2017 8:19 AM
To: 'Yunxia Chen' mailto:helen.c...@huawei.com>>; 'Tina 
Tsou' mailto:tina.t...@arm.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [OPNFV confluence] Ulrich Kleber mentioned you on "Tc Agenda 
20170803"

Helen,

We had a discussion today on the takeaways from the call yesterday, to try to 
come to a broader consensus on the plan for how to achieve the Auto project’s 
proposed scope and the Opera project’s scope for F (ONAP integration). Here are 
the key questions I recommended we discuss over email before the TSC meeting:
1)   As noted by Uli there may be a dependency of Auto on Opera. What Opera 
project resources (developers) will be available in F to complete the ONAP 
integration (the “ONAP integration team” as I refer to them below)?
a.   In Auto we had not planned to necessarily deploy ONAP as a complete 
platform, but rather if possible to deploy the components that are needed to 
test the interop use cases in Auto’s scope.
b.   If we find that approach (partial ONAP install) is infeasible/unable 
to meet our goals, we will depend upon a complete ONAP platform install 
instead, either through Opera or as described for the LaaS proposal integrating 
ONAP and OPNFV into a multi-lab testbed 
environment. In this case, 
who from the Opera team would be available to work with us on one of those 
approaches?
[HELEN] Please refer to my above comments.
2)   My overall recommendation is to keep the project overhead low, 
progress agile, and the approach flexible. Given ability to meet those goals, I 
don’t care where the work is done. Here are some questions that will help us in 
the decision per those goals:
a.   Can a combined project be organized as multiple, potentially loosely 
connected tracks?

   i.  We need 
regular project meetings in order to make rapid progress. Would the ONAP 
integration team prefer to have their own meetings? Although we know there was 
a lot of work done on Open-O integration, we don’t see a lot of record of those 
meetings on the wiki etc. That’s OK, if the team (e.g. led by Harry) can 
deliver ONAP integration without a lot of involvement from the Auto project 
team (mostly US based). We want people to work