from:"SPATSCHECK, OLIVER \(OLIVER\)"

Re: [onap-tsc] [onap-discuss] Importance of common auth service in this release

2017-09-08 Thread SPATSCHECK, OLIVER (OLIVER)


Kanagaraj,

we started collecting none functional requirements for the next release here:

https://wiki.onap.org/display/DW/R2+proposals+for+Non-functional+requirements

so they can be prioritized. Could you document your suggestion there?

I do agree that our authentication/authorization setup needs some substantial 
thought to get to what is needed.  I would try to address all of them with a 
consistent architecture so below is one part of that.

Thx

Oliver


From:  on behalf of Kanagaraj Manickam 

Date: Thursday, September 7, 2017 at 9:59 AM
To: "onap-tsc@lists.onap.org" 
Cc: "onap-disc...@lists.onap.org" 
Subject: [onap-discuss] Importance of common auth service in this release



Dear TSC team,

This mail is regarding the importance of common auth service in this release. 
please find more details below.

In Onap 1.0, we are using the Portal user management feature with required role 
in place for user authentication and the REST API for every ONAP components are 
not published. so for end user, portal is the only access point and there was 
no need of common user management across services, which portal user management 
took care of it.

But in Onap 1.1 (amesterdam) release, we have already published REST API for 
every components and we have now MSB to register all the ONAP components and 
get discovered by
user or integration components. so now, user could discover and operate every 
onap componenet's feature by using the REST API with deafult user credentails 
published for every ONAP component. But when user operate the same feature via 
portal, (s)he should go thru the portal user authedication and authorization. 
so this scenario brings the inconsistency.

In this scenario, I believe that we should be providing the common user 
authedication and authorization service across all ONAP components, simliar to 
OpenStack keystone service. And we are already having AAF to address this 
scenario. so Should we make AAF as mandatory component in amesterdam release 
and every onap components get aligned with it?

Thanks.

Regards
Kanagaraj M

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

Re: [onap-tsc] [Onap-usecasesub] R2 use cases planning

2017-08-29 Thread SPATSCHECK, OLIVER (OLIVER)


I like where this is heading. If we were true agile we would decouple this a 
bit.

We take the use cases, break them down in platform features, add the platform 
features to the backlog of each project and each project can decide which 
platform backlog features to work on for the next release.  There might be some 
minimal coordination needed (minimal set of required features for the next 
release) to arrive at a working system but it would be much lighter touch then 
now. It would also allow projects to think about the bigger picture when making 
implementation decisions as they would know what will be coming in the future 
and they don’t just add a “fix” for the next use case requested.

Oliver

From:  on behalf of Alla Goldner 

Date: Wednesday, August 23, 2017 at 12:41 PM
To: "Vul, Alex" , onap-usecasesub 

Cc: "onap-tsc@lists.onap.org P" 
Subject: Re: [Onap-usecasesub] [onap-tsc] R2 use cases planning

Right, and this is what we are supposed to do in September, please see attached 
the previously distributed milestones plan proposal.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D32097.92242830]

From: Vul, Alex [mailto:alex@intel.com]
Sent: Wednesday, August 23, 2017 7:35 PM
To: Alla Goldner ; onap-usecasesub 

Cc: onap-tsc@lists.onap.org P 
Subject: RE: [onap-tsc] R2 use cases planning

Hi Alla,

Agree with what you are saying. I would even go a step further and say that the 
use case subcommittee needs to develop a use case pipeline that would inform 
ONAP architecture/design and implementation activities *ahead* of time when 
particular functionality is required for use case support.

Thanks,

Alex Vul
Intel Corporation


From: Alla Goldner [mailto:alla.gold...@amdocs.com]
Sent: Wednesday, August 23, 2017 9:31 AM
To: Vul, Alex >; onap-usecasesub 
>
Cc: onap-tsc@lists.onap.org P 
>
Subject: RE: [onap-tsc] R2 use cases planning

Hi Alex,

Of course, we can do it, I agree.
However, would be good to also define which functional scope is targeted for R2 
5G use case explicitly.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D32097.92242830]

From: Vul, Alex [mailto:alex@intel.com]
Sent: Wednesday, August 23, 2017 7:26 PM
To: Alla Goldner >; 
onap-usecasesub 
>
Cc: onap-tsc@lists.onap.org P 
>
Subject: RE: [onap-tsc] R2 use cases planning

Alla,

I would suggest that we continue working on 5G use cases in their entirety, 
even though we may only be able offer a subset of 5G support in R2. I think 5G 
use cases present a set of significant challenges from the ONAP 
architecture/design perspective – both in terms of changes to existing 
components, as well as functionality that is missing all together. It would be 
good to consider these challenges as we continue to refine the ONAP 
functionality/capabilities in R2 and beyond. Going into R3, we should have 
enough capabilities to support a full-features 5G use case…

My two cents,

Alex Vul
Intel Corporation



From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Wednesday, August 23, 2017 9:16 AM
To: onap-usecasesub 
>
Cc: onap-tsc@lists.onap.org P 
>
Subject: Re: [onap-tsc] R2 use cases planning

Hi all,

Let me try to summarize some interim results of this discussion:


1.  There seem to be consensus that R2 major goal is to concentrate on 
supporting ONAP Platform capabilities missing in R1, which would eventually 
lead to mature “enterprise grade” platform and introduction of a new services 
which would come with minimal/no new development.

2.  With that, there is a desire to have some new use cases in R2, though 
would be ideal if those new use cases can be based on introduced Platform 
capabilities/support of existing services, thus no significant time would be 
spend on the functional aspects of those use cases.


As a result



3.  We work on/extend the list of ONAP missing Platform capabilities

Re: [onap-tsc] R2 use cases planning

2017-08-21 Thread 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

Re: [onap-tsc] Migration to *.onap.org

2017-08-04 Thread SPATSCHECK, OLIVER (OLIVER)


Also not sure if it is entirely black and white. There might be some projects 
we can move in the R1 timeframe if we allow for one project at a time 
migration. Then the PTL can make that choice based on there workload and 
project complexity.

Oliver

> On Aug 4, 2017, at 2:44 AM  EDT, LEFEVRE, CATHERINE  
> wrote:
> 
> ***Security Advisory: This Message Originated Outside of AT ***
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> Good morning Stephen,
>  
> Thank you for your feedback.
>  
> I will definitively finalize the high level plan as requested and will 
> organize a call accordingly in the coming days.
> I will also consider Gildas’ feedback based on the discussions we had with 
> the LF Council.
>  
> Best regards
> Catherine
>  
> From: Stephen Terrill [mailto:stephen.terr...@ericsson.com] 
> Sent: Thursday, August 03, 2017 8:22 PM
> To: Lefevre, Catherine ; onap-tsc@lists.onap.org
> Subject: RE: Migration to *.onap.org
>  
> Hi Catherine,
>  
> I can understand the complexities (and this was confirmed internally for me).
>  
> I think that there are some basic things we need to cover, already mentioned 
> by Gildas, such as removing commented references to what is considered 
> proprietary, or owned,  code etc, even if that is not what you are addressing 
> below.
>  
> What could be good to resolve the discussion is to at a high level, like you 
> have, state down the high level options that we have with the associated 
> risks.  E.g.
> -Initial big bang migration 
> o   Start now: 
> §  Move all projects at once 
> ·Advantage: Clean slate for R1
> ·Risk: several weeks to sort out, release 1 delay unmitigated risk.
> §  Move projects one at a time 
> ·Advantage: 
> o   Controlled migration
> ·Disadvantage 
> o   Implication for each project to reference old and new dependancies
> o   Time to migration (could it be done by R1 Release)
> o   Risk delay to R1 due to stablising after migration
> §  Move projects after xxx (code freeze, …?) 
> ·….
> BR,
>  
> Steve
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Lefevre, Catherine
> Sent: 01 August 2017 14:07
> To: onap-tsc@lists.onap.org
> Subject: [onap-tsc] Migration to *.onap.org
>  
> Dear ONAP TSC,
>  
> I fully understand the request about the seed code to be migrated to 
> *.onap.org.
> Nevertheless I want to bring to your attention that this request will require 
> significant effort (development, testing and infrastructure changes)
>   • Coordinate and update Maven dependencies and links
>   • Update namespaces as required
>   • Change the source code in order to align with *.onap.org for each 
> impacted project
>   • Change the development scripts
>   • Review and update automated test cases
>   • Re-adjust the LF infrastructure accordingly, keeping the 
> org.openecomp version in place until the end of migration
> That way each project can control the pace of migration from org.openecomp -> 
> org.onap : especially for the projects that are already based on the previous 
> naming.  
>   • Review and re-adjust build jobs to be approved by CI-Management 
> project
>   • Create a temporary environment to perform the necessary code changes
>   • Plan the migration in order to avoid any drastic impact on the ONAP 
> community
>   • Recreate new docker images and stabilize the complete ONAP Environment
>   • Etc.
>  
> Based on past experience (moving from *.att.com to *.openecomp.org), this 
> effort can take up to several weeks until the ONAP release is completely 
> stabilized
> If we pursue in this direction then it is a major risk for our Amsterdam 
> release to be completed on time.
> We will need to review the scope of ONAP R1 based on our resource capacity.
>  
> Or we can develop a complete migration plan as part of our ONAP R1 commitments
> And implement this migration in October as part of ONAP R2 preparation.
>  
> Is it something we can discuss during our next TSC meeting?
>  
> Thanks in advance for your consideration.
>  
> Many thanks & regards
> Catherine
>  
> Catherine Lefèvre
> AT Network and Shared Services
> D2 Platform & Systems Development
> AVP Software Development & Engineering
> ECOMP/ONAP/RUBY/SPP
>  
>  
> Phone: +32 2 418 49 22
> Mobile: +32 475 77 36 73
> catherine.lefe...@intl.att.com
>  
> TEXTING and DRIVING… It Can Wait
> AT
> BUROGEST OFFICE PARK SA
> Avenue des Dessus-de-Lives, 2
> 5101 Loyers (Namur)
> Belgium
>  
>  
> NOTE: This email (or its attachments) contains information belonging to the 
> sender, which may be confidential. proprietary and/or legally privileged. The 
> information is intended only for the use of the individual(s) or entity(ies) 
> named above. If you are not the intended recipient, you are hereby notified 
> that any disclosure, distribution or taking of any

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

