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 <hagbard at gmail.com> 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&AI, 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, 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 >> >> >> >> _______________________________________________ >> 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 > > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedstrom at oamtechnologies.com 720-470-7091 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/923ee9a9/attachment.html>
