Re: [onap-tsc] Network Function Change Management Project Proposal

[Stephen Terrill]

Hi Oliver,

I think that we are at a stage where we are setting a precedent with this type 
of problem, so we may try one approach and decide it was or was not a good 
idea.  Yes, I would suggest the use case approach for this for release 2, where 
the output of the use case work is an understanding of the needs expressed on 
different projects.

BR,

Steve

-Original Message-
From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
Sent: 12 June 2017 17:00
To: Stephen Terrill <stephen.terr...@ericsson.com>
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Network Function Change Management Project Proposal


Steve,

I think the actual code would be contributions to various other projects e.g. 
CMO needs workflows but I would think those would be additional features in SO 
not a separate orchestrator for CMO. So the CMO team members would likely also 
become contributors in other projects but we wouldn’t need a separate code base.

So I think what you are recommending is to work this as a use case for release 
2 ?

Oliver

> On Jun 10, 2017, at 8:07 AM  EDT, Stephen Terrill 
> <stephen.terr...@ericsson.com> wrote:
> 
> Hi Oliver,
> 
> It might depend a little on the expected final intention. Is the final 
> expectation that there will be a new module required (I thought I'd heard 
> something about that could be the case), or whether it is expected that this 
> functionality is something that would be realised solely through additional 
> to the code produced by existing/already proposed projects?
> 
> If the former we could go and setup a project, if the latter is be leaning 
> towards use cases. 
> 
> We now need to keep in mind that the projects we start now don't have to be 
> aimed for the first release, but if there is a group interested and it 
> eventually plans to have a result I don't see why it couldn't start now if we 
> are clear on what it is to do. 
> 
> BR,
> 
> Steve
> 
> BR,
> 
> Steve. 
> 
> Sent from my Phone
> 
>> On 9 Jun 2017, at 11:23, SPATSCHECK, OLIVER (OLIVER) 
>> <spat...@research.att.com> wrote:
>> 
>> 
>> During the F2F meeting we discussed a project proposal on the topic. As this 
>> addresses workflows across components rather then build a component the 
>> question came up what form this should take. 4 options are proposed
>> 
>> 1. Make it a project and add a clear deliverable (e.g. Documentation) to the 
>> project proposal.
>> 2. Make this work part of the architecture subcommittee.
>> 3. Have a coordinator on this
>> 4. Make this a use case for r2
>> 
>> In my mind I don't like #2. as it removes the clear focus of this work.
>> 
>> The suggestion was made to ask the TSC on the mailing list for opinions.
>> 
>> So please advice.
>> 
>> Oliver
>> ___
>> 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] Network Function Change Management Project Proposal

[SPATSCHECK, OLIVER (OLIVER)]

Steve,

I think the actual code would be contributions to various other projects e.g. 
CMO needs workflows but I would think those would be additional features in SO 
not a separate orchestrator for CMO. So the CMO team members would likely also 
become contributors in other projects but we wouldn’t need a separate code base.

So I think what you are recommending is to work this as a use case for release 
2 ?

Oliver

> On Jun 10, 2017, at 8:07 AM  EDT, Stephen Terrill 
>  wrote:
> 
> Hi Oliver,
> 
> It might depend a little on the expected final intention. Is the final 
> expectation that there will be a new module required (I thought I'd heard 
> something about that could be the case), or whether it is expected that this 
> functionality is something that would be realised solely through additional 
> to the code produced by existing/already proposed projects?
> 
> If the former we could go and setup a project, if the latter is be leaning 
> towards use cases. 
> 
> We now need to keep in mind that the projects we start now don't have to be 
> aimed for the first release, but if there is a group interested and it 
> eventually plans to have a result I don't see why it couldn't start now if we 
> are clear on what it is to do. 
> 
> BR,
> 
> Steve
> 
> BR,
> 
> Steve. 
> 
> Sent from my Phone
> 
>> On 9 Jun 2017, at 11:23, SPATSCHECK, OLIVER (OLIVER) 
>>  wrote:
>> 
>> 
>> During the F2F meeting we discussed a project proposal on the topic. As this 
>> addresses workflows across components rather then build a component the 
>> question came up what form this should take. 4 options are proposed
>> 
>> 1. Make it a project and add a clear deliverable (e.g. Documentation) to the 
>> project proposal.
>> 2. Make this work part of the architecture subcommittee.
>> 3. Have a coordinator on this
>> 4. Make this a use case for r2
>> 
>> In my mind I don't like #2. as it removes the clear focus of this work.
>> 
>> The suggestion was made to ask the TSC on the mailing list for opinions.
>> 
>> So please advice.
>> 
>> Oliver
>> ___
>> 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] Network Function Change Management Project Proposal

[Stephen Terrill]

Hi Oliver,

It might depend a little on the expected final intention. Is the final 
expectation that there will be a new module required (I thought I'd heard 
something about that could be the case), or whether it is expected that this 
functionality is something that would be realised solely through additional to 
the code produced by existing/already proposed projects?

If the former we could go and setup a project, if the latter is be leaning 
towards use cases. 

We now need to keep in mind that the projects we start now don't have to be 
aimed for the first release, but if there is a group interested and it 
eventually plans to have a result I don't see why it couldn't start now if we 
are clear on what it is to do. 

BR,

Steve

BR,

Steve. 

Sent from my Phone

> On 9 Jun 2017, at 11:23, SPATSCHECK, OLIVER (OLIVER) 
>  wrote:
> 
> 
> During the F2F meeting we discussed a project proposal on the topic. As this 
> addresses workflows across components rather then build a component the 
> question came up what form this should take. 4 options are proposed
> 
> 1. Make it a project and add a clear deliverable (e.g. Documentation) to the 
> project proposal.
> 2. Make this work part of the architecture subcommittee.
> 3. Have a coordinator on this
> 4. Make this a use case for r2
> 
> In my mind I don't like #2. as it removes the clear focus of this work.
> 
> The suggestion was made to ask the TSC on the mailing list for opinions.
> 
> So please advice.
> 
> Oliver
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc


smime.p7s
Description: S/MIME cryptographic signature
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Network Function Change Management Project Proposal

[SPATSCHECK, OLIVER (OLIVER)]

During the F2F meeting we discussed a project proposal on the topic. As this 
addresses workflows across components rather then build a component the 
question came up what form this should take. 4 options are proposed

1. Make it a project and add a clear deliverable (e.g. Documentation) to the 
project proposal.
2. Make this work part of the architecture subcommittee.
3. Have a coordinator on this
4. Make this a use case for r2

In my mind I don't like #2. as it removes the clear focus of this work.

The suggestion was made to ask the TSC on the mailing list for opinions.

So please advice.

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