2017-08-03 Thread SPATSCHECK, OLIVER (OLIVER)


I think we all agree on the goal. I do wonder though how much of what you see 
is an artifact of projects getting established and moving large pre existing 
code fragments as seed code into the correct location and how much is really 
new development which has started for this release and been done behind closed 
doors.

My suspicion is that the majority has to do with project formation and 
acquiring/organizing preexisting seed code right now. If a project wants to 
ingest preexisting seed code it makes little sense to do it in smaller junks 
just to meet some commit size benchmark.

On the other hand if we are still seeing this size of commits in October we 
have a problem.

Oliver


On Aug 3, 2017, at 2:23 AM, Alla Goldner 
> wrote:

Hi David, all,

Thanks for raising this issue!

Similar to others, I believe we should handle this by creating (and then 
enforcing) best practices on code quality and code reviews starting from 
Release 2.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology




From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Sauvageau, David
Sent: Wednesday, August 02, 2017 7:37 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

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,


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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=S27l99VDRzQ_iZU9kZeYryRytPjTzB6MiMPhfYlhLoU=E2TUNSyrxTh2UC95WY-VS57POZGyekyRes4WloON6V0=

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

Re: [onap-tsc] Migration to *.onap.org

2017-08-01 Thread SPATSCHECK, OLIVER (OLIVER)

Could we put that on the TSC agenda on Thu?

Thx

Oliver

> On Aug 1, 2017, at 8:07 AM  EDT, LEFEVRE, CATHERINE  
> wrote:
> 
> ***Security Advisory: This Message Originated Outside of AT ***
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> Dear ONAP TSC,
>  
> I fully understand the request about the seed code to be migrated to 
> *.onap.org.
> Nevertheless I want to bring to your attention that this request will require 
> significant effort (development, testing and infrastructure changes)
> ·Coordinate and update Maven dependencies and links
> ·Update namespaces as required
> ·Change the source code in order to align with *.onap.org for each 
> impacted project
> ·Change the development scripts
> ·Review and update automated test cases
> ·Re-adjust the LF infrastructure accordingly, keeping the 
> org.openecomp version in place until the end of migration
> That way each project can control the pace of migration from org.openecomp -> 
> org.onap : especially for the projects that are already based on the previous 
> naming.  
> ·Review and re-adjust build jobs to be approved by CI-Management 
> project
> ·Create a temporary environment to perform the necessary code changes
> ·Plan the migration in order to avoid any drastic impact on the ONAP 
> community
> ·Recreate new docker images and stabilize the complete ONAP 
> Environment
> ·Etc.
>  
> Based on past experience (moving from *.att.com to *.openecomp.org), this 
> effort can take up to several weeks until the ONAP release is completely 
> stabilized
> If we pursue in this direction then it is a major risk for our Amsterdam 
> release to be completed on time.
> We will need to review the scope of ONAP R1 based on our resource capacity.
>  
> Or we can develop a complete migration plan as part of our ONAP R1 commitments
> And implement this migration in October as part of ONAP R2 preparation.
>  
> Is it something we can discuss during our next TSC meeting?
>  
> Thanks in advance for your consideration.
>  
> Many thanks & regards
> Catherine
>  
> Catherine Lefèvre
> AT Network and Shared Services
> D2 Platform & Systems Development
> AVP Software Development & Engineering
> ECOMP/ONAP/RUBY/SPP
>  
>  
> Phone: +32 2 418 49 22
> Mobile: +32 475 77 36 73
> catherine.lefe...@intl.att.com
>  
> TEXTING and DRIVING… It Can Wait
> AT
> BUROGEST OFFICE PARK SA
> Avenue des Dessus-de-Lives, 2
> 5101 Loyers (Namur)
> Belgium
>  
>  
> NOTE: This email (or its attachments) contains information belonging to the 
> sender, which may be confidential. proprietary and/or legally privileged. The 
> information is intended only for the use of the individual(s) or entity(ies) 
> named above. If you are not the intended recipient, you are hereby notified 
> that any disclosure, distribution or taking of any action in reliance on the 
> content of this is strictly forbidden. If you have received this e-mail in 
> error please immediately notify the sender identified above
>  
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=3qNBXK1AEoL6zxuaVrLo3UBFVSNq0OaszyDvfaLoUQE=vK70kqm-zpxVa5UZRJs-RxEUPokb6jDG4kR-XCz9hGY=

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

[onap-tsc] ONAP User Group

2017-07-18 Thread SPATSCHECK, OLIVER (OLIVER)


I think ONAP should have an ONAP User Group. The goal of this group would be to 
foster the use of ONAP rather then handle the development of ONAP which we have 
been so focused on.  I think if we intermingle the two to much we are just 
slowing things down. Now I don’t know what form this should take on. It could 
be a subcommittee, something else or handled outside the LF entirely as it has 
no code impact. To define the scope a bit clearer I added a a mock up welcome 
page below.

Any thoughts/suggestions on the topic?

Thx

Oliver




Welcome to the ONAP User Community page. This is the place where you can:

- exchange information on how to use ONAP
- post ONAP use cases you might have created (documentation, source code, 
configuration or whatever else you might want to share)
- find others which might want to work with you in prototyping an ONAP use case
- keep the community updated on what you are trying out


Note: It is OK to post links to propietery use cases here.

The goal of this community  is to foster collaboration but also to collect as 
much information as possible on how ONAP is being used with as little 
constrains/overhead as possible (no approval required you work with whom you 
want to work doing what you want).

The user community meets once a week to discuss issues and ideas from the user 
community and might organize work shops colocated with other events 
occasionally.

This is not the place where you define use cases which drive new features into 
the platform or any other platform development questions. To define use cases 
which drive new features into the platform please go through the process 
defined in the ONAP use case sub committee.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Committers and voting - Please read.

2017-06-30 Thread SPATSCHECK, OLIVER (OLIVER)

+1


On Jun 30, 2017, at 11:41 AM, Andrew Grimberg 
> wrote:

To help weed things down I would suggest that every repository in a
project be required to define a distinct list of committers and not
allow an umbrella project to define top level committers. That list may
be the same across several of them, but they should be distinct to each
repository and hold to the same configuration of just a few committers
per repository. It may mean a bit more administrative overhead for the
management, and definitely for the set-up but it will clearly define who
does, and does not have domain knowledge on a particular set of code.


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

Re: [onap-tsc] Committers and voting - Please read.

2017-06-30 Thread SPATSCHECK, OLIVER (OLIVER)

Mazin,

your email triggered me to actually go through the wiki and get some stats. I
attached a spreadsheet with committers per company and project (I did this
manually so there might be some minor mistakes but the trend holds). Also the
companies are sorted by appearance so the order is random.

Seems the TSC has failed miserably enforcing it’s own policies.

The average number of committers is 8.6. The max is 26 the min is 1. Based on
the 27 approved projects on the wiki 15 are not in compliance of the policy.
There are 10 projects with more then 10 committers.

Looking at some of the trends it seems to be a self feeding process one company
adds more then the others don’t want to be “left out” and respond in kind. So
it’s more driven by ego/politics then merit in most cases I can see.

