Not sure I understand what you meant by "watch and complain", or who it was addressed to. Neither do I understand "we need to help them" ... who is them? Please clarify if possible. Thanks, Michael
On Tue, Apr 25, 2017 at 8:26 PM, denghui (L) <denghui12 at huawei.com> wrote: > We can?t just watch and complain, we need to help them if there is an > issue, that is the motivation of the proponents of ONAP modeling people in > last ONS summit. > > > > Thanks > > > > DENG Hui > > > > *From:* onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces@ > lists.onap.org] *On Behalf Of *Michael Brenner > *Sent:* Tuesday, April 25, 2017 7:26 AM > *To:* Brian Hedstrom > *Cc:* onap-discuss > *Subject:* Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on > Friday May 5th > > > > ... 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 <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@ > 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@ > oamtechnologies.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- > bounces 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. > onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r= > 2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HRoKLiOZCWLzl3Z- > 00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGHEcVf4U29cHpOGP > KmwevRHGAoeiY&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 > > [image: ??????????] > > > > _______________________________________________ > 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> > > > -- Michael Brenner, Chief Architect NFV ------------------------------ M: +1-732-895-5772 http://getcloudify.org <http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> @cloudifysource <https://twitter.com/CloudifySource> <https://www.linkedin.com/company-beta/17918192/> <https://github.com/cloudify-cosmo> <https://www.youtube.com/cloudifysource> <http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/a367e32e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/a367e32e/attachment.jpg>
