I think we are on the same page here: let's get the modelers embedded with the dev teams in a collaborative stance. They have a *lot* important to offer, the key is to get them into the fast loop where they can be most effective :)
Ed On Mon, Apr 24, 2017 at 9: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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/be413ea8/attachment.html>
