Re: [onap-tsc] [onap-discuss] Action Plan towards Casablanca

[Sauvageau, David]

Bell would like to contribute to the end user committee

Envoyé de mon iPhone

Le 31 mars 2018 à 07:08, Alla Goldner 
> a écrit :

Thanks, Mazin,

We will definitely not slow down as time issue is becoming critical and try to 
come up with our proposal of realistic scope per defined prioritized areas.

We also need to define what percentage of work in Casablanca would be dedicated 
by the projects to leftovers from Beijing and to extension of S3P work.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology




From: GILBERT, MAZIN E (MAZIN E) [mailto:ma...@research.att.com]
Sent: Saturday, March 31, 2018 3:56 AM
To: Alla Goldner >
Cc: onap-usecase...@lists.onap.org; 
onap-disc...@lists.onap.org; 
onap-tsc@lists.onap.org P 
>
Subject: Re: [onap-discuss] Action Plan towards Casablanca
Importance: High

Thanks Alla for the summary.

Here is what we agreed to at the TSC meeting.
There are three work plans for Casablanca. The theme is increase deployability 
of ONAP.

1. Functional requirements and use cases. We agreed to establish an end-user 
advisory committee that will be driven by the equivalent of product managers 
across operators who will help to set priorties that can accelerate 
deployability of ONAP. The work of your committee on use cases and 5G 
solutioning will help to provide options for the end-user advisory committee.

2. Platform Evolution. This includes some of your list items
a. S3P new target (including code coverage)
b. Backward compatibility
c. Improve modularity and simplicity of using ONAP.

3. Broader learning and education of ONAP.
The Education committee will develop a proposal for weekly Webinars.

I am working to assemble 1. My hope is to have 3-4 operators signed up next 
week so they can meet with your team and get the work started.
Phil will make that committee official as a subgroup under LFN end-user 
advisory committee. Until then, let’s not slow down.

We also discussed what we want to accomplish prior to the Beijing meeting in 
June. We will discuss that further at the TSC meeting this week,
and also vote on the release planning for Casablanca.

Great progress by the team on Beijing. Most projects hit M4 already. Momentum 
is amazing.

Mazin


On Mar 30, 2018, at 5:03 AM, Alla Goldner 
> wrote:

Hi all,

I re-attach the picture which describes high level priorities as discussed 
during the meeting called by me on Wednesday evening. I understand this was 
discussed in details also during the TSC meeting.

What we had on the table was:

1.   Leftovers from Beijing remained from :
a.   Functional requirements (PNF, Scaling, Change Management, HPA)
b.  Leftovers from S3P support
2.   New S3P requirements
3.   All new use cases and requirements coming to Casablanca (you could see 
the variety during our meeting on Monday)
4.   A different projects proposed extensions
5.   Possibly, new projects potentially proposed for Casablanca
6.   Architecture evolution related modifications

Clearly, this whole scope will not be accomplished in a single Release, this is 
why we needed to see what would be areas of priorities.
Clearly, we may get additional input from the Service Providers, as discussed, 
but in the mean time, in order to make progress, let’s assume these are the 
priorities.

Now, in order to do constructive work and move forward towards Casablanca 
Release, specifically for Usecase subcommittee, we need to see what ongoing 
work matches the Deployability goal as defined and, additionally, extract 
generic functional requirements from the use cases brought to the table/see if 
some requirements brought to the table can be generalized.

I identify the following areas for our activities out of proposed prioritized 
areas:

1.   Leftovers of functional requirements from Beijing – as scope is pretty 
clear, I would say that at this point the required actions are:
a.   Have a detailed list of functionality proposed to move to Casablanca
b.  Negotiate with involved projects on this functionality and resources 
assigned to these activities

2.   All 5G related requirements:
a.   A realistic plan of what can be implemented in Casablanca (a subset of 
functionality discussed so far), based on available/emulated VNFs/PNFs, 3GPP 
standards’ availability etc. with flows, needed resources, affected modules

3.   All external controllers related activities – this work should be 
generalized and common principle should be developed on what we bring to 
Casablanca in such a way that it can be utilized by several use cases. Some 
initial work on this was also done in Beijing.
a.   A concrete 

