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 <srics.r at gmail.com> 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 <hagbard at gmail.com> 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 <michael at gigaspaces.com> >> 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 at 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 < >>>> michael at gigaspaces.com> 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 <ash at yunify.org> >>>>> *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 <hagbard at gmail.com>, Brian Hedstrom < >>>>> brian.hedstrom at oamtechnologies.com> >>>>> *Cc: *"JANA, RITTWIK \(RITTWIK\)" <rjana at research.att.com>, >>>>> onap-discuss <onap-discuss at lists.onap.org>, 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 <hagbard at gmail.com> 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 <brian.hedstrom at oamte >>>>> 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 to graphically represent parts of a >>>>>> system?s model, including >>>>>> >>>>>> - Structural Views: The static nature of the system using >>>>>> objects, attributes and relationships (e.g., information or >>>>>> components that >>>>>> must be present in the system). This includes class diagrams and >>>>>> component >>>>>> diagrams. >>>>>> - Behavioral: The dynamic nature of the system through >>>>>> collaboration of objects and state changes (e.g., activities >>>>>> performed by >>>>>> the system). This includes use case diagrams, sequence diagrams, state >>>>>> machines. >>>>>> >>>>>> UML is protocol agnostic and therefore these "Information Models" are >>>>>> protocol agnostic. >>>>>> >>>>>> UML models can then be transformed into protocol specific data models >>>>>> such as YANG, XML, SMIv2, etc. >>>>>> >>>>>> Creating a UML Information Model allows data cohesion across the >>>>>> various interfaces in the system. Using Interface Realizations >>>>>> <http://www.uml-diagrams.org/realization.html>, specific interfaces >>>>>> can be modeled. In fact, an interface Information Model could be >>>>>> transformed into multiple data models to support multiple management >>>>>> protocols. >>>>>> >>>>>> Therefore, the focus first is on building a UML Information Model, >>>>>> then once that's approved by the organization, then data models and >>>>>> encodings can be generated based on the chosen interface protocols. >>>>>> >>>>>> Thanks, >>>>>> Brian >>>>>> >>>>>> On Sun, Apr 23, 2017 at 5:13 AM, <zhao.huabing at zte.com.cn> wrote: >>>>>> >>>>>>> Hi Brijesh, >>>>>>> >>>>>>> You brought up a great topic, we may need to converge at the same >>>>>>> aspect, but for different aspects, there are different modelling >>>>>>> languages >>>>>>> which can better meet the specific requirement of that aspect, and they >>>>>>> are >>>>>>> very complementary. >>>>>>> >>>>>>> For example, TOSCA(Heat is another, come with openstack) is a good >>>>>>> choice for the topology modelling of cloud application , YANG can be >>>>>>> used >>>>>>> for the configuration model( normally using for L2 L3, can be used for >>>>>>> L4-L7 as well), and BPMN is good at workflow orchestration. >>>>>>> >>>>>>> It's difficult to put all these different modelling capabilities in >>>>>>> a single data model or using an unique DSL, and we don't need to. But >>>>>>> It's >>>>>>> possible to make them work together smoothly under a unified umbrella >>>>>>> system to accomplish the automated close loop and I'm glad to see ONAP >>>>>>> has >>>>>>> already make a very good start at that job. >>>>>>> >>>>>>> Thanks, >>>>>>> Huabing >>>>>>> >>>>>>> ???? >>>>>>> *???:* BrijeshKhandelwal; >>>>>>> *???:*GILBERT, MAZIN E (MAZIN E); denghui (L); JANA,RITTWIK >>>>>>> (RITTWIK); onap-discuss at lists.onap.org; onap-tsc at lists.onap.org; >>>>>>> *??:* 2017-04-22 11:56:56 >>>>>>> *??:Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May >>>>>>> 5th* >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Adding some thoughts on information model: >>>>>>> >>>>>>> Orchestration need to interoperate among different interfaces, which >>>>>>> in turn need to deal with very different payloads in form of YAML, YANG, >>>>>>> JSON etc. There will be lots of data processing among these models to >>>>>>> process complete service. Handling these templates in orchestrator will >>>>>>> impose limitations on capability and performance of orchestrator. >>>>>>> >>>>>>> So, there should have standardized data model for smooth processing >>>>>>> among orchestration steps. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Probably first time, orchestration is composing 3 different worlds >>>>>>> of Network, Infra, IT, with different tunes of YANG, YAML, JSON/XML. >>>>>>> >>>>>>> Is there a play to develop standardized data models for >>>>>>> orchestration, which will meet needs of each area? Is TOSCA sufficient? >>>>>>> Or >>>>>>> need some extended JSON data models? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -Brijesh >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounc >>>>>>> es at lists.onap.org] *On Behalf Of *GILBERT, MAZIN E (MAZIN E) >>>>>>> *Sent:* Thursday, April 20, 2017 8:30 AM >>>>>>> *To:* denghui (L); JANA, RITTWIK (RITTWIK) >>>>>>> *Cc:* onap-discuss at lists.onap.org; onap-tsc at lists.onap.org >>>>>>> *Subject:* Re: [onap-tsc] Modelling discussion on Friday May 5th >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rittwik, Deng, >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is great. Thank you for taking the lead. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I realize the focus is on TOSCA and parsers. Wonderful! >>>>>>> >>>>>>> I want to take you one level higher to start by discussing >>>>>>> >>>>>>> what the framework look like for the information model. Perhaps >>>>>>> invite folks who have >>>>>>> >>>>>>> operational experience. Then start describing the differernt >>>>>>> >>>>>>> data models and how TOSCA plays a role in driving service chaining >>>>>>> and micro services >>>>>>> >>>>>>> (like analytics, data collections, etc). >>>>>>> >>>>>>> >>>>>>> >>>>>>> It would be great if the outcome of this mini session to >>>>>>> >>>>>>> be a recommendation position/paper or a proposal for a project. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Mazin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Apr 20, 2017, at 4:34 AM, denghui (L) <denghui12 at huawei.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello all >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are happy to let you know that we are hosting a modeling session >>>>>>> on Friday, May 5th, AT&T Lab. >>>>>>> >>>>>>> 9:00-10:30 Shitao moderate: TOSCA NFV Profile >>>>>>> >>>>>>> 10:30-12:00 Rittwik moderate: AT&T Parser >>>>>>> >>>>>>> 13:30-16:00 DengHui moderate: Modelling & Opendeployment >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please kindly help to let us know if you are interested in joining >>>>>>> us, so that we can book a proper meeting room for our discussion >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rittwik & DENG Hui >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ONAP-TSC mailing list >>>>>>> ONAP-TSC at lists.onap.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.o >>>>>>> nap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeM >>>>>>> TSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HR >>>>>>> oKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGH >>>>>>> EcVf4U29cHpOGPKmwevRHGAoeiY&e= >>>>>>> >>>>>>> >>>>>>> >>>>>>> ============================================================ >>>>>>> ================================================================ >>>>>>> >>>>>>> Disclaimer: This message and the information contained herein is >>>>>>> proprietary and confidential and subject to the Tech Mahindra policy >>>>>>> statement, you may review the policy at http://www.techmahindra.com >>>>>>> /Disclaimer.html externally http://tim.techmahindra.com/tim/ >>>>>>> disclaimer.html internally within TechMahindra. >>>>>>> >>>>>>> ============================================================ >>>>>>> ================================================================ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ONAP-TSC mailing list >>>>>>> ONAP-TSC at lists.onap.org >>>>>>> https://lists.onap.org/mailman/listinfo/onap-tsc >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> onap-discuss mailing list >>>>> onap-discuss at lists.onap.org >>>>> https://lists.onap.org/mailman/listinfo/onap-discuss >>>>> >>>>> >>>> >>>> >>>> -- >>>> Brian Hedstrom >>>> Founder/CEO >>>> OAM Technology Consulting LLC >>>> oamtechnologyconsulting.com >>>> brian.hedstrom at oamtechnologies.com >>>> 720-470-7091 <(720)%20470-7091> >>>> >>> >>> >>> _______________________________________________ >>> onap-discuss mailing list >>> onap-discuss at lists.onap.org >>> https://lists.onap.org/mailman/listinfo/onap-discuss >>> >>> >> >> _______________________________________________ >> onap-discuss mailing list >> onap-discuss at lists.onap.org >> https://lists.onap.org/mailman/listinfo/onap-discuss >> >> > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/de4cc959/attachment.html>
