+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/20170424/b3ab25b9/attachment-0001.html>
