Re: [onap-tsc] [onap-tsc-vote] Confirmation of [extapi] Committer Promotion - Vote Ends Nov. 6, 10AM pacific.

[Jennifer Wood]

Thank you. This has been approved by the TSC at the November 9, 2017
meeting.

Regards,

Jen Wood
Operations Analyst
The Linux Foundation
jw...@linuxfoundation.org

On Thu, Nov 2, 2017 at 9:19 AM, Kenny Paul 
wrote:

> Does the TSC confirm the promotion of Mark Gibson to be a Committer for
> the External API Project?
> Please respond with a +1, 0 -1
>
> Supporting documentation for Committer promotion:
> https://wiki.onap.org/pages/viewpage.action?pageId=15995154
>
>
> Best Regards,
> -kenny
>
> *Kenny Paul,  Technical Program Manager*
> *kp...@linuxfoundation.org *
> *510.766.5945 <(510)%20766-5945>*
>
>
> ___
> onap-tsc-vote mailing list
> onap-tsc-v...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc-vote
>
>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-tsc-vote] Approval of Control Loop Subcommittee Creation - Vote ends Nov 6, 6PM Pacific

[Jennifer Wood]

Thank you. This has been approved by the TSC at the November 9, 2017
meeting.

Regards,

Jen Wood
Operations Analyst
The Linux Foundation
jw...@linuxfoundation.org

On Thu, Nov 2, 2017 at 5:29 PM, Kenny Paul 
wrote:

> Does the TSC approve the creation of the Control Loop Subcommittee as per
> the proposal submitted by Pamela Dragosh on Oct 11.  Please respond with a
> +1, 0, -1
>
> Official record of submission: https://lists.onap
> .org/pipermail/onap-tsc/2017-October/003715.html
> Text of proposal below.
> ---
>
> Dear TSC,
>
> I would like some guidance on the proposal for a Control Loop
> SubCommittee. This was discussed in Paris F2F at the Control Loop E2E
> Meeting. We identified a need for a subcommittee to help coordinate the
> efforts of supporting Control Loops across all the multitude of projects
> that are involved. Coordination between the project teams proved difficult
> to manage amongst themselves. Each Use Case for Amsterdam also had slightly
> different requirements for their respective Control Loops. There needs to
> be an overarching subcommittee that can manage this effort.
>
> This is what I am proposing:
>
> Name: Control Loop Subcommittee
> Purpose: Coordinate the projects involved in implementation of Control
> Loop for the use cases in each release.
> Expected Deliverables:
> · Wiki – One-stop wiki page that can organize all the
> architectural and flow diagrams expected for the Use Cases targeted for a
> Release.
> · Architectural Diagram – Work with Architecture Sub Committee to
> provide architecture diagrams for Control Loop Design, Instantiation and
> Runtime Execution.
> · Flow Diagrams – Work with the relevant project teams to provide
> Flow Diagrams for creating Control Loops during Design Time Service Design
> and Flow Diagrams for Control Loop Runtime Instantiation and Execution.
> · Model definition (In coordination with Modeling, VNFSDK, VNF
> Requirements Sub Committees) – Coordinate the models for VNF Vendor
> Recommendations for Control Loops, Models for DCAE Microservices, Models
> for Policy Configuration/Operational Control Loop Policies, etc.
> · Project Requirements – Work with required Project teams to
> ensure commitments and deliverables for Control Loop Use Cases for a
> release. The Core teams are DCAE/CLAMP/Policy, but ultimately most projects
> are involved (APPC/VFC/SO/Dmaap/SDC/AAI to name a few).
> · Integration Testing Requirements – Work with the integration
> test team to build E2E Testing Scripts for Control Loop Design,
> Instantiation and Runtime Execution
> · Documentation Requirements – Work with the documentation team
> to build documentation on how the community can build, design and test
> Control Loops.
> Starting Participants:
> Pamela Dragosh – AT&T
> Liam Fallon – Ericsson
> Gervais-Martial Ngueko – AT&T
> Guangrong Fu – ZTE
> Grzegorz Tysczka – Orange
> Patrick Liu - Huawei
>
> Regards,
>
> Pamela Dragosh
> ONAP Policy PTL
>
>
>
>
> ___
> onap-tsc-vote mailing list
> onap-tsc-v...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc-vote
>
>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-discuss] December Event CFP Notifications Delayed.