Re: [onap-tsc] Planning for ONAP TSC Elections

[Sauvageau, David]

+1 on the proposal and will gladly join the wg

Envoy? de mon iPhone

Le 17 d?c. 2017 ? 11:21, Xinhui Li 
> a ?crit :

Thanks, Phil.  I would like to participate into the proposed WG.

Xinhui

From: > 
on behalf of Phil Robb 
>
Date: Wednesday, 13 December 2017 at 4:03 PM
To: onap-tsc >
Subject: [onap-tsc] Planning for ONAP TSC Elections

Hello ONAP TSC Members:

As documented in the ONAP Project Charter, the TSC is tasked with figuring out 
how to populate the TSC in a meritocratic manner beginning 12 months after the 
project launch, which was March 2017.  Hence it is time to start planning this 
transition.  To kick this process off, I have the following suggestions:

- Given that March 2018 is in the middle of the Beijing release cycle, I 
suggest we postpone the TSC election until directly after the Beijing release 
in late May.  We should discuss and approve our method of populating the TSC by 
the end of March, but not actually execute it until late May or early June.  
Please let me know if you think this is a good or bad idea.

- I suggest we form a small workgroup to create an initial proposal for 
discussion with the broader TSC.  Some topics to consider when architecting the 
TSC makeup include:
- Constituencies.  Are there different constituencies that need 
representation on the TSC?
- PTLs.  Having an election of PTLs to populate the TSC one possible way to 
do it.  These PTLs may be from different constituencies, or just At-Large.
- Committers-At-Large (CALs).  Some seats can come from the committer 
community at large.
- Particular Roles.  Possibly have the PTL from the Integration Team, or 
the Release Manager as voting members of the TSC as an example of "special" 
roles that should have TSC representation.
- Company Caps - To ensure that a single company does not have too much 
voting power within the TSC, a limit (usually defined as a percentage) is 
imposed on how many TSC members can come from the same organization (or 
affiliated organization).
- TSC size.  Common guidance is to keep the TSC size somewhere between 7 
and 19.  11,13, and 15 are common sizes.  Depending on how the TSC is populated 
the size may vary or may be static.

Please let me know your thoughts.  If you think a workgroup to put an initial 
proposal together is a good idea, please indicate that.  If you think we should 
have a few open discussions to set an initial direction please indicate that.  
If a workgroup seems reasonable, and you would like to participate in that 
group please indicate that as well.

I look forward to the discussion.

Thanks,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [OOM] Request for new committer on OOM - Borislav Glozman

[Sauvageau, David]

Dear TSC

Following a unanimous +1 vote from the current OOM committers, I would like to 
promote Borislav Glozman as a new committer to the OOM project. Borislav has 
made great contribution to the project, both from an implementation and design 
perspectives.

Official request is posted here: 
https://wiki.onap.org/display/DW/Committer+Promotion+Request+for+%5BOOM%5D+-+Borislav+Glozman

Thanks for supporting!


From: "Sauvageau, David" <david.sauvag...@bell.ca>
Date: Saturday, November 11, 2017 at 8:53 AM
To: "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org>
Cc: Borislav Glozman <borislav.gloz...@amdocs.com>
Subject: [OOM] Request for new committer on OOM - Borislav Glozman

Dear TSC
Following a unanimous +1 vote from the current OOM committers, I would like to 
promote Borislav Glozman as a new committer to the OOM project.

Thanks for supporting!

Envoyé de mon iPhone

Début du message transféré :
Expéditeur: Mike Elliott 
<mike.elli...@amdocs.com<mailto:mike.elli...@amdocs.com>>
Date: 10 novembre 2017 à 14:31:38 UTC−5
Destinataire: "Sauvageau, David" 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>, 
"onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>" 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>
Objet: Rép :⁨ [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman⁩
++1!

Mike.

From: 
<onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of "HU, JUN NICOLAS" <jh2...@att.com<mailto:jh2...@att.com>>
Date: Friday, November 10, 2017 at 10:00 AM
To: "Sauvageau, David" 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>, 
"onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>" 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>
Subject: Re: [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman

+1

Thanks for the contribution.

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Sauvageau, David
Sent: Wednesday, November 08, 2017 8:20 AM
To: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>
Subject: [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman

Dear OOM committers,

This is a request to promote Borislav as a committer on the OOM project. I 
would need all OOM committers to vote on Borislav’s promotion by replying +1, 0 
or –1 on this email. If we get a majority of +1, I will then bring the request 
to the TSC.

Thanks!

From: Borislav Glozman 
<borislav.gloz...@amdocs.com<mailto:borislav.gloz...@amdocs.com>>
Date: Sunday, November 5, 2017 at 2:48 AM
To: David Sauvageau <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>
Cc: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>
Subject: ONAP OOM committer for Borislav Glozman

Hi David,

I would like to officially become OOM committer.
I fix defects, commit code, participate in meetings, participate in design of 
features, participated in Paris ONAP event and presented there.
I also lead a team of developers who work on OOM.

Could you please assist me in becoming a committer in OOM project so that I 
could actively participate in Beijing release in OOM?
Please let me know what is the process.

Thanks,
Borislav Glozman
O:+972.9.776.1988
M:+972.52.2835726

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at 
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=qxToYrwGC0Ebi3fnN8QCAw=mVTt6sWo4p1QzZF5qAMDqu_l6dcTZ5IXGwrTS7rJJSk=-zFTiuctAqjZ6huZQJk_HQek9j3Q5g_Agz7UX3DKDm4=>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] [OOM] Request for new committer on OOM - Borislav Glozman

[Sauvageau, David]

Dear TSC
Following a unanimous +1 vote from the current OOM committers, I would like to 
promote Borislav Glozman as a new committer to the OOM project.

Thanks for supporting!

Envoy? de mon iPhone

D?but du message transf?r? :

Exp?diteur: Mike Elliott 
<mike.elli...@amdocs.com<mailto:mike.elli...@amdocs.com>>
Date: 10 novembre 2017 ? 14:31:38 UTC?5
Destinataire: "Sauvageau, David" 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>, 
"onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>" 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>
Objet: R?p :? [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman?

++1!

Mike.

From: 
<onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of "HU, JUN NICOLAS" <jh2...@att.com<mailto:jh2...@att.com>>
Date: Friday, November 10, 2017 at 10:00 AM
To: "Sauvageau, David" 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>, 
"onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>" 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>
Subject: Re: [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman

+1

Thanks for the contribution.

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Sauvageau, David
Sent: Wednesday, November 08, 2017 8:20 AM
To: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>
Subject: [onap-discuss] [OOM] Request for new committer on OOM - Borislav 
Glozman

Dear OOM committers,

This is a request to promote Borislav as a committer on the OOM project. I 
would need all OOM committers to vote on Borislav's promotion by replying +1, 0 
or -1 on this email. If we get a majority of +1, I will then bring the request 
to the TSC.

Thanks!

From: Borislav Glozman 
<borislav.gloz...@amdocs.com<mailto:borislav.gloz...@amdocs.com>>
Date: Sunday, November 5, 2017 at 2:48 AM
To: David Sauvageau <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>
Cc: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>
Subject: ONAP OOM committer for Borislav Glozman

Hi David,

I would like to officially become OOM committer.
I fix defects, commit code, participate in meetings, participate in design of 
features, participated in Paris ONAP event and presented there.
I also lead a team of developers who work on OOM.

Could you please assist me in becoming a committer in OOM project so that I 
could actively participate in Beijing release in OOM?
Please let me know what is the process.

Thanks,
Borislav Glozman
O:+972.9.776.1988
M:+972.52.2835726

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at 
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=qxToYrwGC0Ebi3fnN8QCAw=mVTt6sWo4p1QzZF5qAMDqu_l6dcTZ5IXGwrTS7rJJSk=-zFTiuctAqjZ6huZQJk_HQek9j3Q5g_Agz7UX3DKDm4=>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Beijing release participation - OOM

[Sauvageau, David]

Dear TSC,

This email is to formally notify ONAP TSC and community that the OOM project 
plans to be part of the ONAP Beijing release.

Regards,
David Sauvageau

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

[onap-tsc] Enforcing an "Upstream first" approach to ONAP

[Sauvageau, David]

Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,


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

Re: [onap-tsc] [MSB][OOM]The July Virtual Developers Event Topic : OOM & MSB Interaction

[Sauvageau, David]

Hi Kenny, can you please create the following repo in OOM?
Thanks,

Components Name

Components Repository name

Maven Group ID

Components Description

registrator oom/registrator org.onap.oom.registrator

Register the service endpoints to MSB so it can be used for service request 
routing and load balancing. Registrator puts service endpoints info to MSB 
discovery module(Consul as the backend) when an ONAP component is deployed by 
OOM, and update its state along with the life cycle, such as start, stop, 
scaling, etc.




On Jul 26, 2017, at 9:37 AM, Sauvageau, David 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> wrote:

Hi Kenny
Can we please create that repo?
Thanks

Envoyé de mon iPhone

Début du message transféré :

Expéditeur: <zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn>>
Date: 26 juillet 2017 à 09:16:15 UTC−4
Destinataire: <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>
Cc: <jn1...@att.com<mailto:jn1...@att.com>>, 
<jflu...@research.att.com<mailto:jflu...@research.att.com>>, 
<jh2...@att.com<mailto:jh2...@att.com>>, 
<rb2...@att.com<mailto:rb2...@att.com>>, 
<ht1...@att.com<mailto:ht1...@att.com>>, 
<roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>>, 
<j...@research.att.com<mailto:j...@research.att.com>>, 
<meng.zhaoxi...@zte.com.cn<mailto:meng.zhaoxi...@zte.com.cn>>, 
<c...@research.att.com<mailto:c...@research.att.com>>, 
<ag1...@att.com<mailto:ag1...@att.com>>, 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>
Objet: Rép :⁨ [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction⁩


Hi David,


Given the current situation, MSB should take the service endpoint registration 
integration with kubernetes implementation as its priority for Amsterdam and 
integration with cloudify implementation as a stretch goal.


As we discussed in the last OOM meeting, we need a repo to accommodate the 
registrator codes for kubernetes service. Can you help to create that repo?  
Please let me know if you have any concerns or question.


Release Components Name
Components Name

Components Repository name

Maven Group ID

Components Description

registrator oom/registrator org.onap.oom.registrator

Register the service endpoints to MSB so it can be used for service request 
routing and load balancing. Registrator puts service endpoints info to MSB 
discovery module(Consul as the backend) when an ONAP component is deployed by 
OOM, and update its state along with the life cycle, such as start, stop, 
scaling, etc.


Resources committed to the Release


Thanks,

Huabing


Original Mail
Sender:  <david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>>;
To:  <jn1...@att.com<mailto:jn1...@att.com>>;
CC: zhaohuabing10201488; 
<jflu...@research.att.com<mailto:jflu...@research.att.com>>; 
<jh2...@att.com<mailto:jh2...@att.com>>; 
<rb2...@att.com<mailto:rb2...@att.com>>; 
<ht1...@att.com<mailto:ht1...@att.com>>; 
<roger.maitl...@amdocs.com<mailto:roger.maitl...@amdocs.com>>; 
<j...@research.att.com<mailto:j...@research.att.com>>;MengZhaoXing10024238; 
<c...@research.att.com<mailto:c...@research.att.com>>; 
<ag1...@att.com<mailto:ag1...@att.com>>; 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>;
Date: 2017/07/26 19:39
Subject: Re: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction


Hi John

Let’s recap what was discussed and agreed as a team:
* For Amsterdam release, Kubernetes is the first OOM technical implementation 
to be created. This is the seed code available and what the team agreed to work 
on
* The cloudily implementation has not been demoed yet and no seed code 
available. It was agreed by the team that cloudily would be a stretch target.

I want to make sure we align to what the OOM team has agreed to deliver.

Comments?


On Jul 25, 2017, at 6:39 PM, NG, JOHN <jn1...@att.com<mailto:jn1...@att.com>> 
wrote:

Huabing,
Ok, let’s focus on Consul integration for the Amsterdam release …

-  In  Day 0 OOM instantiation, Cloudify is the first OOM module to be 
created.

-  Cloudify  creates Consul as the next OOM module.   Cloudify 
registers itself in Consul.

-  Cloudify  then creates the rest of the OOM modules (Postgres, API 
Handler, Dashboard), and registers each module in Consul.  And Consul starts 
performing health checks against them.

-  OOM  instantiation is now complete.

-  OOM  deploys MSB as one of the first ONAP components.  OOM 
provides/configures MSB with the location of the Consul API for access and 
discovery.

-  OOM  then continues to deploy the rest of the ONAP components and 
modules, and r

Re: [onap-tsc] [onap-discuss] Question on ONAP Operations Manager (OOM)

[Sauvageau, David]

That is a good point.

From the OOM perspectivewe believe that deployment mechanism should provide 
consistency through OOM, and therefore the DCAE controller should probably be 
replaced by OOM as a consistent re-usable functionality. Generally speaking, we 
need to provide the equivalent functionality of the DCAE controller across all 
components (i.e. deploy in the right DCs, auto-scale, etc).

The role of OOM vs DCAE controller should definitely be discussed – but I do 
not believe each component should have their own “controller function” to 
perform lifecycle events.

From:  on behalf of 
"fu.guangr...@zte.com.cn" 
Date: Monday, June 5, 2017 at 2:40 AM
To: "onap-disc...@lists.onap.org" , 
"onap-tsc@lists.onap.org" 
Subject: [onap-discuss] Question on ONAP Operations Manager (OOM)


Hi there,



After I went through the proposal page of OOM, I feel sort of confused on one 
point. I hope guys for OOM could help to figure it out.

To my understanding, one of the responsibilities of OOM is to manage the 
lifecycle of the ONAP components, as is mentioned on the page "The users can 
also deploy ONAP instances, a component, or a change to a software module 
within a component". But for some components, they have their own controllers 
to manage the lifecycle of their sub-components. Take DCAE for example, 
onboarding of microservices is currently being performed by the DCAE controller 
for analytics applications and data collectors. How does OOM cope with such 
kind of scenario? Will OOM take over the responsibility of the lifecycle 
management of sub-projects/sub-modules?



Regards,

Guangrong








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

[onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on Containers

[Sauvageau, David]

Deer TSC,

I would like to formally propose 2 projects to simplify the deployment and the 
operations of the ONAP platform and components.

Project: ONAP Operations Manager (Formerly ONAP controller) - 
https://wiki.onap.org/display/DW/ONAP+Operations+Manager

This proposal introduces the ONAP Platform OOM (ONAP Operations Manager) to 
efficiently Deploy, Manage, Operate the ONAP platform and its components (e.g. 
MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). The OOM addresses 
the current lack of consistent platform-wide method in managing software 
components, their health, resiliency and other lifecycle management functions.  
With OOM, service providers will have a single dashboard/UI to deploy & 
un-deploy the entire (or partial) ONAP platform, view the different instances 
being managed and the state of each component, monitor actions that have been 
taken as part of a control loop (e.g., scale in-out, self-heal), and trigger 
other control actions like capacity augments across data centers.

Sub-project: ONAP Operations Manager / ONAP on Containers - 
https://wiki.onap.org/pages/viewpage.action?pageId=3247305

This project describes a deployment and orchestration option for the ONAP 
platform components (MSO, SDNC, DCAE, etc.) based on Docker containers and the 
open-source Kubernetes container management system. This solution removes the 
need for VMs to be deployed on the servers hosting ONAP components and allows 
Docker containers to directly run on the host operating system.

The primary benefits of this approach are as follows:

  *   Life-cycle Management. Kubernetes is a comprehensive system for managing 
the life-cycle of containerized applications.  Its use as a platform manager 
will ease the deployment of ONAP, provide fault tolerance and horizontal 
scalability, and enable seamless upgrades.
  *   Hardware Efficiency. As opposed to VMs that require a guest operating 
system be deployed along with the application, containers provide similar 
application encapsulation with neither the computing, memory and storage 
overhead nor the associated long term support costs of those guest operating 
systems.
  *   Deployment Speed. Eliminating the guest operating system results in 
containers coming into service much faster than a VM equivalent. This advantage 
can be particularly useful for ONAP where rapid reaction to inevitable failures 
will be critical in production environments.
  *   Cloud Provider Flexibility. A Kubernetes deployment of ONAP enables 
hosting the platform on multiple hosted cloud solutions like Google Compute 
Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.


We currently have the support of Bell, AMDOCS, AT, Orange, Ericsson and 
Gigaspaces on the project and still looking for more. Please review and comment!

Thanks,
David Sauvageau, Bell Canada.




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

[onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on Containers

[Sauvageau, David]

Dear TSC,

I would like to formally propose 2 projects to simplify the deployment and the 
operations of the ONAP platform and components.

Project: ONAP Operations Manager (Formerly ONAP controller) - 
https://wiki.onap.org/display/DW/ONAP+Operations+Manager

This proposal introduces the ONAP Platform OOM (ONAP Operations Manager) to 
efficiently Deploy, Manage, Operate the ONAP platform and its components (e.g. 
MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). The OOM addresses 
the current lack of consistent platform-wide method in managing software 
components, their health, resiliency and other lifecycle management functions.  
With OOM, service providers will have a single dashboard/UI to deploy & 
un-deploy the entire (or partial) ONAP platform, view the different instances 
being managed and the state of each component, monitor actions that have been 
taken as part of a control loop (e.g., scale in-out, self-heal), and trigger 
other control actions like capacity augments across data centers.

Sub-project: ONAP Operations Manager / ONAP on Containers - 
https://wiki.onap.org/pages/viewpage.action?pageId=3247305

This project describes a deployment and orchestration option for the ONAP 
platform components (MSO, SDNC, DCAE, etc.) based on Docker containers and the 
open-source Kubernetes container management system. This solution removes the 
need for VMs to be deployed on the servers hosting ONAP components and allows 
Docker containers to directly run on the host operating system.

The primary benefits of this approach are as follows:

  *   Life-cycle Management. Kubernetes is a comprehensive system for managing 
the life-cycle of containerized applications.  Its use as a platform manager 
will ease the deployment of ONAP, provide fault tolerance and horizontal 
scalability, and enable seamless upgrades.
  *   Hardware Efficiency. As opposed to VMs that require a guest operating 
system be deployed along with the application, containers provide similar 
application encapsulation with neither the computing, memory and storage 
overhead nor the associated long term support costs of those guest operating 
systems.
  *   Deployment Speed. Eliminating the guest operating system results in 
containers coming into service much faster than a VM equivalent. This advantage 
can be particularly useful for ONAP where rapid reaction to inevitable failures 
will be critical in production environments.
  *   Cloud Provider Flexibility. A Kubernetes deployment of ONAP enables 
hosting the platform on multiple hosted cloud solutions like Google Compute 
Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.


We currently have the support of Bell, AMDOCS, AT, Orange, Ericsson and 
Gigaspaces on the project and still looking for more. Please review and comment!

Thanks,
David Sauvageau, Bell Canada.

*** PS you may have received this proposal twice since my original seemed to 
have bounced.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Project Proposal: ONAP CLI

[Sauvageau, David]

Agreed with Brian as well.

Maybe CLI could be added at a later time but to me should not be a priority for 
2017 Release 1.

From:  on behalf of Dhananjay Pavgi 

Date: Tuesday, May 9, 2017 at 8:59 AM
To: "FREEMAN, BRIAN D" , Kanagaraj Manickam 
, "t...@lists.onap.org" 
Subject: Re: [onap-tsc] Project Proposal: ONAP CLI

Spot on, Brian. You got it.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com Platinum 
Member. Visit : http://www.onap.org

From: FREEMAN, BRIAN D [mailto:bf1...@att.com]
Sent: Tuesday, May 09, 2017 10:55 PM
To: Dhananjay Pavgi ; Kanagaraj Manickam 
; t...@lists.onap.org
Subject: RE: Project Proposal: ONAP CLI


Scripting is useful but shell scripts that wrap curl  functions are the method 
we are pushing folks towards. Separate CLI and REST API’s are generally a 
waste. With automation we see less pressure to have a CLI and more a need to be 
able to get the work done and CURL/POSTMAN are the tools of the new devops 
environment.

Brian

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Dhananjay Pavgi
Sent: Tuesday, May 09, 2017 6:32 AM
To: Kanagaraj Manickam 
>; 
t...@lists.onap.org
Subject: Re: [onap-tsc] Project Proposal: ONAP CLI

Thanks. Don’t agree with the comment on GUI can’t be used in DevOps. Wonder how 
CLI would be easier in any which ways to work with clumsy yaml/TOSCA files. CLI 
was good for short service commands.

While it would still make sense to have it for VNFs; for some of the reasons 
sighted below. For Network Automation Platform like ONAP; still ponder over 
it’s necessity.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com
 Platinum Member. Visit : 
http://www.onap.org

From: Kanagaraj Manickam [mailto:kanagaraj.manic...@huawei.com]
Sent: Tuesday, May 09, 2017 7:37 PM
To: Dhananjay Pavgi 
>; 
t...@lists.onap.org
Subject: RE: Project Proposal: ONAP CLI

Thanks for sharing your comments. Pls find my inputs below:

CLI has its own advantages over GUI in following aspects:

  1.  ONAP Continuous integration (CI), where we want to perform various ONAP 
operations, CLI will be very handy option. This is applicable to 3rd party CI 
as well.
  2.  While GUI is the preferred interface for end-user, back-end operators and 
 admin always prefer CLI (it’s an industry trend !) as its simpler, faster.
  3.  Installation scripting, VNF boot scripting with ONAP.
  4.  Dev testing … integration testing.
  5.  OSS/BSS products would want to perform any automation on top of ONAP, it 
could go either with CLI or SDK.
In short, GUI can’t be used in devops environment, and CLI fills the gap.

In addition, CLI provides an alternate option to GUI,  for operating back ONAP 
functionalities.

And to feel the importance of CLI, Pls refer some existing active automation 
projects in industry, given here:

  1.  OpenStack heat provides  CLI ‘openstack stack’
  2.  Cloudify provides CLI ‘cfy’
  3.  ODL provides CLI with different commands

So IMHO,
-  CLI does compliment GUI and does not defeat it.
-  Considering ONAP as platform, CLI should be part of it.

Regards
Kanagaraj M

***
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！**

***
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 

[onap-tsc] Repo Question

[Sauvageau, David]

+1

Envoy? de mon iPhone

Le 26 avr. 2017 ? 18:36, Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>> a ?crit :

+1

Chris

From: onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alla 
Goldner
Sent: Wednesday, April 26, 2017 10:06 AM
To: Ed Warnicke; SPATSCHECK, OLIVER (OLIVER)
Cc: Phil Robb via onap-tsc
Subject: Re: [onap-tsc] Repo Question

+1

Alla Goldner

 Original Message 
Subject: Re: [onap-tsc] Repo Question
From: Ed Warnicke mailto:hagb...@gmail.com>>
Date: Apr 26, 2017, 7:34 PM
To: "SPATSCHECK, OLIVER (OLIVER)" mailto:spatsch 
at research.att.com>>
+1

Ed

On Wed, Apr 26, 2017 at 8:14 AM, SPATSCHECK, OLIVER (OLIVER) mailto:spatsch at research.att.com>> wrote:

Dear TSC,

I think we have a little conundrum with the current code base repos. As you are 
likely aware the original code base we had released was matching our 1610 
internal release. We have been busy the last few weeks uploading the delta to 
bring the public code base up to the current internal version to give the 
community the same view/code we use today. Now it turns out that our current 
internal code base requires some additional "sub-repos" 3 under A and one 
under SDC. Without those repos we can not complete the public code update by 
5/5 as originally promised.

The conundrum now is that we still don't have a charter and no projects have 
been created yet. So there is no process for us to create those additional 
repos on LF servers.

Therefore, I am requesting a one time waiver from the TSC allowing the LF to 
create those repos so we can complete the code base update in a timely manor.

I don't really think there is any substantial risk as the TSC can always decide 
to delete the repos again later if the TSC doesn't like them. On the positive 
side it allows the community to see all the code in a timely manor.

To be clear those are nor new functional components. Those repos only include 
improvements to the existing functional components in particular A and SDC.

Thx

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

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-tsc] Invitation: ONAP Project: TSC Meeting @ Weekly from 7am to 8am on Thursday from Thu Apr 13 to Thu Apr 27 (PDT) (onap-tsc@lists.onap.org)

[Sauvageau, David]

Hi can anyone help me? The zoom meeting reached maximum capacity of 50 people 
so I can?t join either by zoom or by phone

From: afis...@linuxfoundation.org
When: 10:00 AM - 11:00 AM April 13, 2017
Subject: [onap-tsc] Invitation: ONAP Project: TSC Meeting @ Weekly from 7am to 
8am on Thursday from Thu Apr 13 to Thu Apr 27 (PDT) (onap-tsc at lists.onap.org)
Location: https://zoom.us/j/430425936


more details 
?
ONAP Project: TSC Meeting

Hi there,

As per the last TSC meeting, am putting placeholders for all April TSC meetings 
on calendars.


Agenda forthcoming. Thank you.


Annie


Annie Fisher is inviting you to a scheduled Zoom meeting.


Join from PC, Mac, Linux, iOS or Android: 


https://zoom.us/j/430425936


Or iPhone one-tap (US Toll): +14086380968,430425936# or +16465588656,430425936#


Or Telephone:


Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)


Meeting ID: 430 425 936


International numbers available: 


https://zoom.us/zoomconference?m=kG4zt84jv0sVUsFaKhXPIyWHpKACTSLh




Use of the Zoom services is subject to Zoom's Terms of Service 
(https://zoom.us/terms)















When

Weekly from 7am to 8am on Thursday from Thu Apr 13 to Thu Apr 27 Pacific Time

Where

https://zoom.us/j/430425936 
(map)

Calendar

onap-tsc at lists.onap.org

Who

?

afisher at linuxfoundation.org - organizer

?

onap-tsc at lists.onap.org



Going? All events in this series: 
Yes
 - 
Maybe
 - 
No
 more options 
?


Invitation from Google Calendar

You are receiving this courtesy email at the account onap-tsc at lists.onap.org 
because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. 
Alternatively you can sign up for a Google account at 
https://www.google.com/calendar/ and control your notification settings for 
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP 
response. Learn 
More.


-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-tsc] [onap-discuss] ONAP Project: Registration for May Developer Event

[Sauvageau, David]

Hi Annie & TSC members,

I would like to propose some kind of a hackathon during the Developer event in 
order to really make it a developer-focused event.

I believe that architecture, code merger strategy and release planning is 
definitely required for that session but if we are to regroup 75-100 developers 
and architects together then we should probably leverage the opportunity to 
have them to start working together.

We could propose an agenda where day 1 is targeted for general audience in 
order to discuss high-level architecture, merging strategy, release planning 
etc, but maybe there could be a parallel track for a hackathon during days 2-3 
or something. We could even have limited ECOMP+Open-O integration POCs at the 
end of the event.

Thoughts?

From:  on behalf of Annie Fisher 

Date: Monday, April 10, 2017 at 8:23 PM
To: "onap-tsc at lists.onap.org" , "onap-discuss at 
lists.onap.org" 
Subject: [onap-discuss] ONAP Project: Registration for May Developer Event

[nline image 1]

ONAP Project Developer Event
May 2 - 4, 2017
AT Labs Research, Middletown, NJ
Link to register:  https://www.regonline.com/ONAPDeveloper
Note: instructions for obtaining necessary visa letters as well at hotel 
information may be found by clicking this link.

Proposed Agenda/Subject Areas to be covered*:
Framework for code merger of Open-O and ECOMP code including:
- Agreement on Principles of merging the code
- Target applications to support in Release 1
- Consolidated Target Architecture of merged code for release 1
- Code modification & implementation methods for merging the code
- Other work to be done for first release
- Target date for first release
- Release cadence
.. *and more...


Annie Fisher, MPA CSM
Program Manager, The Linux Foundation
Location & Time-zone: San Francisco, CA, PST
web: https://www.linuxfoundation.org/
email: afisher at linuxfoundation.org
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 45521 bytes
Desc: image001.png
URL: