Hi, Stephen,
Regarding step 9:
There’re two kinds of integration testing:
1. one is for developers: we will try our best to use open source, not
necessary “dummy” VNFs, for the CI / CD testing. Windriver has kindly
contributed their OPNFV labs for this purpose; and Integration team has started
related initial setup in that env. We’ll try to give all developers access to
this env for their daily CI/CD testing eventually.
2. The second one is gating use case deployment: this is an E2E one, which may
or may not include PNFs. The criteria for us are:
a. It needs to cover the important ONAP platform related functionalities
b. Under R1 timeframe.
This lab could be the same as item 1 or a different one. But we’ll try to reuse
as much our work as possible from item 1, such as service template,
configuration, policy, security, etc. This will also give some developers
access as well, but at a later stage of ONAP release cycle. The main purpose
for this one is for gating use case testing, not demo even though it could be
used for demo.
Regards,
Helen Chen
On 6/20/17, 12:35 AM, "Stephen Terrill" <stephen.terr...@ericsson.com> wrote:
Hi,
Thanks for bringing to the TSC list Alla.
A few things to keep in mind that I think are reflected here.
- When approving the use-case committee I asked about the flows and
the clarification was that the use case committee would work with high level
flows. I agree that this is required to help identify the needs to be placed
on the projects. We do want to keep in mind, though, that the use cases are
guidance on what the ONAP should support and shouldn't be viewed as defining
ONAP as that would be limiting.
- Step 6: I would extend to this to capture "new functionality" to
existing modules as well - as architecture is about functional allocation to
the modules and identifying the needs on the interfaces.
- Step 8 where it says that the detailed per component flows are
created, I assume that is in the project for that component and with the API
definition of that project?
- Step 9 says that the integration project finalizes the PNF/VNF
selection. That is not aligned with what we discussed in Beijing where we said
the integration project would work with "dummy" NFs that everyone can get hold
of. We don't expect commercial, nor even all non-commercial VNFs to be handled
in the integration projects, we said that would be in demo labs for the use
cases. My understanding of the integration project is to bring all components
of the NFs together and test the different life-cycle phases on the dummy VNFs,
its not about demoing the use cases.
BR,
Steve
PS - For R1 the project definitions have high level flows, I assume that
for R1 there is not too much more for the sub-committee to do right??
-----Original Message-----
From: Alla Goldner [mailto:alla.gold...@amdocs.com]
Sent: 20 June 2017 08:08
To: Yoav Kluger <yoav.klu...@amdocs.com>; SPATSCHECK, OLIVER (OLIVER)
<spat...@research.att.com>; Yunxia Chen <helen.c...@huawei.com>
Cc: Stephen Terrill <stephen.terr...@ericsson.com>;
onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>;
onap-usecase...@lists.onap.org
Subject: RE: [onap-discuss] Use Case Subcommittee Flow
Hi all,
Please see the proposed update of the flow, based on the comments received
from Yoav and from Chris:
1. Use case subcommittee discuses new use cases
2. Use case subcommittee produces use case flow diagrams, provides its
view on the foreseen modules introductions/modifications and suggests potential
PNFs / VNFs
3. Use case subcommittee gets feedback from the potentially effected
projects including integration team on feasibility
4. Iterate back to 2.
5. TSC approves the use case
6. In case new modules or new API introduction is foreseen, architecture
subcommittee defines the new/modified ONAP flows and the interfaces principles,
based on the approved use cases
7. Projects define their extended functionality and their external APIs,
following those principles.
8. Detailed per-component flows are defined and projects write their user
stories / implement them; Integration team continuously works with Use case
subcommittee to accompany the use case development, review epics/user stories,
answer questions, etc. Use case subcommittee behaves as system engineers for
the use case through test start date
9. Integration team defines the gating use case based on step 8 and
finalizes the PNFs / VNFs selection, with the help of use case subcommittee,
architecture subcommittee, PTLs of a different ONAP projects
10. TSC approves the gating use case
11. Integration project leads (coordinates) effort to get the gating use
case tested, repaired, and verified, and the results are documented.
Please let me know if it makes sense.
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
-----Original Message-----
From: Yoav Kluger
Sent: Tuesday, June 20, 2017 12:02 AM
To: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>; Yunxia Chen
<helen.c...@huawei.com>
Cc: Alla Goldner <alla.gold...@amdocs.com>; Stephen Terrill
<stephen.terr...@ericsson.com>; onap-disc...@lists.onap.org
Subject: RE: [onap-discuss] Use Case Subcommittee Flow
Hi,
As far as I recall from the first architecture subc. meeting, it is not
responsible for defining APIs, although we did discuss the possibility that we
would want to guide as to the --what-- should be conveyed in APIs. And this is
for new APIs only.
My understanding of phase 6 here, and we probably should clarify this, is
that the architecture subc. Kick in only when there are new APIs, or new
modules, that are required to support the use case. If there are then it is
vital that the arch subc to address this in a timely manner to make sure
further work post phase 6 can progress. Also, I think what was said for the use
case subc is true for the arch subc: as user stories are written, deeper
understanding is reached as to what is required, and what was not apparent at
an earlier stage may become apparent at a later stage - requiring attendance of
the arch subc not seen earlier. I would not propose to also change this in our
phases definition here, but I would assume when the arch subc articulates its
phases it may want to clarify that.
Having said that, in the vCPE use case I don't think we have any such new
elements. So with the above proposed modifications we can say we are in phase 7.
Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
-----Original Message-----
From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: Monday, June 19, 2017 3:33 PM
To: Yunxia Chen <helen.c...@huawei.com>
Cc: Alla Goldner <alla.gold...@amdocs.com>; Yoav Kluger
<yoav.klu...@amdocs.com>; Stephen Terrill <stephen.terr...@ericsson.com>;
onap-disc...@lists.onap.org
Subject: Re: [onap-discuss] Use Case Subcommittee Flow
OK.
So are we following this for release 1.?
If yes we completed step 5 ( I guess we are official still voting on vCPE
but we did get the majority number of votes already so it is bound to pass…).
That would mean step 6. has to kick in.
Is the architecture subcommittee willing to step up to this? As we need
to have user stories for the projects by the end of the month the architecture
subcommittee would have to close on this really this week so the projects can
start on assessing the impact and writing user stories.
Chris any comments?
If we are following a different process for release one who is doing the
work required in step 6.?
Thx
Oliver
> On Jun 19, 2017, at 3:10 PM EDT, Yunxia Chen <helen.c...@huawei.com>
wrote:
>
> Thanks Alla and Yoav to put it together. Since Integration team will make
automatic CI/CD far before the real release, I suggest that they get involved
asap: the more they understand the use case, the more they could develop the
testing cases. And most importantly they define the gating use case.
>
> I suggest to make some minor adjust on the flow:
>
> 1. Use case subcommittee discuses new use cases
> 2. Use case subcommittee produces use case flow diagrams, ONAP
flow diagrams, and suggests potential PNFs / VNFs
> 3. Use case subcommittee gets feedback from the potentially
effected projects including integration team on feasibility
> 4. Iterate back to 2.
> 5. TSC approval
> 6. Architecture subcommittee defines the general new/modified
interfaces principles, based on approved use cases
> 7. Projects define their extended functionality and their
external APIs, following those principles.
> 8. Detailed per-component flows are defined and projects write
their user stories / implement them; Integration team will work with use case
subcommittee continues to accompany the use case development, review epics/user
stories, answer questions, etc. (behave as system engineers for the use case)
through test start date.
> 9. Integration team will define the gating use case based on step
8; and finalize the PNFs / VNFs selection, with the help of use case
subcommittee, architecture subcommittee, PTLs with ONAP projects
> 10. TSC approval the gating use case.
> 11. Integration project leads (coordinates) effort to get the
gating use case tested, repaired, and verified, and the results will be
documented.
>
> Regards,
> Helen Chen
>
> On 6/19/17, 11:39 AM, "onap-discuss-boun...@lists.onap.org on behalf of
Alla Goldner" <onap-discuss-boun...@lists.onap.org on behalf of
alla.gold...@amdocs.com> wrote:
>
> Hi Yoav, Oliver, Steve, all,
>
> Firstly, I believe we need to distinguish R1 from any future release.
The methodology we build here would be good to work with in the future
releases, but not immediately.
> For our immediate R1 work we need to quickly start interaction
between the use cases teams, the integration team and the projects, making sure
all these are aligned.
>
> For the longer term activities, I would say, following Yoav's
description below and the other received comments, we may consider the
following split:
>
> 1. Use case subcommittee discuses new use cases
> 2. Use case subcommittee produces use case flow diagrams and
ONAP flow diagrams
> 3. Use case subcommittee gets feedback from the potentially
effected projects including integration team on feasibility
> 4. Iterate back to 2.
> 5. TSC approval
> 6. Architecture subcommittee defines the general new/modified
interfaces principles, based on approved use cases
> 7. Projects define their extended functionality and their
external APIs, following those principles.
> 8. Detailed per-component flows are defined and projects
write their user stories / implement them; Use case subcommittee continues to
accompany the use case development, review epics/user stories, answer
questions, etc. (behave as system engineers for the use case) through test
start date
> 9. Integration project leads (coordinates) effort to get the
use case tested, repaired, and verified
>
> Best regards,
>
> Alla Goldner
>
> Open Network Division
> Amdocs Technology
>
>
>
>
>
> -----Original Message-----
> From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yoav Kluger
> Sent: Monday, June 19, 2017 9:07 PM
> To: Stephen Terrill <stephen.terr...@ericsson.com>; SPATSCHECK,
OLIVER (OLIVER) <spat...@research.att.com>; onap-disc...@lists.onap.org
> Subject: Re: [onap-discuss] Use Case Subcommittee Flow
>
> Hi,
>
> The use case work involves two activities:
> 1. Define the use case, in particular the specifics of the use
case which should be proven for a given release.
> 2. Define ONAP delivery of the use case, i.e. ONAP flow
diagrams
>
> Activity 1 requires domain expertise in the specific area of the use
case. As an example, in the vCPE case we needed to know the base spec if one
existed - in our case it was TR-317, and related technologies. Then we needed
to take use case architectural decisions based on a) what elements from the
spec we want to define as deliverables for R1; b) what modifications are
needed in various components of the use case; c) take lower level decisions
which the spec leaves undefined but which must be taken in order for the use
case to work and make sense to its customers.
>
> These expertise will typically reside in the use case subc. and not
necessarily in the integration project, whose main expertise will be in
integrating all ONAP pieces, producing the right lab environment, and verify
that ONAP does what it is supposed to do. Somewhere very close to test start
time you would expect the integration team to gain some expertise in the
specific use case - but this will be very close to the time it needs to be
tested and long after development of this use case in the various projects has
started.
>
> Since this is not about ONAP architecture but rather about the use
case architecture - these expertise would also not necessarily reside in the
architecture subc.
>
> Therefore the way I understand the flow is:
> 1. Use case subcommittee discuses new use cases
> 2. Use case subc produces use case flow diagrams and ONAP flow
diagrams
> 3. Use case subcommittee gets feedback from the potentially
effected projects including integration team on feasibility
> 4. Iterate back to 2.
> 5. TSC approval
> 6. Detailed per-component flows are defined and projects write
their user stories / implement them; Use case subc continues to accompany the
use case development, review epics/user stories, answer questions, etc. (behave
as system engineers for the use case) through test start date
> 7. Integration project leads (coordinates) effort to get the
use case tested, repaired, and verified
>
> Thanks,
> Yoav Kluger
> Amdocs Technology
> +1(201)912-7294
> +972-54-4850278
>
>
>
> -----Original Message-----
> From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Stephen Terrill
> Sent: Monday, June 19, 2017 1:45 PM
> To: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>;
onap-disc...@lists.onap.org
> Subject: Re: [onap-discuss] Use Case Subcommittee Flow
>
> Hi,
>
> I wasn't in the use case subcommittee meeting today, so I was
wondering what is meant by "integration project leads (coordinates) effoerts to
get detailed flows ..." If these are information flows between the components,
then we have 3 places that would be doing such flows: UC subcommittee,
Architecture sub-commiteed, integration project. It seems like too many.
>
> Can we have the use-case sub-committee doing the high level flows for
the use case, only sufficient level to identify the requirements on the
components. The architecture group is having the flows to show the general
principles, then the APIs are done in the proejcts?
>
> BR,
>
> Steve
>
> -----Original Message-----
> From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER
(OLIVER)
> Sent: 19 June 2017 16:31
> To: onap-disc...@lists.onap.org
> Subject: [onap-discuss] Use Case Subcommittee Flow
>
>
> Based on the discussion in the subcommittee meeting my understanding
on how use cases get worked from the beginning to the end is like follow:
>
> 1. Use case subcommittee discuses new use cases 2. Use case
subcommittee gets feedback from community including integration team on
feasibility 3. Iterate back to 1.
> 4. TSC approval
> 5. Integration project leads (coordinates) effort to get detailed
flows with the help of the other projects and the release manager 6. Detailed
flows are defined and projects write there user stories/implement them 7.
Integration team tests flows and use case
>
> Did I capture this correctly? Does that make sense to everybody?
>
> Thx
>
> Oliver
> _______________________________________________
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> _______________________________________________
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 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://www.amdocs.com/about/email-disclaimer>
>
> _______________________________________________
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 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://www.amdocs.com/about/email-disclaimer>
>
> _______________________________________________
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
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://www.amdocs.com/about/email-disclaimer>
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