[Michael O'Brien]

Kenny,
   Thank you for your work on this with the TSC and Linux Foundation – we 
appreciate on top of all release work.
   Notifications are coming in now.
   /michael

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kenny Paul
Sent: Tuesday, November 14, 2017 16:31
To: onap-discuss ; onap-tsc 

Subject: [onap-discuss] December Event CFP Notifications Delayed.

This is just to let everyone know that we are running behind on the 
notifications. Also a few people have reported that their submission did not go 
through so please look over the list below to ensure your submission is there.  
NOTE: THIS IS JUST THE LIST SUBMISSIONS - THIS IS NOT THE NOTIFICATION

I want to share a couple of things regarding this event.  The Governing Board 
felt that in light of the Amsterdam release timing this event should be equal 
parts externally and internally facing. The composition of this event will be 
broader than our previous events in New Jersey, Beijing and Paris where the 
only attendees were basically the active ONAP development community. This event 
is an opportunity for you to not only share your ONAP knowledge with your 
peers, but also with those that want to learn more about ONAP in general. The 
expanded scope meant that a number of new logistical factors had to be 
accounted for and as such our approach to presentation submissions had to be 
altered accordingly.

The second item is that I made a tactical error when I eliminated the Google 
forms for CFP submissions for this event.  The LF uses Google forms to collect 
external CFP input for all of our events and has done so for a very long time. 
This model is integrated on the backend to ensure everything runs as seamless 
as possible. In those cases where this method cannot be used by someone we have 
always provided the simple workaround in the form of survey monkey. This 
workaround is easy for the users, but requires a lot of manual intervention on 
our part behind the scenes. In retrospect it was probably a mistake to shut 
down the Google form as the primary submission source as it has caused things 
to run less than smoothly.

Not on the list below is the TSC meeting on Dec 13th. You can add to that 
agenda here

My apologies for the delay.

Notifications should go out by the weekend.

List sorted by presenter name
-kenny

———


Select the talk type

Session Title for Presentation:

Speaker Full Name

Presentation

AAI Abstractions & Extensibility

Adrian Batos-Parac


End-to-End Model Driven VNF Lifecycle Management/Modeling

Alex Vul


VNF Homing & Placement Optimization

Alex Vul

Panel Discussion

Open source and standards - the differences, the similarities, the joint way 
forward

Alla Goldner

Session Presentation

R2 requirements and use cases

Alla Goldner

Presentation

VNF On-Boarding, Requirements, and Operations

Alok Gupta

Presentation

Progressing ONAP testing and integration with a "dummy VNF"

Andrew Fenner

Presentation

ONAP Integration Through Information and Data Modeling

Andrew J. Mayer, Ph.D.

Hands-ON

Hands-ON TOSCA Modeling Workshop with TOSCA Simple Profile and ARIA

Arthur Berezin, Michael Brenner

Presentation

Enabling Workloads Orchestration in Containers via Multi Cloud

Bin Hu, Ramki Krishnan, Gil Hellmann, Sumit Verdi and more

Presentation

Virtualized Access Managment on ONAP

BLAINE MCDONNELL

Presentation

Architecture Subcommittee meeting

Chris Donley

Presentation

ONAP Amsterdam Architecture

Chris Donley

Presentation

VNF SDK supporting VNF Onboarding

Chris Donley


SDNC Roadmap

Dan Timoney

Presentation

Multi-Vendor Active Inventory UI Extensibility

David Adams

Presentation

An Introduction to the ONAP Operations Manager (OOM)

David Sauvageau/Mike Elliott

Presentation

Model Driven Service Orchestration - SO state of the Union

DeWayne Filppi


Testing strategies for Beijing

Eric Debeau

Presentation

Use-cases

Eric Debeau

Presentation

Deep Dive into the VPP based VNFs of the vCPE Use case

Eric Multanen

Presentation

VNF Validation Program (VVP)

Erik Sundelof

Session Presentation

Telemetry and Analytics for the NFV World - IOAM, DCAE, PNDA

Frank Brockners

Presentation

Real Time Data Event Streaming & Processing a critical need for true automation 
control

Habib Madani

Presentation

MSB Beijing Release Plan

Huabing Zhao

Presentation

Network Slice LCM with ONAP

Ignacio Más

Presentation

Toward container support as cloud infrastructure that runs VNFs

Isaku Yamahata

Presentation

Transaction Traceability Across ONAP Components

James MacNider

Presentation

Active, or Planned Deployments of ONAP

Jamil Chawki

Session Presentation

Open CLI Platform (OCLIP) and ONAP CLI

Kanagaraj Manickam

Presentation

State, context, adaptability, and scale for self-learning closed loop policies

Liam Fallon

Presentation

Before onboarding your VNF: How VNFSDK can help

Lianha

Re: [onap-tsc] Transparency first

[Yunxia Chen]

Hi, Eric,

I totally agree with your point regarding “transparency first”, and I think so 
far ONAP community doing it relatively well:

1.   We have bitergia to report all important activities and contributions 
with a public accessible hosted site of: https://onap.biterg.io

2.   Jira tickets system allow everyone to report any issues and check 
issues there.

3.   All projects’ / subcommittees’ weekly meeting open to everyone

4.   Etc.

Even with our integration testing sessions, we sent invitation to everyone who 
registered “onap-discussion” maillist. The testing results and videos, (we 
didn’t post every video since we have recorded 500+ hrs’ testing sessions, but 
they are available if anyone interested). (Since I am the PTL of Integration 
project, I talk more on integration point of view.)

We have agreed that at Amsterdam release, especially the last few weeks, we 
will focus on those three “approved” use cases in the selected “gating” open 
lab, and bugs reported by those places have higher priority, (others are still 
in our jira site publically available). At the same time, we provided help on 
other labs when the resource and bandwidth were available. Regarding that SO 
bug found by you (thank you for your help on testing it, please continue doing 
so), it happens intermittently and depends on different java classloader’s 
behavior, and unfortunately (or luckily? ☺) we didn’t hit it at those four use 
cases testing process. And I am sure there’re more issues we didn’t catch at 
different infrastructure and use cases. Hopefully we could do better and better 
in future releases: testing on more clouds is in Integration’s Beijing release 
road map with the condition of available testing infrastructure.

Regards,

Helen Chen

From:  on behalf of Eric Debeau 

Date: Friday, November 17, 2017 at 7:17 PM
To: onap-tsc 
Subject: [onap-tsc] Transparency first

Hello

I would like to share some feedbacks from the yesterday TSC.

We are working in an open source community with some guidelines from the ONAP 
TSC Charter  “The Open Network Automation Platform (ONAP) will operate 
transparently, openly, collaboratively, and ethically”.

As a result, we must work in a transparent way. We must not hide the problems, 
issues. At the end of the day, the code will remind us of the reality.

There is no perfect software solution in our industry, and we must admit that 
we may have some issues and we must provide some documentation to avoid 
discovering them when using ONAP.

Let’s go to Beijing ;-)