I think the TSC needs to either step up and enforce it’s own rules or abandon
the rule altogether. The current status quo punish people which play by the
rules which I would think is not the intend of the TSC.

I would be interested to hear how the open source “gurus” have handled this in
the past as I suspect this has happened before in other projects.

Oliver

On Jun 29, 2017, at 9:35 PM, GILBERT, MAZIN E (MAZIN E)
> wrote:

*** Security Advisory: This Message Originated Outside of AT ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

ONAP Community,

I have sent a note on this before, so my apology for sending it again.
It is important that this community follow the guidelines of the TSC on
committers and PTLs. We have provided guidelines that projects should
have between 3-5 committers that have actual development experience
and deep knowledge in the software or release software. While I love
the passion and involvement of the community, I see few projects that
misused those directions and ended up with committers in excess of 10, some
signed up the last minute to steer the PTL vote.

I hesitated to manage and clean-up the committers per advice from
the Linux Foundation, but I will ask the TSC to enforce those guidelines
in future to ensure fair outcomes across all projects.

Thank you.. I will soon share some great news of new exciting members who
are joining ONAP. Thank you again for your hard work to making ONAP
a success and let’s make the Amsterdam Release a blast.

Mazin

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=rUHhj9ph_CQ3Np2G-F9zUffASbFXC8e__XGg_VFgjtE=AOatY2_khrWMjoCancKkJNqTK5U3Z5woGJ-3-uMx4jY=

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

Re: [onap-tsc] Agenda for tomorrow (Friday) TSC meeting?

2017-06-22 Thread SPATSCHECK, OLIVER (OLIVER)


Can we put the optimization framework back on the agenda too? I think we have 
addressed Stephen's and Chris’s concerns and I am not aware of any other.

Thx

Oliver

On Jun 22, 2017, at 7:48 PM, Phil Robb 
> wrote:

The Agenda has been updated.

Best,

Phil.

On Thu, Jun 22, 2017 at 4:58 PM, Jason Hunt 
> wrote:

Hi,

Can we get an updated agenda of project reviews for tomorrow's TSC meeting?  I 
need to brief my delegate.

Thank you!


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt


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




--
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=1V52W_rD7UxEIOlzLt65ifw2TqZWSwMjtUoydIYN4U4=uf5667Zru1tUjaum6ybmsCs333UAebBr1VPnMbT_-cs=

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

Re: [onap-tsc] Optimization framework

2017-06-22 Thread SPATSCHECK, OLIVER (OLIVER)


I would say something like:

“ It offers a set of MS which provide reusable optimization functionality which 
can optionally be used by other ECOMP components if required by a use case.” 

I like MS better then SDK but I think we agree.

Can certainly change to may.

Thx

Oliver

> On Jun 22, 2017, at 3:35 PM  EDT, Christopher Donley (Chris) 
> <christopher.don...@huawei.com> wrote:
> 
> Oliver,
>  
> Just to clarify the governance question: is this project producing a set of 
> services or an SDK that other projects can choose to implement or is it 
> producing artifacts that they must implement?  
>  
> From your example, I read it as the former (that projects can choose whether 
> or not to utilize oof), rather than a mandate.  If so, I’d recommend updating 
> the proposal (particularly the architecture alignment section) to change 
> “[may|will] need to….” language to “may ….” to clarify that point.
>  
> Also (since it will come up tomorrow), please adjust the committer list. 
> Everyone on the project is currently listed as a committer.
>  
> Chris
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER 
> (OLIVER)
> Sent: Thursday, June 22, 2017 10:31 AM
> To: Stephen Terrill
> Cc: PUTHENPURA, SARAT (SARAT); onap-tsc
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
>  is aligned with the architecture.
>  
> Now if I interpret your second question correctly you are also asking “How 
> does it help?” .
>  
> The reason we want to combine all of this in one project is that there is 
> reusability in the code required in steps 1.-5.
>  
> For example:
>  
> 1. + 2. requires code to gather information from many existing ONAP 
> components and present them in a common format so they can be used to derive 
> the optimization formulation.
>  
> 3. + 4. as we do not believe that there is one formulation/optimizer which 
> solvers every problem we do believe that the same formulation approach 
> combined with a set of optimizers and constraints can cover a large set of 
> diverse use cases leading to reuse in this area too.
>  
>  So the benefit of the project as the library of 
> formulations/optimizers/runtime framework grows will be that instead of 
> writing code

Re: [onap-tsc] Optimization framework

2017-06-22 Thread SPATSCHECK, OLIVER (OLIVER)

I think you are highlighting this:

> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  

that survived.

Oliver


> On Jun 22, 2017, at 3:28 PM  EDT, ROSE, DANIEL V <dr6...@att.com> wrote:
> 
> The original design I saw had the SNIRO framework (att internal name for 
> this) as being a few microservices deployed via OOM. OOM would then place 
> them near other components based on needs (Ie if dcae needs a certain 
> optimization service, instances of it would be deployed closer to the edge 
> dace relies on. If it is something SO needs, it would be deployed closer to 
> the core but that placement logic was all in oom. Not sure if that logic 
> survives to the current proposal.
>  
> Thanks,
>  
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill
> Sent: Thursday, June 22, 2017 3:22 PM
> To: SPATSCHECK, OLIVER <spat...@research.att.com>
> Cc: PUTHENPURA, SARAT <sa...@research.att.com>; onap-tsc 
> <onap-tsc@lists.onap.org>
> Subject: Re: [onap-tsc] Optimization framework
>  
> Hi Oliver,
>  
> Thanks for the clarifications – I do understand better now and as a result I 
> am fine with this.
>  
> Two questions/comments though:
> -  I assume it could even be called by the controllers if this was 
> relivant (e.g. the VF-C, OOM).
>  
> Perhaps in the description at the start just after where it says the project 
> would provide 2 new services a) HAS and b) CMSO, you could put:
> These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
> the service design framework.
> The HAS and CMSO modules will execute both as services on DCAE and 
> independent processes.
> --
>  
> BR,
>  
> Steve
>  
> From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
> Sent: 22 June 2017 19:31
> To: Stephen Terrill <stephen.terr...@ericsson.com>
> Cc: onap-tsc <onap-tsc@lists.onap.org>; PUTHENPURA, SARAT (SARAT) 
> <sa...@research.att.com>
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
&

Re: [onap-tsc] Optimization framework

2017-06-22 Thread SPATSCHECK, OLIVER (OLIVER)


> On Jun 22, 2017, at 3:22 PM  EDT, Stephen Terrill 
> <stephen.terr...@ericsson.com> wrote:
> 
> Hi Oliver,
>  
> Thanks for the clarifications – I do understand better now and as a result I 
> am fine with this.
>  
> Two questions/comments though:
>   • I assume it could even be called by the controllers if this was 
> relivant (e.g. the VF-C, OOM).
>  

Certainly. Any ECOMP component could call this.

Thx

Oliver

> Perhaps in the description at the start just after where it says the project 
> would provide 2 new services a) HAS and b) CMSO, you could put:
> These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
> the service design framework.
> The HAS and CMSO modules will execute both as services on DCAE and 
> independent processes.
> --
>  
> BR,
>  
> Steve
>  
> From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
> Sent: 22 June 2017 19:31
> To: Stephen Terrill <stephen.terr...@ericsson.com>
> Cc: onap-tsc <onap-tsc@lists.onap.org>; PUTHENPURA, SARAT (SARAT) 
> <sa...@research.att.com>
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
>  is aligned with the architecture.
>  
> Now if I interpret your second question correctly you are also asking “How 
> does it help?” .
>  
> The reason we want to combine all of this in one project is that there is 
> reusability in the code required in steps 1.-5.
>  
> For example:
>  
> 1. + 2. requires code to gather information from many existing ONAP 
> components and present them in a common format so they can be used to derive 
> the optimization formulation.
>  
> 3. + 4. as we do not believe that there is one formulation/optimizer which 
> solvers every problem we do believe that the same formulation approach 
> combined with a set of optimizers and constraints can cover a large set of 
> diverse use cases leading to reuse in this area too.
>  
>  So the benefit of the project as the library of 
> formulations/optimizers/runtime framework grows will be that instead of 
> writing code for new optimization challenges they can be just configured or 
> at least will require minimal code development.
>  
> Does that address your concerns?
>  
> Please advice how you want to document this? E.g.

Re: [onap-tsc] Face to Face meeting agreements

2017-06-13 Thread SPATSCHECK, OLIVER (OLIVER)


One more question. Did the toy use case (vDNS/vFirewall) we want to use for 
automated testing ever get formally approved. I know we briefly discussed it 
and everybody was nodding but to be honest I don’t recall if we actually voted 
on it. If we didn’t can we close on this Thu too?

Thx

Oliver

> On Jun 13, 2017, at 11:50 AM  EDT, Kenny Paul <kp...@linuxfoundation.org> 
> wrote:
> 
> Sorry, That is what I thought from over the phone.
> 
> Best Regards, 
> -kenny
> 
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org
> 510.766.5945
> 
>> On Jun 12, 2017, at 1:35 PM, SPATSCHECK, OLIVER (OLIVER) 
>> <spat...@research.att.com> wrote:
>> 
>> 
>>> On Jun 12, 2017, at 4:31 PM, Kenny Paul <kp...@linuxfoundation.org> wrote:
>>> 
>>> All of the use cases were approved.
>>> 
>> 
>> That’s not correct. The toy use case and the vEPC/voLTE use case were 
>> approved. The vCPE use case is still being worked with the deadline for all 
>> use cases being the TSC meeting this Thu.
>> 
>> Oliver
> 

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

Re: [onap-tsc] Forward:Re: Comments about Holmes

2017-06-13 Thread SPATSCHECK, OLIVER (OLIVER)


Yuan,

just to be clear we did agree to integrate Holmes into DCAE in release 1.0:  
"DCAE supports Holmes to be deployed as an analytic application in the form of 
docker(s)."

As for which use case is using which configuration this will have to be decided 
as part of the release planing I presume.

Thx

Oliver

> On Jun 13, 2017, at 10:29 AM  EDT, yuan@zte.com.cn wrote:
> 
> Hi Mazin,
> 
> 
> 
> I believe the Holmes team have deelply discussed with DCAE team off line and 
> in line during Beijing F2F meeting. Holmes team totally understood DCAE team 
> is proposing DCAE framework with perfect architecture and will be implemented 
> step by step. In release 1, Holmes will work independently to support close 
> loop for voLTE use case and Holmes team will keep in touch with DCAE team for 
> future integration. Keeping aligment in interface level but decouple the 
> components with each other would be better for open source practice. Let end 
> users make decision how they would like to integrating different components 
> in different scenarios.  
> 
> 
> 
> Regards,
> 
> Yuan Yue
> 
> 
> 
> 
> 
> 
> 
> 袁越 yuanyue
> 
> 资深战略规划师   Senior Strategy Planner
> 
> 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
> Product
> 
> 
> 
> 
> <9ae3e214c17d49ed935d87c674ba3ee2.jpg>
> <24242e5637af428891c4db731e7765ad.jpg>
> 南京市雨花区软件大道50号中兴通讯3号楼
> 1/F,Building 3, ZTE Nanjing R Center II, No.50, Software Avenue,YuHua 
> District,Nanjing,P.R.China 210012
> T: +025 88013478 
> M: +86 13851446442 
> E: yuan@zte.com.cn 
> www.zte.com.cn
> 原始邮件
> 发件人： ;
> 收件人：付光荣10144542;
> 抄送人： ; ;
> 日 期 ：2017年06月13日 04:45
> 主 题 ：Re: [onap-tsc] Forward:Re:  Comments about Holmes
> 
> 
> Ok. It would have been beneficial to have a deeper dive with the DCAE team 
> and the architecture team so you understand the flow and architecture.
> My view is not to allow this to run independently. They are serious efforts 
> in terms of life cycle management, resource management, 
> reliability, etc that one needs to support for each of these components, and 
> we can not repeat that work for each analytics service
> provided by each contributor. 
> 
> Hence DCAE tries to bring it all together and enable on boarding of different 
> types of Microservices.
> 
> 
>> On Jun 11, 2017, at 11:18 PM, fu.guangr...@zte.com.cn wrote:
>> 
>> Hi Mazin,
>> 
>> We have discussed with Oliver and are now aware of that DCAE is an open 
>> platform that allows independent/external systems to be integrated with it. 
>> Based on this and to make Holmes more flexible, we proposed Holmes to be set 
>> up as a standalone project.
>> 
>> Being a standalone project does not mean that Holmes will not support DCAE. 
>> Holmes will expose DMaaP related APIs to the public and be released in the 
>> form of docker(s) so that it can be integrated with DCAE. Meanwhile, as an 
>> independent system,  Holmes can also be run in standalone mode, which 
>> enables it to be connected or utilized by other systems in ONAP directly.
>> 
>> Regards,
>> 
>> Guangrong
>> 
>> 
>> 
>> 
> 
>  
> 
> 
> 发件人：zhaohuabing10201488
> 收件人：fuguangrong10144542;
> 抄送人：mengzhaoxing10024238;wangrui10208678;
> 日 期 ：2017/06/12 09:05
> 主 题 ：Forward：Re: [onap-tsc] Comments about Holmes
> 
> From:  GILBERT,MAZINE(MAZINE);
> To:roberto.k...@orange.com; fuguangrong10144542;
> Cc:t...@lists.onap.org;
> Date:  2017-06-11 06:08:46
> Subject:Re: [onap-tsc] Comments about Holmes
> 
>  
> Guangdong
> 
>  
> I realize the TSC arrived at a middle ground during the F2F meeting of having 
> Holmes as a separate project. I have tried to share my views on this 
> previously and it seems to have failed. DCAE is a framework for on operating  
> big data Microservices. Holmes is an analytics Microservice, that is policy 
> driven. The policies are set through Drools by the Policy engine, while the 
> analytics is done by DCAE. DCAE and Policy have well defined protocols to 
> help operate control loops. This  design was done so that developers can 
> build, test and deploy their own Microservices (correlations, predictions,, 
> normalization, compressions, analytics, etc) without having to establish yet 
> another independent component in ONAP.  There are numerous large-scale  
> correlation engines adopted by many operators and vendors today. Holmes is 
> one example. This flexibility in the design in ONAP. allows companies to plug 
> and play their Microservices function without additional dependencies or 
> software development. This approach  is successful and how it is employed in 
> AT 
> 
>  
>  
> I strongly suggest you spend sometime to better understand how DCAE and 
> open/close loops work in ONAP. It is very important that we enable 
> disaggregation and flexibility so that developers can innovative quickly. I 
> will  rely heavily on the architecture subcommittee to

Re: [onap-tsc] Tentative July ONAP Developers Face-to-Face Meeting

2017-06-12 Thread SPATSCHECK, OLIVER (OLIVER)

That’s not how I took the poll. I thought the question was “if it was decided 
that there was a meeting these would be possible days that work”.

I am wondering if we could make this a regional/virtual meeting. E.g. AT and 
a good number of the other ONAP members have quite elaborate teleconferencing 
rooms in multiple cities. I am wondering if we could meet locally and just use 
those teleconferencing rooms. In my experience this is pretty close to a real 
meeting (much much better then a zoom video meeting if you never have used one 
of those rooms …).

Just a thought.

Considering the tight schedule of the ONAP release I am pretty sure that a 
large fraction of the AT developers would not be able to make a F2F meeting 
in July. So the question in my mind is:  Is it more valuable to have a F2F 
meeting with only a fraction of the key developers present or a virtual meeting 
with everybody?

Oliver

On Jun 12, 2017, at 4:05 PM, Stephen Terrill 
> wrote:

Hi Paul, All,

One part of this poll that we were seeking feedback on was whether the 
developers in the project felt that it was of value to have a meeting in July 
for coordination other project etc – should the interpretation be that those 
who do not feel there is value answer “no” to all dates, and the ones that do 
select the dates that they can attend?

BR,

Steve

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kenny Paul
Sent: 12 June 2017 19:09
To: onap-disc...@lists.onap.org; onap-tsc 
>
Subject: [onap-tsc] Tentative July ONAP Developers Face-to-Face Meeting

Please respond to the doodle poll below no later than:
Thurs. 01:00 PM UTC
Thurs. 09:00 PM China
Thurs: 09:00 AM Eastern
Thurs: 06:00 AM Pacific

https://doodle.com/poll/7zufivqebtnvrhdt

Thank You.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=k6RRZKHW06SCuVKo287vNy6OnTesVvhtAExqgjZ2Jlw=LbYCxJRJjFJ2XOcJG6YgFS5oC7-ee113Exd1q1XY86s=

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

Re: [onap-tsc] Face to Face meeting agreements

2017-06-12 Thread SPATSCHECK, OLIVER (OLIVER)


On Jun 12, 2017, at 4:31 PM, Kenny Paul 
> wrote:

All of the use cases were approved.


That’s not correct. The toy use case and the vEPC/voLTE use case were approved. 
The vCPE use case is still being worked with the deadline for all use cases 
being the TSC meeting this Thu.

Oliver
___
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

2017-06-12 Thread 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 
> <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

[onap-tsc] Network Function Change Management Project Proposal

2017-06-08 Thread 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

Re: [onap-tsc] Call for vCPE VNFs proposals

2017-06-01 Thread SPATSCHECK, OLIVER (OLIVER)

Could we also start listing who is supporting the open source VNFs? E.g. even 
the simple open source based VNFs we are using for the current ONAP demo  based 
on the seed code took a couple of people 2 months or so to get to work properly 
in the integration environment. I would assume that for commercial VNFs this 
support will be provided by the vendor. However, for open source VNFs we need 
volunteers to take on that role. I would track those on the Wiki or identify 
them as gaps. If we can’t find that support we can’t use that VNF.

Thx

Oliver

On May 31, 2017, at 11:36 PM, Zhou, Danny 
> wrote:

The wiki 
page
 already lists preferred and usable open source VNFs like below, but the ONOS 
vBNG as open source vBNG and OpenWRT as open source vHGW does not make sense to 
me. Specifically, the ONOS vBNG is essentially a L3 NAT without the 
capabilities to address requirement such as session management, traffic 
aggregation and routing, etc., and in addition to OpenWRT acting as vHGW, VPP 
based high performance Home 
Gateway
 as well 
asvRouter
 should be better.

  *   vDHCP: ISC DHCP
  *   vDNS:   ISC Bind
  *   vAAA:   FreeRADIUS

-Danny Zhou
Intel

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
Sent: Thursday, June 1, 2017 3:36 AM
To: KLUGER, YOAV >; 
onap-tsc@lists.onap.org; onap-discuss 
>
Subject: Re: [onap-tsc] Call for vCPE VNFs proposals

I recommend that any available open source implementations of these VNFs also 
be included. I am aware of several potential VNFs as used in the R-CORD 
project, and as being collected through the similar ODL VCO (Virtualized 
Central Office) project. These are being collected and assessed for deployment 
on OPNFV reference platforms as part of the proposed “Edge” project: 
https://wiki.opnfv.org/display/PROJ/Multi-Access+Edge
 intended to expand reference VNF options for edge-focused service deployments 
such as residential broadband. As a part of this project we will also be 
building reference blueprints (TOSCA based) for these VNFs and orchestrating 
them using ONAP components as well as other projects we are currently using for 
this in OPNFV (Cloudify, and OpenStack Tacker).

OPNFV is acquiring the necessary hardware (e.g. OLT devices) to have a 
fully-functional edge-focused lab environment in which to complete this 
integration. I’ll add the related info to the ONAP wiki as the usability of the 
open source VNFs becomes clear.

Thanks,
Bryan Sullivan | AT

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of KLUGER, YOAV
Sent: Wednesday, May 31, 2017 12:23 PM
To: onap-tsc@lists.onap.org; onap-discuss 
>
Subject: [onap-discuss] Call for vCPE VNFs proposals

Dear ONAP community,

As we all know, the Residential Broadband vCPE use case is one of our two 
targeted use cases for R1.
Its wiki 
page
 has been significantly enriched recently, and more details are added on a 
daily basis.
A general residential broadband solution can be much more complex than what 
would be reasonably achievable by R1. We have narrowed down the description of 
the use case for R1, to something that should be both achievable and usable.
For the use case to

Re: [onap-tsc] wiki and conference calls

2017-05-26 Thread SPATSCHECK, OLIVER (OLIVER)


Yes and we should keep that organized. If we post them on random wiki pages 
nobody will find them… .

Seems Casey has a plan.

Casey,

do you think you can put a concrete proposal out with a process on how people 
can get there meetings/notes/recordings listed and organized?

Thx

Oliver

On May 26, 2017, at 11:58 AM, Danny Lin 
<l...@vmware.com<mailto:l...@vmware.com>> wrote:

+1

In our Multi-Cloud project, we have discussed the similar issue, in a slightly 
different context. We typically record all meetings, and also have a meeting 
note. We are wondering if we should post these recording and meeting notes, and 
if so, where?

Danny

From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Ed Warnicke <hagb...@gmail.com<mailto:hagb...@gmail.com>>
Date: Friday, May 26, 2017 at 8:35 AM
To: "SPATSCHECK, OLIVER (OLIVER)" 
<spat...@research.att.com<mailto:spat...@research.att.com>>
Cc: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] wiki and conference calls

+1k

I would strongly suggest we adopt the community norm that its totally cool for 
teams to start calls/IRC channels but they *really* need to list them in a 
central index so people can find them.  Aggressive Openness :)

Ed

On Fri, May 26, 2017 at 8:03 AM, SPATSCHECK, OLIVER (OLIVER) 
<spat...@research.att.com<mailto:spat...@research.att.com>> wrote:

I noticed that a substantial number of teams are starting either ad hoc or 
weekly conference calls.  As I think it’s great that the community is forming I 
am wondering if we can start tracking those calls on the ONAP wiki page  (can 
we add a calendar or something like that?).

This would make it much easier to stay on top of attending the correct meetings 
… .

Thx

Oliver
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org<mailto:ONAP-TSC@lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3nVF4lkCrih5WqBdByLDuw=WWQywOe8bMgd3AP-qfR_OADQrRfgqCtyrhmqUIh9eY8=IUBkkzFuSoaLnnzuYQFCopAEe5a9WG-QNSqKaWJwieE=>


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

Re: [onap-tsc] Thoughts on next steps.

2017-05-17 Thread SPATSCHECK, OLIVER (OLIVER)

Yuan,

let me separate things a bit.

The way I look at it is that there is a set of use cases which gate the success 
of the release. Those use cases have a set of VNFs.  

I completely agree with you that ONAP should support many commercial VNFs. In 
fact I would like all commercial VNFs to be supported by ONAP that’s the 
ultimate goal of AT, however, that does not mean that all of them have to be 
part of the set of VNFs used for the use case which gates the release. 

Now let’s focus on the VNFs which gate the release as the others can be worked 
using proprietary or bilateral agreements.  As stated below I don’t know how to 
do that efficiently. That doesn’t mean there isn’t a solution. So if you can 
outline one that would be great. I see three main challenges:

1. Developer access to VNFs. From experience you can speed up development 
substantially if you give developers access to an integration environment. It’s 
nice to develop against specs but I have never seen a complex project  (inside 
or outside of AT) which just worked based on developers working against 
specs. That’s where the whole agile idea comes from. Integration testing 
becomes an integral part of your development. So one way of fixing this is to 
give access to an IST level environment to the developers. That’s the approach 
we took with open sourcing ECOMP. Without that our demo use case would probably 
still not be working. So now if we use a commercial VNF how do we get 
developers these environments? E.g. AT has multiple development teams and we 
dynamically provided them what they needed on Rackspace to open source ECOMP. 
There are two solutions to this in my mind:

a.) We have a shared lab where all developers perform all the IST testing. If 
we want to follow this approach we have to answer the following questions:

Considering the substantially larger scale then Open-O do we have  a lab that 
can support ALL developers by 6/29? Who would provide that?  Does the shared 
lab really have enough instances to not slow development down?
Does that lab have a license which would allow them to give first hand access 
to e.g. an Ericsson (sorry just picked somebody randomly for illustrative 
purposes) developer to a Huawei or ZTE VNF?
Would e.g. Ericsson allow there developers to access that VNF or would they be 
afraid of IP entanglement if they did?
Do we have to worry about any international export control or anti trust laws 
doing this?

Again all those questions need to be answered by 6/29 to make this work for the 
first release and I have seen little discussion on this so far. 

b.) Each organization developing provides it’s own integrated testing 
environment to it’s developers. That would mean e.g. AT needs to run all 
those VNFs in it’s own internal lab. Of course AT wouldn’t pay for that after 
all we are providing free code to the community so we wouldn’t pay license fees 
to a vendor to do so.

In this case are the VNF vendors willing to license there VNFs to ALL ONAP 
contributors for free in support of ONAP development? 
Are those license agreements reasonable enough (e.g. limited indemnification if 
software gets stolen) for the ONAP development teams to actually sign?
Can all of this be completed by 6/29?

2. Another problem is around final acceptance testing of the release. I am a 
strong believer that if others can’t repeat something it doesn’t really exists. 
E.g. in physics a phenomena is only true if more then one DIVERSE team was able 
to observe it. I strongly believe software testing needs to follow the same 
objective.  So how would we set up repeatable testing of commercial VNFs which 
can be performed by more then one diverse team? The possible approaches are 
similar then the once outlined above. 

3. The last one is around demos. E.g. one things which I think has been fairly 
well received (based on the feedback I got) is the fact that you can try the 
ECOMP part of ONAP on Rackspace EASILY. I know we are still working on the 
generic open stack setup but the fact that so many people are asking for it is 
an indication that people want to “kick the tiers” of ONAP in there own 
environment. Again how would we address this need with proprietary VNFs?  
Without delivering VNFs with the use case ONAP is just a huge amount of code 
doing nothing …. . Or to put it differently. A wise man told me once: “ People 
don’t want platforms they want solutions!” if we can’t demo a solution as part 
of the release openly people will be very disappointed.

Again I don’t see a practical way of addressing this in the time given (e.g. I 
know for example that even a free license agreement with AT generally 
requires negotiations in the risk and IP area). If you know one could you 
please outline it so the community can understand what the plan is in detail?

Thx

Oliver

> On May 17, 2017, at 3:27 AM  EDT, yuan@zte.com.cn wrote:
> 
> Hi Oliver and all,
> 
> 
> 
> My answer to " I wouldn’t even know how that worked

Re: [onap-tsc] Proposal: Architecture Subcommittee

2017-05-12 Thread SPATSCHECK, OLIVER (OLIVER)

Don’t get my comment wrong I am in full support of an architecture 
subcommittee. I am somewhat worried on scope and process though.

If the architecture team can put release gating requirements on the project as 
outlined below (maybe I didn’t understand that correctly …) what is the process 
to ensure that they are realistic in the next release (enough resources 
available in the project) and align with the priorities of the volunteers in 
the projects which do the  work.  If they don’t they won’t get implemented and 
we don’t have a release.

I thought release features are worked by the projects.

It always worries me if you separate the decision process from the resources as 
without resources even the best decision has no value.

Oliver

On May 12, 2017, at 2:01 AM, 
aayush.bhatna...@ril.com wrote:

+1 for the subcommittee formation.

Additional proposal on the deliverables of the architectural subcommittee -

- Create the deployment architecture for ONAP especially for multi-DC VNF 
orchestration. This aspect is important as ONAP components such as the DCAE 
follow an edge-lake architecture which becomes relevant only when we visualize 
a multi-site deployment.

- Define the architectural principles of disaster recovery (DR) orchestrated by 
the MSO and Policy Engine for VNFs.

Regards

Aayush

From: onap-tsc-boun...@lists.onap.org 
> on 
behalf of Alla Goldner >
Sent: Friday, May 12, 2017 10:29 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman >; Christopher 
Donley (Chris) 
>; onap-tsc 
>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman >; 
onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman

Re: [onap-tsc] CI/CD

2017-05-11 Thread SPATSCHECK, OLIVER (OLIVER)


Yes that would be in scope of the integration project.

Oliver

On May 11, 2017, at 4:46 PM, Stephen Terrill 
> wrote:

Hi All,

I’ve become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information 
here:https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]

STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=BiE0UeMVWL5BFRE96kIMByH1XejOpwHbW3SIxLd5Cq8=HRf6t_SB0Ec1Y5h2_JGwQWflOuJIVBmcBS66AEBNhxk=

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

Re: [onap-tsc] Seed code for Service Orchestrator

2017-05-11 Thread SPATSCHECK, OLIVER (OLIVER)


So am I.  I thought in the charter we had agreed that the MSO code base would 
be used for this. Similar to the 3 legacy Open-O components.

Was there any discussion on this anywhere?

Thx

Oliver

> On May 11, 2017, at 3:48 PM  EDT, eric.deb...@orange.com wrote:
> 
> Hello
>  
> I am surprised to discover that open-o/gso is considered as the seed code for 
> the Service Orchestrator.
>  
> As far as I know, we never decided such choice during the discussions last 
> week and it should be a TSC decision.
>  
> Regards
>  
> Eric
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=yopWEEan7upXoI1z2e3hU3o52mzgW69H-rB7ZIT8-A8=r3tAPP-TO6TFW9dliuNeUQRkuweOwDof8ZXXYNxy8nw=

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

Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers

2017-05-10 Thread SPATSCHECK, OLIVER (OLIVER)


I guess where I was getting confused is who is managing the micro services 
themselves. E.g. DCAE uses micro services. The micro services in DCAE are 
managed by the DCAE controller in terms of life cycle management (turning up 
the micro services, monitoring the health of the micro service, turning down 
the micro service). In this case the DCAE controller also partially handles 
service discovery. My understanding was that the OOM will handle those tasks 
going forward in a unified way.

So let me see if I am getting this straight now.  Is the following statement 
true?

If I have a micro service within ONAP the OOM manages:

- turn up
- faults
- turn down
- auto scaling

the micro service framework manages

- service registration
- service discovery
- service load balaning

Do both teams agree to this separation?

If that is the case I agree that they are separate tasks and that the term 
micro service framework is very misleading as I would have thought a framework 
also handled turn up, faults, turn down and auto scaling.  Maybe we should go 
back to micro service bus then.

Those projects are obviously still closely related though. E.g. if you turn up 
a micro service (as the OOM would do) you have to let the micro service bus 
know about it (e.g. register it).

Helen,

I am not sure I understand the difference between a component of ONAP and a 
tool. For the OOM to manage the above life cycle events of micro services and 
other components in ONAP it has to be running at the same operational level as 
any other ONAP component does.  So it’s not just a “script” you run once. It’s 
a component.   It just doesn’t directly interact with VNFs but that doesn’t 
make it less important.

Thx

Oliver


On May 10, 2017, at 8:55 PM, 
zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn> wrote:


What Helen said is correct.


During the project proposal discussion in the last week, people suggest use 
"Microservice Framework " instead of "Microservice Bus", that might be the 
reason of this confusion.

"Microservice Framework" or "Microservice Bus" provides a platform to enable 
service registration/discovery, service request routing, service load balancing 
for the services.


From the project description of OOM(ONAP Operations Manager), OOM intends to 
Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, 
SDC, etc.) and infrastructure (VMs, Containers).


So the scopes of these two project obviously have no any overlapping.


Thanks,

Huabing

Original Mail
Sender:  ＜helen.c...@huawei.com<mailto:helen.c...@huawei.com>＞;
To:  ＜spat...@research.att.com<mailto:spat...@research.att.com>＞; 
＜david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>＞;
CC:  ＜onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>＞;
Date: 2017/05/11 07:21
Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP 
onContainers


As I understand correctly:
First of all, from its functionality, Microservices Framework focus on helping 
project which uses microservices to easier manage their services, including 
register/discover, etc. through its services bus; it is the content, and where 
it will be installed, is out of its scope. And OOM focus on where it will be 
installed, (from theory, it could be packed in a VM or a container), but OOM 
chose docker.

Secondly from its distribution, Microservices Framework is part of ONAP itself; 
while OOM will be distributed as tools for ONAP, just as some tools which will 
be distributed from Integration project.

Regards,

Helen Chen

On 5/10/17, 1:23 PM, "SPATSCHECK, OLIVER  (OLIVER)" 
＜spat...@research.att.com<mailto:spat...@research.att.com>＞ wrote:


One more question. I am wondering what the relationship of the Microservice 
Framework (https://wiki.onap.org/display/DW/Microservices+Framework) and below 
is.

Below says:

＞＞ The OOM addresses the current lack of consistent platform-wide method in 
managing software components, their health, resiliency and other lifecycle 
management functions.

the Microservice Framework proposal says:

＞＞Standardize ONAP platform Microservies concepts & principles and provide 
key framework

it seems the Microservice Framework is a subset of the the Operations 
Manager and container proposal in scope.

Am I interpreting this correctly?

Thx

Oliver

＞ On May 10, 2017, at 3:35 PM  EDT, Sauvageau, David 
＜david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>＞ wrote:
＞
＞ Oliver – I can move it there. Was not aware thanks
＞
＞ On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER  (OLIVER)" 
＜spat...@research.att.com<mailto:spat...@research.att.com>＞ wrote:
＞
＞
＞I would assume so otherwise we would have duplication.
＞
＞On an editorial note I thought we were supposed to move the proposal 
links above the project proposal draft line h

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

2017-05-10 Thread SPATSCHECK, OLIVER (OLIVER)


One more question. I am wondering what the relationship of the Microservice 
Framework (https://wiki.onap.org/display/DW/Microservices+Framework) and below 
is.  

Below says:

>> The OOM addresses the current lack of consistent platform-wide method in 
>> managing software components, their health, resiliency and other lifecycle 
>> management functions.

the Microservice Framework proposal says:

>>Standardize ONAP platform Microservies concepts & principles and provide key 
>>framework

it seems the Microservice Framework is a subset of the the Operations Manager 
and container proposal in scope.

Am I interpreting this correctly?

Thx

Oliver

> On May 10, 2017, at 3:35 PM  EDT, Sauvageau, David <david.sauvag...@bell.ca> 
> wrote:
> 
> Oliver – I can move it there. Was not aware thanks
> 
> On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER  (OLIVER)" 
> <spat...@research.att.com> wrote:
> 
> 
>I would assume so otherwise we would have duplication. 
> 
>On an editorial note I thought we were supposed to move the proposal links 
> above the project proposal draft line here:
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Proposing-2BA-2BProject=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=KRq5UXk7n766idl0S3NdoJnXVXF7vWo4f17PKdHET6o=
>  
> 
>when they are ready for the TSC review period.
> 
>Thx
> 
>Oliver
> 
>> On May 10, 2017, at 3:11 PM  EDT, Yunxia Chen <helen.c...@huawei.com> wrote:
>> 
>> Hi, David,
>> Could this manager be used for “Distribution” and “Packaging” of ONAP? 
>> Please refer to:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Integration=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=XtcCxrSC2x1iAS_-wkrcO7OCAMRT4JckuzoQHdrNC88=
>>  
>> 
>> Regards,
>> 
>> Helen Chen
>> 
>> From: <onap-tsc-boun...@lists.onap.org> on behalf of "Sauvageau, David" 
>> <david.sauvag...@bell.ca>
>> Date: Wednesday, May 10, 2017 at 11:30 AM
>> To: "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org>
>> Subject: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on 
>> Containers
>> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JKrpL9bPGtCjFYFOQv1RHpooQ1UEvvb5Sqbl3r_-TTY=
>>  
>> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D3247305=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JpUYmrsZsg6RjZKDiep2Pih0JSdBKmoI6wxVFzvDVWA=
>>  
>> 
>> 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 containeri

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

2017-05-09 Thread SPATSCHECK, OLIVER (OLIVER)


I would rather use scripts then CLI as Brian pointed out but on the other hand 
this project will hurt nobody as long as it’s built on top of the REST APIs. So 
in my mind this comes down to who wants to put resources on this. I guess what 
you are hearing is that some companies won’t … .

Oliver

> On May 9, 2017, at 12:36 PM  EDT, Haiby, Ranny (Nokia - US/San Jose USA) 
>  wrote:
> 
> Hi,
>  
> I was about to vote in favor of putting this to a rest then I realized we may 
> not be thinking the same thing when it comes to CLI.
>  
> If the CLI is a parallel interface to the REST API then it definitely makes 
> no sense to have one.
>  
> If, however, a CLI is a *wrapper* on top of the API, then based on past 
> experience it may serve us best to have one. Taking the OpenStack example, 
> the CLI provides a simplified way to perform actions, and when used by 
> scripting tools, makes such scripts simple and readable. Consider an action 
> such as creating a VM that boils down to:
> $ openstack server create --flavor FLAVOR_ID --image IMAGE_ID --key-name 
> KEY_NAME \
>   --user-data USER_DATA_FILE --security-group SEC_GROUP_NAME --property 
> KEY=VALUE \
>   INSTANCE_NAME
>  
> Where as building the curl command line that will do the same action can be 
> much more cumbersome and error prone.
>  
> I believe that if we don’t create a CLI wrapper, there will be multiple such 
> wrapper libraries created by many parties, and we will miss the benefit of 
> the community creating it once.
>  
> Ranny.
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam
> Sent: Tuesday, May 9, 2017 9:06 AM
> To: Ramkumar Venketaramani 
> Cc: t...@lists.onap.org
> Subject: Re: [onap-tsc] Project Proposal: ONAP CLI
>  
> Thank you all for providing the feedback.
>  
> Dear TSC team,
> Based on the comments received, I feel that community is not much interested 
> in it and does not feel as high priority project for this release. So I 
> think, we could park this project proposal in backlog and could re-visit in 
> later release, on need basis. 
>  
> But, Pls let me know if needs to be worked out for R1. Thanks.
>  
> Regards
> Kanagaraj M
>  
>  
>  
>  
>  
> On Tue, May 9, 2017 at 7:00 PM, Ramkumar Venketaramani 
>  wrote:
> I would recommend a REST based approach as well.
>  
> Regards,
>  
> Ram
>  
> From:  on behalf of Dhananjay Pavgi 
> 
> Date: Tuesday, May 9, 2017 at 5: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
>
> 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
>
> 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:
>   • ONAP Continuous integration (CI), where we want to perform various 
> ONAP operations, CLI will be very handy option. This is applicable to 3rd 
>

Re: [onap-tsc] [onap-discuss] Projects

2017-05-08 Thread SPATSCHECK, OLIVER (OLIVER)


As I am ready to start commenting on the various proposals I was wondering what 
mechanism we should use for that.  Should we just use the confluence comment 
feature?  If we do that we need to make sure that the primary contacts are 
responsive in editing the proposal/responding to the comments. What’s the 
protocol?

I know Mazin was pushing for having most proposals ready by Thu so there is 
little time left… .

Thoughts?

Oliver

> On May 8, 2017, at 8:47 AM  EDT, Ed Warnicke  wrote:
> 
> I am agnostic as to which way we resolve it, so long as they are indexed in 
> one place and it's obvious how to find it :)
> 
> Ed
> 
> On Mon, May 8, 2017 at 12:01 AM, Kanagaraj Manickam 
>  wrote:
> There is an another wiki  
> https://wiki.onap.org/display/DW/Project+Proposal+Kickoff where most of the 
> projects are proposed.
> 
> Should we bring them under the page listed here 
> https://wiki.onap.org/display/DW/Proposing+A+Project
> 
>  
> 
> 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 this e-mail in error, please notify the sender by 
> phone or email immediately and delete it!
> ***
> 
>  
> 
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Danny Lin
> Sent: Sunday, May 07, 2017 4:14 AM
> To: Ed Warnicke
> Cc: onap-disc...@lists.onap.org; onap-tsc
> Subject: Re: [onap-tsc] [onap-discuss] Projects
> 
>  
> 
> Good suggestion, Ed. I will list multi-VIM project there. Thanks.
> 
>  
> 
> Danny
> 
> 
> On May 6, 2017, at 3:41 PM, Ed Warnicke  wrote:
> 
> I have seen a bunch of proposal wiki pages for projects, but only see a small 
> number listed in the index for such proposals:
> 
> https://wiki.onap.org/display/DW/Proposing+A+Project
> 
>  
> 
> For the folks working on proposals, would you list them there?
> 
>  
> 
> It allows the others who might be interested to see that there is a project 
> proposal coming together and participate :)
> 
>  
> 
> Ed
> 
>  
> 
> On Sat, May 6, 2017 at 9:08 AM, GILBERT, MAZIN E (MAZIN E) 
>  wrote:
> 
> Team,
> 
> First, thank you for spending a week in NJ brainstorming, planning and 
> architecting our next 4Q17 release.
> Our next step is to have the smaller community teams flush out their project 
> proposals, fill in gaps, and communicate
> with other teams to consolidate proposals in the case of overlaps. Please 
> notify us if your proposal is ready to be
> reviewed for feedback. I expect the majority of proposals will be in that 
> stage before our Thursday TSC meeting
> on May 11th.
> 
> Have a wonderful weekend.
> mazin
> 
> 
> ___
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=3nVF4lkCrih5WqBdByLDuw=vlMAtln-nCY4wHPDZBk3vYGpkIUrdU-nEUWD5J4G7Oo=bjIf_nHjEJ9EvLfgMgrX9fIECr_GPPLraqE9rWQN8bA=
> 
> 
> ___
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=0RAg6WGUQczuY_PyZwWICxxhGGt7oGP1B_2NZmNihFc=L8gq8Zi-32C-rfQuRnKL9AOLrSsrKvcfkTkIkVcliLM=
>  

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

[onap-tsc] Updated TSC Charter

2017-04-24 Thread SPATSCHECK, OLIVER (OLIVER)

That sounds reasonable to me.

Oliver

On Apr 21, 2017, at 15:50, Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>> wrote:

That?s essentially the approach we used in OPEN-O, with the Release Manager 
handling the coordination ? if a project needed a new repo for a sub-project, 
etc., the team reached out to Gildas.  It worked fairly well. We could update 
the language in section 1 to allow plural repositories.  Beyond that, I suggest 
not over specifying the mechanism in the charter, and instead provide 
flexibility to the TSC to deal with issues as they arise.

Chris

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Friday, April 21, 2017 12:34 PM
To: SPATSCHECK, OLIVER (OLIVER)
Cc: Christopher Donley (Chris); Ed Warnicke; SULLIVAN, BRYAN L; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>
Subject: Re: [onap-tsc] Updated TSC Charter

Inline...

On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) mailto:spatsch at research.att.com>> wrote:

I think one option would be to stick with the project approval as outline but 
allow multiple repos in one project as decided by the project team.

Then we could have a repo coordinator who provides advice to the projects on 
repos and races issues (like this should really be two projects) to the TSC as 
they occur which allows the TSC to intervene (e.g. splitting the project).

This sounds like a good start :)  Though I would prefer the TSC ask hard 
questions as to whether a project has grown beyond its scope rather than 
'intervening' ;)

Ed


Similarly to your philosophy I believe into trusting the people which do the 
work and dealing with problems IF they happen rather then trying to design a 
process which is heavy handed trying to address anticipated issues which might 
rarely/never occur.

Oliver

> On Apr 21, 2017, at 1:47 PM  EDT, Ed Warnicke  gmail.com<mailto:hagbard at gmail.com>> wrote:
>
> Inline...
>
> On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER)  research.att.com<mailto:spatsch at research.att.com>> wrote:
>
> I guess you could argue that our current code base is not well formed but if 
> you look at Gerrit right now you see about 60+ repos for the couple of 
> components we have.
>
> LOL... I try not to argue that somebody elses work is not well formed till I 
> can understand a bit better both their constraints and reasoning ;)
> But when they do things that don't make immediate sense to me... I *do* get 
> curious and want to understand :)
> So about the worst you are going to get from me is that seeking to understand 
> and perhaps some "Have you thought of this" questions :)
>
>
> Let?s just start with A. A in my mind is one project. The scope of the 
> project is to provide a current inventory for ONAP.
>
> It consist of 5 repos.
>
> - AAI Chef cookbooks
> - AAI Chef environment files
> - AAI REST based services
> - AAI common logging library
> - Loads SDC Models into A
>
> now could we have thrown all of this into one repo? Sure we could have but I 
> think they are functionally separate enough that they shouldn?t be in the 
> same repo so they can be managed separately (e.g. versioning, patches, 
> releases etc?). Also not every ONAP user might use all of them (e.g. somebody 
> might not want to use chef and add an ansible repo)
>
> This is true pretty much for every component we have right now as you can see 
> in gerrit.
>
> Now I guess you could argue that we should file a sub project proposal for 
> each of those repos but I am not sure if e.g. creating two repos for  Check 
> cookbooks and Check environment files is really a decision which needs TSC 
> input. That could perfectly be handled by the project team. After all we are 
> trusting the project team to write the code so why not trust them with this?
>
> Honestly, my preferred mode of oversite in general is to provide information 
> that may be relavent and then defer to the guys doing the work.
> So please take my comments in that spirit ;)
>
> When I see repo proliferation a couple of things come to mind for me:
> 1)  Is that really part of one project with one set of committers?  Or is 
> that a new subcommunitee with a new set of committers (or likely to be).
> In my mind, its much easier in a multi-repo environment to miss the "Hey, 
> that's actually different committers involved and should probably be a new 
> project" mark.
> 2)  Repo splits have costs both way.  Multiple repos make it harder for folks 
> to check out all the code, but easier to grab just one corner of it.
> Multiple repos make builds more complex, but faster.
> e
>
> My past experience has been that TSCs are at their best when they ask 
> projects to *consider* questions, express that they have thought ab

[onap-tsc] Updated TSC Charter

2017-04-21 Thread SPATSCHECK, OLIVER (OLIVER)


I think one option would be to stick with the project approval as outline but 
allow multiple repos in one project as decided by the project team. 

Then we could have a repo coordinator who provides advice to the projects on 
repos and races issues (like this should really be two projects) to the TSC as 
they occur which allows the TSC to intervene (e.g. splitting the project). 

Similarly to your philosophy I believe into trusting the people which do the 
work and dealing with problems IF they happen rather then trying to design a 
process which is heavy handed trying to address anticipated issues which might 
rarely/never occur.

Oliver

> On Apr 21, 2017, at 1:47 PM  EDT, Ed Warnicke  wrote:
> 
> Inline...
> 
> On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER)  research.att.com> wrote:
> 
> I guess you could argue that our current code base is not well formed but if 
> you look at Gerrit right now you see about 60+ repos for the couple of 
> components we have.
> 
> LOL... I try not to argue that somebody elses work is not well formed till I 
> can understand a bit better both their constraints and reasoning ;)
> But when they do things that don't make immediate sense to me... I *do* get 
> curious and want to understand :)
> So about the worst you are going to get from me is that seeking to understand 
> and perhaps some "Have you thought of this" questions :)
>  
> 
> Let?s just start with A. A in my mind is one project. The scope of the 
> project is to provide a current inventory for ONAP.
> 
> It consist of 5 repos.
> 
> - AAI Chef cookbooks
> - AAI Chef environment files
> - AAI REST based services
> - AAI common logging library
> - Loads SDC Models into A
> 
> now could we have thrown all of this into one repo? Sure we could have but I 
> think they are functionally separate enough that they shouldn?t be in the 
> same repo so they can be managed separately (e.g. versioning, patches, 
> releases etc?). Also not every ONAP user might use all of them (e.g. somebody 
> might not want to use chef and add an ansible repo)
> 
> This is true pretty much for every component we have right now as you can see 
> in gerrit.
> 
> Now I guess you could argue that we should file a sub project proposal for 
> each of those repos but I am not sure if e.g. creating two repos for  Check 
> cookbooks and Check environment files is really a decision which needs TSC 
> input. That could perfectly be handled by the project team. After all we are 
> trusting the project team to write the code so why not trust them with this?
> 
> Honestly, my preferred mode of oversite in general is to provide information 
> that may be relavent and then defer to the guys doing the work.
> So please take my comments in that spirit ;)
> 
> When I see repo proliferation a couple of things come to mind for me:
> 1)  Is that really part of one project with one set of committers?  Or is 
> that a new subcommunitee with a new set of committers (or likely to be).
> In my mind, its much easier in a multi-repo environment to miss the "Hey, 
> that's actually different committers involved and should probably be a new 
> project" mark.
> 2)  Repo splits have costs both way.  Multiple repos make it harder for folks 
> to check out all the code, but easier to grab just one corner of it.
> Multiple repos make builds more complex, but faster.  
> e
>  
> My past experience has been that TSCs are at their best when they ask 
> projects to *consider* questions, express that they have thought about them, 
> but then defer broadly to the guys on the ground (a projects committers).
> 
> Do you have thoughts for how that might be done in this situation?
> 
> Ed
> 
> 
> So in my mind this will either lead to:
> 
> A.) unnecessary red tape overhead
> B.) people combining things into a single repo because they don?t want to do 
> the red tape.
> 
> (and believe me I know red tape ?.). Probably you get a bit of both.
> 
> 
> Oliver
> 
> > On Apr 21, 2017, at 12:07 PM  EDT, Ed Warnicke  wrote:
> >
> > Oliver,
> >
> > For my edification, can you give an example or two of where a well scoped 
> > project would set up multiple repos?
> >
> > Ed
> >
> > On Fri, Apr 21, 2017 at 8:47 AM, SPATSCHECK, OLIVER (OLIVER)  > research.att.com> wrote:
> > I have another question on the charter. I just noticed that a project (or 
> > sub project) and a repo are the same thing.  I find this to be sub optimal. 
> > In my mind a project is a well defined scope of work. A repo has to do with 
> > how to optimize my code management.  Am I the only one with the concern 
> > that binding the two will force people into sub optimal repo structures?
> >
> > Thx
> >
> > Oliver
> > ___
> > ONAP-TSC mailing list
> > ONAP-TSC at lists.onap.org
> > https://lists.onap.org/mailman/listinfo/onap-tsc
> >
> 
>

Re: [onap-tsc] [onap-discuss] Importance of common auth service in this release

Re: [onap-tsc] [Onap-usecasesub] R2 use cases planning

Re: [onap-tsc] R2 use cases planning

Re: [onap-tsc] Migration to *.onap.org

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

Re: [onap-tsc] Migration to *.onap.org

[onap-tsc] ONAP User Group

Re: [onap-tsc] Committers and voting - Please read.

Re: [onap-tsc] Committers and voting - Please read.

Re: [onap-tsc] Agenda for tomorrow (Friday) TSC meeting?

Re: [onap-tsc] Optimization framework

Re: [onap-tsc] Optimization framework

Re: [onap-tsc] Optimization framework

Re: [onap-tsc] Face to Face meeting agreements

Re: [onap-tsc] Forward:Re: Comments about Holmes

Re: [onap-tsc] Tentative July ONAP Developers Face-to-Face Meeting

Re: [onap-tsc] Face to Face meeting agreements

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

[onap-tsc] Network Function Change Management Project Proposal

Re: [onap-tsc] Call for vCPE VNFs proposals

Re: [onap-tsc] wiki and conference calls

Re: [onap-tsc] Thoughts on next steps.

Re: [onap-tsc] Proposal: Architecture Subcommittee

Re: [onap-tsc] CI/CD

Re: [onap-tsc] Seed code for Service Orchestrator

Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers

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

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

Re: [onap-tsc] [onap-discuss] Projects

[onap-tsc] Updated TSC Charter

[onap-tsc] Updated TSC Charter

31 matches

Site Navigation

Mail list logo

Footer information