We understand the DCAE provide the framework and Holmes can be a sub-project as
one DCAE special application project. We can image there will be more and more
DCAE applications in more areas in the further.
In this case, we wish DCAE project as framework and the 'Holmes' as a
application project. Project risk division can be good for first release.
Best regards
Wang Rui
原始邮件
发件人： ＜rajesh.gadi...@intel.com＞
收件人： ＜ranny.ha...@nokia.com＞ ＜c...@research.att.com＞ ＜spat...@research.att.com＞
＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月17日 08:33
主 题 ：Re: [onap-tsc] Thoughts on next steps.
+1. I like this approach given our focus to get a good release out in Nov.
From: ＜onap-tsc-boun...@lists.onap.org＞ on behalf of "Haiby, Ranny (Nokia -
US/San Jose USA)" ＜ranny.ha...@nokia.com＞
Date: Tuesday, May 16, 2017 at 2:10 PM
To: "RATH, CHRISTOPHER A (CHRISTOPHER A)" ＜c...@research.att.com＞,
"SPATSCHECK, OLIVER (OLIVER)" ＜spat...@research.att.com＞, onap-tsc
＜onap-tsc@lists.onap.org＞
Subject: Re: [onap-tsc] Thoughts on next steps.
@Oliver – I share your concern about having 32 projects and gating the release
with deliverables from each one.
What I would like to propose is categorization of “core” and “non-core” (or a
less derogatory name) projects. Core projects are those that provide the
minimum viable product functionality, e.g. A&AI, Modeling, SO, etc. Some
projects seem like providing functionality beyond the MVP, such as CLAMP,
Holmes, etc. Some projects will fall somewhere in between and we could use our
common sense to categorize them.
This way the community could focus on reviewing the core projects first, and
the release will be gated by deliverables from these projects only. This does
not mean that non-core projects will not be approved and worked on in the
first release, assuming they are defined, approved and have contributors.
There are of course some bad implementation examples of such categorization
(OpenStack “Big Tent” anybody?) but I believe we can avoid past mistakes and
make this approach work for the benefit of the community.
Ranny.
From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org]
On Behalf Of RATH, CHRISTOPHER A (CHRISTOPHER A)
Sent: Tuesday, May 16, 2017 1:03 PM
To: SPATSCHECK, OLIVER (OLIVER) ＜spat...@research.att.com＞ onap-tsc
＜onap-tsc@lists.onap.org＞
Subject: Re: [onap-tsc] Thoughts on next steps.
For the areas in which I have contributions to consider, here are some
clarifications.
First, the Common Controller Framework should have overlap as far as scope with
a lot of projects. That is the point of that project, to find overlapping
functionality, develop it in a single project, and reuse it among the other
components. So I would not be concerned with any overlap between CCF and the
other projects dealing with deployment, management, orchestration, etc. That
is by design.
For DCAE: we have recognized an overlap with Holmes, which in my view should be
a sub-project of DCAE, but it does not appear that sub-projects were proposed
this way. DMaaP does not have an overlap with DCAE. DCAE uses DMaaP, as do
many other components, but the scopes are completely different. I believe the
functionality in DMaaP for data processing does not exist today and it is not
clear that it would be part of an open-source release of DMaaP or not anyway.
For DMaaP: The CCF overlap is by design. It is our intention to provide a
“Data Bus Controller” with responsibility for deploying and managing DMaaP data
delivery components where they are needed and when they are needed. That
functionality exists in DCAE today, but needs to be pulled out to be generally
available across ONAP components.
For MSB: I agree this should be part of CCF. It could be used by DCAE and OOM.
—
Christopher A. Rath
Director Inventive Science – Intelligent Services and Platforms Research
From: ＜onap-tsc-boun...@lists.onap.org＞ on behalf of "SPATSCHECK, OLIVER
(OLIVER)" ＜spat...@research.att.com＞
Date: Tuesday, May 16, 2017 at 3:47 PM
To: onap-tsc ＜onap-tsc@lists.onap.org＞
Subject: [onap-tsc] Thoughts on next steps.
***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
I just went through the proposals and noticed that quite a few of them have not
clearly defined boundaries between them which makes me wonder if they overlap
(see table below). From experience overlapping project definitions rarely lead
to good outcomes (duplicate work gets done and people are very upset at the
end…) so I think we should resolve this before approving the projects.
When I built this table I focused on what’s written in the proposals. Now from
discussions I think some of the perceived overlaps might just be a matter of
cleaning up the writing. Others might actually be real. In either case I think
we need to be clear and precise in the project description and can’t rely on
various email exchanges for this. I also don’t claim that my table is
complete. If you want I can put the table on the Wiki so people can add there
perceived or real overlaps.
I don’t know how you usually resolve those issues but I would think that the
project leads for all projects which might have an overlap define a common
statement which defines there relationship with each other in some level of
detail. Thoughts?
I also looked at the use cases. Lingli and her team did a great job cleaning up
the VoLTE use case:
https://wiki.onap.org/pages/viewpage.action?pageId=3246140
The flow charts are a great start but we do need to get into more details and
actually show the real API calls as well. I am also not sure I understand how
exactly the legacy Open-O and legacy ECOMP components integrate. I think the
next step here is to walk through this in detail. I don’t think that’s
something that can be done efficiently via email. I would suggest a call on the
topic. That might actually be better then a F2F in June as it allows more
developers to dial in.
One concern on this particular use case is that only Huawei and ZTE have any
VNFs in it. Personally I don’t think it’s a good start for an open project to
start with proprietary VNFs from mainly one manufacturer with some
contribution from a second. I wouldn’t even know how that worked in practice.
E.g. will those VNFs be available to competing vendors so they can test/develop
ONAP code?
This brings me to overall use case scope and reality.
Using Gilda’s release plan (all his fault after all :)) we have to work all of
this out by 6/29 (sounds a lot of time but really isn’t). Development is only 3
months till RC0. We have 32 projects. That’s 21 projects more then the seed
code of 8+3. If I ignore the toy use case we have two use cases proposed with
the VoLTE one having more details then the other. Coordinating interfaces one
on one for the 32 projects requires 512 meetings. …. I think if we are trying
to achieve all of this in release 1 we are setting ourselves up for failure.
If it was up to me I would probably just focus the use cases on instantiation
and one simple control loop. This might seem like very little but considering
the work we need to start the projects, set up the labs, get developers
familiar with the environment, get them lab access etc… which all takes time.
I think that would be realistic for a first release and then we can adjust the
second release accordingly.
In terms of projects I would be very careful which projects have deliverables
in release 1.0. . I don’t think having deliverable in release 1.0 is a gating
function of getting a project approved. So the TSC can approve projects that
make sense but as said I would discourage some of them to have a contribution
to the 1.0 release.
Probably just stating the obvious … .
Oliver
Project
Potential Scope Overlapp
AAI
APPC
Common Controller… , VF-C
Authentication…
CLAMP
Modeling
Common Controller …
VF-C, App-C, SDN-C, ONAP Operations Manager, Microservice Bus, DCAE, DMAAP,
MultiVIM, Service Orchestration
DCAE
Holmes, Common Controller…, DMAAP
DMAAP
Common Controller… , DCAE (mentions data processing)
Documentation
ONAP University
External API Framework
Modeling, External System Register, ONAP Extensibility
External System Register
External API Framework, ONAP Extensibility
Holmes
DCAE
ICE
VNF-SDK
Integration
ONAP Operations Manager
Microservice Bus
Common Controller …, ONAP Operations Manager
Modeling
CLAMP
Miulti Vim
Common Controller…
Network Function Change..
ONAP CLI
ONAP Extensibility
ONAP Operations Manager, External API Framework, External System Register
ONAP University
Documentation
ONAP Operations Manager
Common Controller… , Integration, Onap Extensibility
ONAP Usecase UI Project
Policy Driven VNF Orchestartion
Policy Framework, SNIRO
Policy Framework…
Policy Driven VNF Orchestration
Portal Platform …
SDN-C
Common Controller…
Service Design & Creation
Modeling
Service Orchestration
Common Controller…
SNIRO
Policy Driven VNF Orchestration
VF-C
Common Controller… , App-C
VID
VNF-SDK
ICE
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