Best regards

Eric


_



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.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Action points on SO/DCAE

[eric.debeau]

Hello

Following the yesterday TSC meeting, we organized a meeting with Helen & Gildas

Sylvain presented and showed from our environment the issues we faced.

SO (Sehu)
There was a problem due the dme.jar. There was a mismatch found between the 
version of org.springframework coming from the dme jar and the one from 
spring-core.
Rob fixed the issue yesterday: https://gerrit.onap.org/r/#/c/23919/


DCAE (Lusheng)
The current DCAE blueprint was tailored for the Integration Lab and can not 
work in another configuration. Some manual tasks must be performed to launch 
DCAE and are not yet documented.

Lusheng will provide 2 solutions:


  1.  Improve documentation adding more specifications on how Designate related 
set up needs to be done, as well as how manual workarounds, if needed for 
specific OpenStack configuration, can be conducted.  DCAE will also provide a 
video tutorial on how to start DCAE. Orange committed to test it and check it.
  2.  After Amsterdam 1.0.0. release is branched, DCAE will add code to the 
demo project (where DCAE bootstrap process is done) addressing the needs of 
additional OpenStack configurations, with respect to DNS zone related 
operations.  Such code change will be available as snapshots on the master 
branch first shortly after the 1.0.0 code is branched, later folded into 1.0.1 
release mid Jan.

Thanks for the reactivity.

Best Regards

Eric


_

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.

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Transparency first

[eric.debeau]

Hello

I would like to share some feedbacks from the yesterday TSC.

We are working in an open source community with some guidelines from the ONAP 
TSC Charter  "The Open Network Automation Platform (ONAP) will operate 
transparently, openly, collaboratively, and ethically".

As a result, we must work in a transparent way. We must not hide the problems, 
issues. At the end of the day, the code will remind us of the reality.

There is no perfect software solution in our industry, and we must admit that 
we may have some issues and we must provide some documentation to avoid 
discovering them when using ONAP.

Let's go to Beijing ;-)

Best regards

Eric


_

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.

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Amsterdam Branching Timeline

[Kanagaraj Manickam]

Dear kenny

We have created branch release-1.1.0 already for onap/cli and setup the Jenkins 
jobs as well.

This is done on the same commit as release binaries are done.

Regards
Kanagaraj M
From: TIMONEY, DAN
To: Kenny Paulmailto:kp...@linuxfoundation.org>>
Cc: Jeremy 
Phelpsmailto:jphe...@linuxfoundation.org>>;onap-tscmailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Amsterdam Branching Timeline
Time: 2017-11-17 04:04:28

Kenny,

Excellent - what service!

Thanks much,
Dan

Sent from MyOwn, an AT&T BYOD solution.




From: "Kenny Paul" mailto:kp...@linuxfoundation.org>>
Date: Thursday, November 16, 2017 at 5:08:06 PM
To: "TIMONEY, DAN" mailto:dt5...@att.com>>
Cc: "onap-tsc" mailto:onap-tsc@lists.onap.org>>, 
"Jeremy Phelps" 
mailto:jphe...@linuxfoundation.org>>
Subject: Re: [onap-tsc] Amsterdam Branching Timeline

Hi Dan,

yes the LF will handle that.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Nov 16, 2017, at 1:22 PM, TIMONEY, DAN 
mailto:dt5...@att.com>> wrote:

Kenny,

After the release branches are created, we’ll also need to create new Jenkins 
jobs to compile against the new release branch.  Is that the responsibility of 
each project team, or was LF planning to handle that?

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc