Re: [onap-discuss] [vpp-dev] [releng] Proposal to redirect #opendaylight-releng to #lf-releng

[Ed Warnicke]

One  suggestion I would have would be to do a phased transition, with a
'topic' in the existing infra channels set to direct folks to lf-releng,
and a period (3 months?, 6 months?) of keeping a presence on the existing
channels, to be used  to politely request bouncing conversations that arise
in them to lf-releng... this way folks can get used to it, and in worst
case, see in the topic where to go :)

Ed

On Tue, Oct 3, 2017 at 11:12 AM, Thanh Ha 
wrote:

> On Tue, Sep 26, 2017 at 6:38 PM, Thanh Ha 
> wrote:
>
>> Hi Everyone,
>>
>> We'd like to pitch an idea to have #opendaylight-releng irc channel
>> redirect to a new #lf-releng channel. Something that's occurred to us is
>> that many of the networking at LF projects have their own separate releng
>> channels in which folks typically ask JJB related questions. Each of these
>> channels are typically moderately active.
>>
>> Something we've been thinking about is the idea of merging all these
>> releng channels into #lf-releng which we're hoping can combine the
>> communities JJB experts so that JJB and other releng related questions can
>> be more broadly asked.
>>
>> Thoughts?
>>
>> Regards,
>> Thanh
>>
>
> Hi Everyone,
>
> For those that don't know me. I am one of the release engineers working on
> the OpenDaylight project. I've added the fd.io, opnfv, and onap
> communities to this list to get feedback on the idea proposed above. Let me
> know if there's other mailing lists in the respective projects we should be
> cc'ing to include in the discussions.
>
> I'd like to hear from the fd.io, opnfv, and onap for their thoughts on
> the proposal to create a single lf-releng channel on IRC and have all the
> respective releng channels redirect to it. Since our respective releng
> projects use similar technologies like JJB, Jenkins, etc... it might be a
> benefit to pool together our expertise so that it is easier to ask
> questions to the broader community when we need help with things like JJB,
> Gerrit, etc...
>
> You can follow the discussion thread so far from the ODL community
> discussed here:
> https://lists.opendaylight.org/pipermail/dev/2017-September/004066.html
>
>
> Regards,
> Thanh
>
>
> ___
> vpp-dev mailing list
> vpp-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [ONAP EXTERNAL OPEN SOURCE COMMUNITY COORDINATOR] Election Kickoff

[Ed Warnicke]

I wish to nominate myself for ONAP External Open Source Community
Coordinator.

I have broad experience in Open Source Networking for over 15 years.  I've
been a TSC member at OpenDaylight since its inception, am TSC Chair at fd.io.
I know people across many different Open Source Communities, many of them
relevant to ONAP.

I believe strongly that a coordinator role is about identifying the members
of the ONAP community who have existing relationships with Open Source
communities relevant to ONAP, and connecting them with community members
who have needs in those Open Source communities.



​

On Thu, May 11, 2017 at 9:56 PM, Phil Robb 
wrote:

> Hello ONAP Community Members:
>
> Please consider this email as the kickoff of the ONAP External Open Source
> Community Coordinator Election process.  A description of the role can be
> found on the ONAP Technical Community Coordinator's page here:
> https://wiki.onap.org/display/DW/Technical+Community+Coordinators
>
> Please recall, as stated in section 5.2.2.2 of the ONAP TSC Charter, any
> member of the technical community is eligible to run for this position.  It
> is not exclusively reserved for TSC Members.  However, only TSC members are
> eligible to vote when choosing among the potential candidates.  This
> position serves at the pleasure of the TSC and TSC Chairperson.
>
> There are two phases to the election process.  The first is the Nomination
> Phase where community members may nominate themselves for the position of
> "ONAP External Open Source Community Coordinator".  Once the Nomination
> Phase has concluded, we will enter the Election Phase, where all ONAP TSC
> Members are invited and encouraged to vote on the candidates whom have been
> nominated.
>
> Timing:
>
>- Nominations open May 11th, 2017.
>- Nominations close May 17th at 9:00pm Pacific Time
>- Voting begins May 18th, 2017
>- Voting Ends May 24th, 2017 at 9:00pm Pacific Time
>
>
> If you wish to nominate yourself for the position of "ONAP External Open
> Source Community Coordinator", please respond-all to this email with your
> picture (headshot), biography, and statement of interest on why you would
> wish to hold the position.  I wlll post this information to the wiki prior
> to the start of the election so that everyone in the technical community is
> able to become familiar with the candidates.
>
> If you have any questions, please do not hesitate to contact me.
>
> Best,
>
> Phil.
> --
> Phil Robb
> Executive Director, OpenDaylight Project
> VP Operations - Networking & Orchestration, The Linux Foundation
> (O) 970-229-5949 <(970)%20229-5949>
> (M) 970-420-4292 <(970)%20420-4292>
> Skype: Phil.Robb
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Projects

[Ed Warnicke]

If you want to be able to have your project proposal reviewed by the TSC by
two weeks from this Thursday, send your email to the t...@lists.onap.org
mailer by Thursday of this week.

Ed

On Mon, May 8, 2017 at 1:11 PM, Danny Lin <l...@vmware.com> wrote:

> So, essentially, by Thursday this week the latest, we need the email to
> TSC mailing list to “propose” the proposal. Is this understanding correct?
>
>
>
> Danny
>
>
>
>
>
> *From: *<onap-discuss-boun...@lists.onap.org> on behalf of Ed Warnicke <
> hagb...@gmail.com>
> *Date: *Monday, May 8, 2017 at 9:44 AM
> *To: *"SPATSCHECK, OLIVER (OLIVER)" <spat...@research.att.com>
> *Cc: *"onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>,
> onap-tsc <onap-...@lists.onap.org>
> *Subject: *Re: [onap-discuss] Projects
>
>
>
> Oliver,
>
>
>
> A proposal is not 'proposed' till an email to the TSC has been sent.
> There is a two week public comment period *after* that email has been sent
> before it is eligible for a creation review by the TSC.  Once a proposal
> has been announced to the TSC I would suggest providing comment on that
> thread via email.
>
>
>
> Before the email is sent to the TSC announcing the proposal, comments on
> the wiki are likely a good vehicle for feedback.
>
>
>
> Ed
>
>
>
> On Mon, May 8, 2017 at 12:41 PM, SPATSCHECK, OLIVER (OLIVER) <
> spat...@research.att.com> wrote:
>
>
> 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 <hagb...@gmail.com> 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 <
> kanagaraj.manic...@huawei.com> wrote:
> > There is an another wiki  https://wiki.onap.org/display/
> DW/Project+Proposal+Kickoff
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Project-2BProposal-2BKickoff=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3nVF4lkCrih5WqBdByLDuw=Qik8ADjDMNFpL1M6gWrg-2UVz1ljOrlRBEmo0JGCVgQ=YyZmdEdb-1NbHRaU04jYsRcp59hPbD7NayLygH6nPaE=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Proposing-2BA-2BProject=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3nVF4lkCrih5WqBdByLDuw=Qik8ADjDMNFpL1M6gWrg-2UVz1ljOrlRBEmo0JGCVgQ=v61R4vyW9P6Bhc2A1EVmDAYUQRBMuxjQgtKW2ERpwjk=>
> >
> >
> >
> > 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-bounces@
> lists.onap.org] On Behalf Of Danny Lin
> > Sent: Sunday, May 07, 2017 4:14 AM
> > To: Ed Warnicke
> > Cc: onap-discuss@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 <hagb...@gmail.com> wrote:
> &

Re: [onap-discuss] Projects

[Ed Warnicke]

Oliver,

A proposal is not 'proposed' till an email to the TSC has been sent.  There
is a two week public comment period *after* that email has been sent before
it is eligible for a creation review by the TSC.  Once a proposal has been
announced to the TSC I would suggest providing comment on that thread via
email.

Before the email is sent to the TSC announcing the proposal, comments on
the wiki are likely a good vehicle for feedback.

Ed

On Mon, May 8, 2017 at 12:41 PM, SPATSCHECK, OLIVER (OLIVER) <
spat...@research.att.com> wrote:

>
> 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 <hagb...@gmail.com> 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 <
> kanagaraj.manic...@huawei.com> 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-bounces@
> lists.onap.org] On Behalf Of Danny Lin
> > Sent: Sunday, May 07, 2017 4:14 AM
> > To: Ed Warnicke
> > Cc: onap-discuss@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 <hagb...@gmail.com> 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) <
> ma...@research.att.com> 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-discuss@lists.onap.org
> > https://lists.onap.org/mailman/listinfo/onap-discuss
> >
> >
> &g

Re: [onap-discuss] Projects

[Ed Warnicke]

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) <
ma...@research.att.com> 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-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th

[Ed Warnicke]

I'll I take this moment to suggest a 'Technical Workstream' call weekly to
present a bunch of technical topics to the community that are of interest
cross project?  Tosca might be a good one to start with :)

Ed

On Tue, Apr 25, 2017 at 11:42 AM, SULLIVAN, BRYAN L  wrote:

> I would recommend someone from Gigaspaces to help out with a TOSCA intro.
> Cloudify has one of the most developed TOSCA-based data models. I?ve been
> using the Cloudify model and also the more limited TOSCA for NFV Simple
> Profile model features supported by Tacker in OPNFV as part of the Models
> project (https://wiki.opnfv.org/display/models).
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> *From:* onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Ed Warnicke
> *Sent:* Tuesday, April 25, 2017 11:18 AM
> *To:* Brian Hedstrom 
> *Cc:* onap-discuss 
> *Subject:* Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on
> Friday May 5th
>
>
>
> Brian,
>
>
>
> I'm sympathetic.  I had Model Driven Development experience with UML prior
> to being involved in yang based modeling.  There's unquestionably a
> learning curve in learning a new modeling language.  My experience in
> crossing that chasm though is that had I tried to do modeling in UML
> intended for yang... I  would have been pushing deeply suboptimal models
> because yang is different enough than UML that you loose a lot in the
> translation.  I'm back to being relatively new on Tosca, so again, I feel
> your pain.  My gut though is that the end experience will be the same: it's
> worth the investment to learn the tools being used on the ground.
>
>
>
> Do we have someone in the community who would be willing to do some intro
> to Tosca for modelers talks to help us close this gap and get our existing
> modeling talent up to productive speed faster?  It would be a great service
> to the community.
>
>
>
> Ed
>
>
>
> On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@
> oamtechnologies.com> wrote:
>
> As a modeler, I had challenges with coming late to the game on the Open-O
> project (FEB timeframe). Everything was TOSCA based and I didn't have TOSCA
> data model experience.
>
> As such, I wasn't able to effectively understand what the "information"
> model was.
>
> The barrier to entry was therefore needing to learn TOSCA data modeling
> language.
>
> It is unrealistic to assume a data modeler has mastery of all data
> modeling languages, encodings, toolsets, etc.  How does a domain expert who
> is not in a developer role effectively communicate a set of requirements,
> architecture and design to developers? Are we just skipping a design and
> architecture phase? How do we capture and document what needs to be built,
> before building it? I definitely support an agile iterative approach to all
> of this.
>
>
>
> On Tue, Apr 25, 2017 at 12:00 PM, Ed Warnicke  wrote:
>
> I think the most productive thing we can do is figure out ways to 'embed'
> good modeling folks (its a very real, and distinct skill) closer to the
> ground
>
> in the projects with a more collaborative stance.   Encouraging these
> kinds of things were suggested as the role for the modeling coordinator.
>
>
>
> Ed
>
>
>
> On Tue, Apr 25, 2017 at 9:56 AM, Brijesh Khandelwal <
> kbrijesh at techmahindra.com> wrote:
>
> Greetings,
>
>
>
> Essentially, two kind of models
>
> 1. Information Models: Which will define ?What? needs to be orchestrate.
> These ?What? model to get inputs from Data model parts of TOSCA, YAML,
> YANG, A, and SDC for standardization.
>
> 2. Behavior Models: Which will define ?How? to orchestrate. This is
> covered by Workflow, BPMN/BPEL, UML-Activity/State models, Some behavior
> parts in TOSCA, YANG/NETCONF.
>
>  2a. While BPMN/BPEL is good for process/workflow orchestration, but
> there is increasing need to include Event-Driven orchestration for
> DCAE/Policy based closed-loops, dynamic changes to process definitions,
> flexibility to execute parts of process.
>
>
>
> I think first focus on modeling standard can be on ?What? models. ?How?
> models need to evolve further, can have multiple-options to use BPMN/BPEL,
> custom state-machines or event-driven orchestration.
>
>
>
> -Brijesh
>
>
>
>
>
> *From:* onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Ash Young
> *Sent:* Tuesday, April 25, 2017 8:35 AM
> *To:* Sridhar Ramaswamy
> *Cc:* onap-discuss
> *Subject:* Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on
> Friday May 5th
>
>
>

[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th

[Ed Warnicke]

Brian,

I'm sympathetic.  I had Model Driven Development experience with UML prior
to being involved in yang based modeling.  There's unquestionably a
learning curve in learning a new modeling language.  My experience in
crossing that chasm though is that had I tried to do modeling in UML
intended for yang... I  would have been pushing deeply suboptimal models
because yang is different enough than UML that you loose a lot in the
translation.  I'm back to being relatively new on Tosca, so again, I feel
your pain.  My gut though is that the end experience will be the same: it's
worth the investment to learn the tools being used on the ground.

Do we have someone in the community who would be willing to do some intro
to Tosca for modelers talks to help us close this gap and get our existing
modeling talent up to productive speed faster?  It would be a great service
to the community.

Ed

On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <
brian.hedstrom at oamtechnologies.com> wrote:

> As a modeler, I had challenges with coming late to the game on the Open-O
> project (FEB timeframe). Everything was TOSCA based and I didn't have TOSCA
> data model experience.
> As such, I wasn't able to effectively understand what the "information"
> model was.
> The barrier to entry was therefore needing to learn TOSCA data modeling
> language.
> It is unrealistic to assume a data modeler has mastery of all data
> modeling languages, encodings, toolsets, etc.  How does a domain expert who
> is not in a developer role effectively communicate a set of requirements,
> architecture and design to developers? Are we just skipping a design and
> architecture phase? How do we capture and document what needs to be built,
> before building it? I definitely support an agile iterative approach to all
> of this.
>
> On Tue, Apr 25, 2017 at 12:00 PM, Ed Warnicke  wrote:
>
>> I think the most productive thing we can do is figure out ways to 'embed'
>> good modeling folks (its a very real, and distinct skill) closer to the
>> ground
>> in the projects with a more collaborative stance.   Encouraging these
>> kinds of things were suggested as the role for the modeling coordinator.
>>
>> Ed
>>
>> On Tue, Apr 25, 2017 at 9:56 AM, Brijesh Khandelwal <
>> kbrijesh at techmahindra.com> wrote:
>>
>>> Greetings,
>>>
>>>
>>>
>>> Essentially, two kind of models
>>>
>>> 1. Information Models: Which will define ?What? needs to be orchestrate.
>>> These ?What? model to get inputs from Data model parts of TOSCA, YAML,
>>> YANG, A, and SDC for standardization.
>>>
>>> 2. Behavior Models: Which will define ?How? to orchestrate. This is
>>> covered by Workflow, BPMN/BPEL, UML-Activity/State models, Some behavior
>>> parts in TOSCA, YANG/NETCONF.
>>>
>>>  2a. While BPMN/BPEL is good for process/workflow orchestration, but
>>> there is increasing need to include Event-Driven orchestration for
>>> DCAE/Policy based closed-loops, dynamic changes to process definitions,
>>> flexibility to execute parts of process.
>>>
>>>
>>>
>>> I think first focus on modeling standard can be on ?What? models. ?How?
>>> models need to evolve further, can have multiple-options to use BPMN/BPEL,
>>> custom state-machines or event-driven orchestration.
>>>
>>>
>>>
>>> -Brijesh
>>>
>>>
>>>
>>>
>>>
>>> *From:* onap-discuss-bounces at lists.onap.org [mailto:
>>> onap-discuss-bounces at lists.onap.org] *On Behalf Of *Ash Young
>>> *Sent:* Tuesday, April 25, 2017 8:35 AM
>>> *To:* Sridhar Ramaswamy
>>> *Cc:* onap-discuss
>>> *Subject:* Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on
>>> Friday May 5th
>>>
>>>
>>>
>>> Can we please have parallel options then? This has disaster written all
>>> over it. I have no problem with people moving fast. I have spent the past
>>> almost 5 years listening to the same people going down this path. So while
>>> I fail to see the speed that keeps being promised, I'm quite certain that
>>> our overall manageability has not really improved across the industry with
>>> this TOSCA only world.
>>>
>>>
>>>
>>> I really don't want to fight and this is Open Source. So can we leave
>>> room for some of the other folks too?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Ash
>>>
>>>
>>>
>>> On Mon, Apr 24, 2017 at 11:54 PM, Sridh

[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th

[Ed Warnicke]

I think the most productive thing we can do is figure out ways to 'embed'
good modeling folks (its a very real, and distinct skill) closer to the
ground
in the projects with a more collaborative stance.   Encouraging these kinds
of things were suggested as the role for the modeling coordinator.

Ed

On Tue, Apr 25, 2017 at 9:56 AM, Brijesh Khandelwal <
kbrijesh at techmahindra.com> wrote:

> Greetings,
>
>
>
> Essentially, two kind of models
>
> 1. Information Models: Which will define ?What? needs to be orchestrate.
> These ?What? model to get inputs from Data model parts of TOSCA, YAML,
> YANG, A, and SDC for standardization.
>
> 2. Behavior Models: Which will define ?How? to orchestrate. This is
> covered by Workflow, BPMN/BPEL, UML-Activity/State models, Some behavior
> parts in TOSCA, YANG/NETCONF.
>
>  2a. While BPMN/BPEL is good for process/workflow orchestration, but
> there is increasing need to include Event-Driven orchestration for
> DCAE/Policy based closed-loops, dynamic changes to process definitions,
> flexibility to execute parts of process.
>
>
>
> I think first focus on modeling standard can be on ?What? models. ?How?
> models need to evolve further, can have multiple-options to use BPMN/BPEL,
> custom state-machines or event-driven orchestration.
>
>
>
> -Brijesh
>
>
>
>
>
> *From:* onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Ash Young
> *Sent:* Tuesday, April 25, 2017 8:35 AM
> *To:* Sridhar Ramaswamy
> *Cc:* onap-discuss
> *Subject:* Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on
> Friday May 5th
>
>
>
> Can we please have parallel options then? This has disaster written all
> over it. I have no problem with people moving fast. I have spent the past
> almost 5 years listening to the same people going down this path. So while
> I fail to see the speed that keeps being promised, I'm quite certain that
> our overall manageability has not really improved across the industry with
> this TOSCA only world.
>
>
>
> I really don't want to fight and this is Open Source. So can we leave room
> for some of the other folks too?
>
>
>
> Thanks,
>
>
>
> Ash
>
>
>
> On Mon, Apr 24, 2017 at 11:54 PM, Sridhar Ramaswamy 
> wrote:
>
> +1, couldn?t agree more. Also, we need to keep in mind the inherent time
> lag in consuming Information Model -> Data Model -> Implementation which
> will slow us down.
>
>
>
> Based on my experience working between TOSCA NFV and Tacker project, an
> iterative approach works the best - consume an available, sufficiently
> flexible data model in the implementation to validate and incorporate
> feedback based its outcome back into the data model. I say this with a huge
> respect for the modelers who are critical in taking us towards a harmonized
> Data Model / Information model for NFV.
>
>
>
> - Sridhar
>
>
>
> On Mon, Apr 24, 2017 at 4:47 PM, Ed Warnicke  wrote:
>
> I strongly second this.
>
>
>
> My experience is that there is a huge service for the good modelers who
> engage with the community to do incredible good... but modeling in a
> vacuum, away from the implementation, and then just expecting the
> implementers to follow directions works poorly.
>
>
>
> I'd say that a far better activity for the long term health would be to
> plug good model people into the places in the community where models are in
> progress.  Their wisdom as participants can be huge, but they need to
> *participate*, not work off in a tower of UML.
>
>
>
> Ed
>
>
>
> On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner 
> wrote:
>
> ... on the other hand, what does one do with a smooth cohesive model, if
> you can't easily translate it to a data model? Without any intent to dive
> into a debate about whether the example is right or not ... we have an ETSI
> NFV VNF UML model ... and we cannot translate it into any data model - it
> takes manual work. The other issue is sort of the reverse - i.e. you don't
> actually KNOW that the UML model is right, until you implement it. And it
> is difficult to implement it, when you don't have the automatic translation
> tools. So you end up building an ideal model, but you don't know if it
> works ... until you have the right translation tools. How long is one to
> wait ... instead of implementing and iterating?
>
> Like with any other project, it really comes down to a schedule, and
> knowing what you want to achieve within that schedule.
>
>
>
> Best,
>
> Michael
>
>
>
> On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom <brian.hedstrom@
> oamtechnologies.com>

[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th

[Ed Warnicke]

I strongly second this.

My experience is that there is a huge service for the good modelers who
engage with the community to do incredible good... but modeling in a
vacuum, away from the implementation, and then just expecting the
implementers to follow directions works poorly.

I'd say that a far better activity for the long term health would be to
plug good model people into the places in the community where models are in
progress.  Their wisdom as participants can be huge, but they need to
*participate*, not work off in a tower of UML.

Ed

On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner 
wrote:

> ... on the other hand, what does one do with a smooth cohesive model, if
> you can't easily translate it to a data model? Without any intent to dive
> into a debate about whether the example is right or not ... we have an ETSI
> NFV VNF UML model ... and we cannot translate it into any data model - it
> takes manual work. The other issue is sort of the reverse - i.e. you don't
> actually KNOW that the UML model is right, until you implement it. And it
> is difficult to implement it, when you don't have the automatic translation
> tools. So you end up building an ideal model, but you don't know if it
> works ... until you have the right translation tools. How long is one to
> wait ... instead of implementing and iterating?
> Like with any other project, it really comes down to a schedule, and
> knowing what you want to achieve within that schedule.
>
> Best,
> Michael
>
> On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom <brian.hedstrom@
> oamtechnologies.com> wrote:
>
>> While the tools are maturing and advancing, if we choose to close that
>> door now, there's no cohesive UML Common Information Model for ONAP.
>> Consequently, we would lack a protocol agnostic information model and when
>> the next cool data modeling language or encoding scheme comes out, we have
>> to start again with working backward. Another key benefit is that UML is
>> much easier to comprehend due to it's graphical diagram nature, versus
>> needing to understand a data modeling language and/or data encoding
>> mechanism.
>> Consensus can be made on class diagrams for example, then translation to
>> a data modeling language can be easily done by hand or by the emerging
>> tools (see my previous email with the links).
>>
>> On Mon, Apr 24, 2017 at 12:29 PM, Michael Brenner > > wrote:
>>
>>> Hi all,
>>>
>>> I actually tend to agree with Ed. While it may be an ideal approach in
>>> theory, tools for automatic generation from UML to Yang, or other modeling
>>> languages for that matter are improving, they are still too far from
>>> perfect, and require a lot of hand-holding so-to-speak, and as a result -
>>> too many headaches. We may be mired in tool debugging, instead on
>>> progressing on ONAP.
>>>
>>> Michael
>>>
>>> *From: *Ash Young 
>>> *Subject: **Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion
>>> on Friday May 5th*
>>> *Date: *April 24, 2017 at 10:09:22 AM PDT
>>> *To: *Ed Warnicke , Brian Hedstrom <
>>> brian.hedstrom at oamtechnologies.com>
>>> *Cc: *"JANA, RITTWIK \(RITTWIK\)" ,
>>> onap-discuss , onap-tsc <
>>> onap-tsc at lists.onap.org>
>>>
>>> I'm actually in agreement with Brian on approach and tool. So much work
>>> has been going on here that I really don't want to see us go backwards by
>>> thinking Yang solves everything.
>>>
>>> Ash
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 24, 2017, at 12:01, Ed Warnicke  wrote:
>>>
>>> I love UML in a variety of contexts, but for expressing things that are
>>> destined to be expressed in yang, or for creating things to be rendered to
>>> yang, in my experience its been a very poor fit.
>>>
>>> Ed
>>>
>>> On Mon, Apr 24, 2017 at 9:41 AM, Brian Hedstrom >> chnologies.com> wrote:
>>>
>>>> The way to put all these different data models under a single umbrella
>>>> is to create a UML
>>>> <https://en.wikipedia.org/wiki/Unified_Modeling_Language> Information
>>>> Model using Eclipse/Papyrus (as an open source tool).
>>>> Unified Modeling Language (UML) is a standard syntax for describing the
>>>> architectural design of a system
>>>>
>>>>- Object Management Group (OMG) & ISO standard
>>>>- Originated from object-oriented software development methods
>>>>
>>>> UML includes many diagrams types 

[onap-discuss] Proposal for list split of onap-discuss

[Ed Warnicke]

Bryan,

That's a good point.  The other thing that happens very quickly (and its
already happening here, thus this thread) is that the volume of traffic
gets sufficiently high that people tune out.  Forcing everyone onto a
single lists is actually dis-unifying once the traffic on that list exceeds
a threshhold that one could argue, by virtue of this thread, we have
already exceeded.

Ed

On Thu, Apr 20, 2017 at 11:37 AM, SULLIVAN, BRYAN L  wrote:

> The flip side (just to be considered in the supporting infra) is that it?s
> not hard for projects to become disconnected when segregated.
> Needing/managing many project email list subscriptions inhibits the ability
> to easily keep an overview of how things are progressing across projects.
> Of course at some point, the firehose becomes unmanageable and the demands
> of focus require segregation.
>
>
>
> But some infra support can address the limitations of project-specific
> lists:
>
> -  Mail subscription system (e.g. http://lists.onap.org) support
> for a ?auto-subscribe to all? option for those who want it.
>
> -  Mail archive system that supports an effective search, e.g.
> the W3C system: https://www.w3.org/Search/Mail/Public/
>
> o   Mailman is woefully inadequate for this. Some services exist that
> could possibly be used for this, e.g. http://openstack.markmail.org/
> search/?q= works well for me, for OpenStack in general.
>
> o   Note that you can also just subscribe using some email service ala
> Gmail or Hotmail, that provides a search feature that works for you. That
> can completely solve your corporate inbox issue, given that you?re allowed
> to use non-corporate email services for open source work.
>
>
>
> If we want to create project-specific lists, I recommend that the LF work
> on the two supporting infra capabilities above, or include workarounds such
> as above in developer intros/FAQs.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> *From:* onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Ed Warnicke
> *Sent:* Thursday, April 20, 2017 10:46 AM
> *To:* Andrew Grimberg 
> *Cc:* onap-discuss 
> *Subject:* Re: [onap-discuss] Proposal for list split of onap-discuss
>
>
>
> I hit a situation just yesterday where there was literally no reasonable
> way to address a sub-community of openstack because they have
>
> a giant monster mailer, and thus there was no reasonable way to address
> the interested subcommunity.
>
>
>
> Monster mega lists suppress conversation.  Give each project their own
> space for their community to talk.
>
>
>
> Ed
>
>
>
> On Thu, Apr 20, 2017 at 10:34 AM, Andrew Grimberg <
> agrimberg at linuxfoundation.org> wrote:
>
> On 04/20/2017 09:46 AM, Ed Warnicke wrote:
> > Josef,
> >
> > I couldn't agree more.  Typically 'discuss' in most communities is for
> > 'cross project' discussion.  Project specific converstions tend to
> happen on
> > ${project}-dev mailers (think dcae-dev, sdnc-dev, etc).   For this to
> > work, one needs projects.  Projects *need* their own space to hold
> > publicly visible conversations.
> >
> > I would strongly recommend *against* a single list in the long term.  It
> > becomes overwhelming, and it strongly discourages folks sending email
> > because the room is so big.
>
> Our largest communities have major cross-posting problems along with new
> people regularly informing us that they don't know where to send things
> because of having too many lists. As such, I can't express how strongly
> I recommend only breaking out a specific topic to a separate list _iff_
> it proves to cause too much traffic on the general list.
>
> As Aimee pointed out OpenStack, which is a community larger than our
> largest community, doesn't do what you're talking about. They use topics
> on their lists precisely to get around the mailing list explosion of a
> list per project that you're suggesting.
>
>
> -Andy-
>
> --
> Andrew J Grimberg
> Lead, IT Release Engineering
> The Linux Foundation
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170420/26578ec0/attachment.html>

[onap-discuss] Proposal for list split of onap-discuss

[Ed Warnicke]

I hit a situation just yesterday where there was literally no reasonable
way to address a sub-community of openstack because they have
a giant monster mailer, and thus there was no reasonable way to address the
interested subcommunity.

Monster mega lists suppress conversation.  Give each project their own
space for their community to talk.

Ed

On Thu, Apr 20, 2017 at 10:34 AM, Andrew Grimberg <
agrimberg at linuxfoundation.org> wrote:

> On 04/20/2017 09:46 AM, Ed Warnicke wrote:
> > Josef,
> >
> > I couldn't agree more.  Typically 'discuss' in most communities is for
> > 'cross project' discussion.  Project specific converstions tend to
> happen on
> > ${project}-dev mailers (think dcae-dev, sdnc-dev, etc).   For this to
> > work, one needs projects.  Projects *need* their own space to hold
> > publicly visible conversations.
> >
> > I would strongly recommend *against* a single list in the long term.  It
> > becomes overwhelming, and it strongly discourages folks sending email
> > because the room is so big.
>
> Our largest communities have major cross-posting problems along with new
> people regularly informing us that they don't know where to send things
> because of having too many lists. As such, I can't express how strongly
> I recommend only breaking out a specific topic to a separate list _iff_
> it proves to cause too much traffic on the general list.
>
> As Aimee pointed out OpenStack, which is a community larger than our
> largest community, doesn't do what you're talking about. They use topics
> on their lists precisely to get around the mailing list explosion of a
> list per project that you're suggesting.
>
> -Andy-
>
> --
> Andrew J Grimberg
> Lead, IT Release Engineering
> The Linux Foundation
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170420/3851724e/attachment.html>