Re: [onap-tsc] R2 use cases planning

[SPATSCHECK, OLIVER (OLIVER)]

Just to be clear it’s development resources – people writing actual code.

Let me also try to separate resources a bit:


1.   There are core development resources. People which write, integrate 
and test code which is part of the platform.

2.   There are developers which work on particular use cases (e.g. building 
VNFs, configuring ONAP, … ) but are not directly involved in the platform 
development.

3.   There are architects/planers/coordinators supporting 1. + 2.

To work of technical debt we have to protect 1.).

2.) is somewhat self regulating. If somebody wants a particular use case s/he 
usually provides 2.) but typically still expects the community to support 1.) 
which is where the problem starts.

Generally 3.) can come up with good ideas at a much faster pace than 1.) can 
handle so 3.) is rarely a bottleneck. (I never had a project where there was a 
shortage of good ideas.)

So unless we see a huge influx of new 1.) for Beijing that is what we need to 
manage carefully.

So use cases which do not require any 1.) work can be done now by anybody. E.g. 
if you can do a 5G use cases without involvement from 1.) who is stopping you? 
Just do it! That’s the self serve concept Mazin mentioned.

However, use cases which require lots of 1.) work will just add rather then 
remove technical dept.

Hope that helps!

Oliver
p.s. FYI good and entertaining books on that topic are “The Phoenix Project” 
and “Creativity Inc.”

From:  on behalf of "Vladimir Yanover 
(vyanover)" 
Date: Friday, August 18, 2017 at 5:42 AM
To: Jason Hunt , Alla Goldner 
Cc: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] R2 use cases planning

what is this resource that should be managed
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] [modeling][sdc][vfc][so][vnfsdk][sdnc][uui] Agenda of modeling project/subcommittee for tomorrow teleconf

[denghui (L)]

Hello all

This Thursday is the deadline for freezing of API, normally it means freezing 
of modeling spec for R1. We can't always delay until the deadline for code 
freezing :)
even tomorrow was planned for modeling project, we will borrow most time from 
modeling project to discuss the status of interface and modeling spec, to check 
whether we need additional call in this week.


1)  Modeling project, (only 1 tosca parser is on the repo for VFC, UUI 
hasn't confirmed yet)



2)  Check the status of interface and modeling spec

Interfaces

a)   VNFSDK-SDC

b)   SDC-SO

c)SDC-VFC

d)   SO-VFC

e)   SO-SDNC
Modeling specs
1.a) VNFD (skip for R1?)
1.b) SD
1.c) NSD
1.d) WAN spec
1.e) vnf package (skip for R1)



3)  ONAP modeling namespace

Thanks a lot

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

Re: [onap-tsc] R2 use cases planning

[GILBERT, MAZIN E (MAZIN E)]

Alla, Team

Agree with the discussion below that the goal of R1 has been on integration of 
Open-O with Open ECOMP.
One of the key goals for R2 should be maturing the platform to an “enterprise” 
grade, specifically the non-functional aspects.
We should have measures and frameworks that evaluate those measures so we track 
progress.

Another key goal of R2 should be to create additional platform capabilities 
that can promote self-service of the platform.
I.e., we may not develop many new applications for R2, but with R2, the user 
community should be able to develop
a number of new applications that require new VNF instantiation, micro services 
on-boarding and closed loop automation with no development.

Very exciting discussion topic. Let’s organize and plan to reach a conclusion 
at the F2F meeting in Sep.

Mazin



On Aug 18, 2017, at 7:27 AM, Alla Goldner 
> wrote:

Hi Vladimir, all,

Thanks for all replies received so far!

Vladimir, this is not about meeting time resources, I believe. Meeting time can 
be extended, if necessary.
The limitation and the need to reduce the scope comes from the fact that 
different projects will have to support related functionality, Integration team 
will have to do all integration work around approved use cases etc.

R1 major goal, as Mazin mentioned yesterday, is about merging Openecomp and 
Open-O code and we decided that the best way to achieve this goes though 
implementing R1 use cases. However, we compromised on ONAP Platform 
functionalities – some of them appear on the dedicated wiki page already, some 
more will be included by the community members. And, as also appears in my 
presentation yesterday
“- Issue of the technical debt we are acquiring in R1 and how to pay that off
• If we load R2 at 100% capacity with new features this may never get cleaned 
up and ONAP may eventually collapse under its own complexity.”

When we develop a use case it typically consists of 2 different aspects:

1.   New ONAP platform capabilities
2.   New functionality related to specific use case, including connectivity 
support, support of new VNFs etc.

For example, if we were guided to concentrate on ONAP Platform capabilities 
only, we then would support R2 with R1 only use cases by implementing ONAP 
Platform capabilities missing in R1, and by also aligning this with R2 target 
architecture view. As clearly, (2) above requires additional effort. This, I 
guess, goes back to the question asked by Jason on R2 goal – and, also in my 
view, as Jason put it, “R2 would be about strengthening the non-functional 
aspects of the platform (usability, maintainability, scalability, reliability, 
etc.) to provide an unrivaled, hardened platform that can be leveraged in any 
carrier's environment.”

And, yet another example, if we agree to decide on case-by-case basis, as 
proposed by Vladimir and by Rajesh, we need criteria on how we select to 
support use cases/missing Platform capabilities. And Ranny provided a great 
list of initial criteria to be used for this goal, if we decide to go in this 
direction.

We are looking for more inputs on this, as this will eventually determine the 
direction R2 takes.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology




From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Friday, August 18, 2017 12:43 PM
To: Jason Hunt >; Alla Goldner 
>
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] R2 use cases planning

Jason, Alla and All
Just to understand the topic, what is this resource that should be managed 
here; is it e.g. meeting time?
Speaking of the #1 below, I understand it as that some ONAP platform 
capabilities are missing so that the agreed R1 use cases cannot be supported. 
If this is the case, the gap certainly should be closed, but it’s R1 work item, 
isn’t it? One therefore can expect that there will be R1 related activities 
(“R1 work items”) and R2 related activities (“R2 work items”) with some 
resource partitioning between them.
Speaking of R2 related activities, we certainly need some selection of use 
cases, but I think it should go on case by case basis: importance, complexity 
of new platform capabilities needed (if any), timeline etc.
Thanks
Vladimir

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Jason Hunt
Sent: Thursday, August 17, 2017 10:16 PM
To: Alla Goldner >
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] R2 use cases planning

Alla,

Thank you for your leadership here and for the work of the use case committee 
on this topic.

ONAP should be able to run any VNF or network service, even ones that aren't 
known today.