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
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.
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
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,
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
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.
>
>
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
+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
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
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
> “[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
> [ma
) 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
>
&
) 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
>
> Fro
.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.
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
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
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
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, O
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
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
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, OL
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
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
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
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
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 pr
ns 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, "SP
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
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.
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 Cha
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
31 matches
Mail list logo