Hi, Can someone please confirm if below is the correct bridge for Modelling Discussion?
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/719372650 Or iPhone one-tap (US Toll): +14086380968,719372650# or +16465588656,719372650# Or Telephone: Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll) Meeting ID: 719 372 650 International numbers available: https://zoom.us/zoomconference?m=SG5cGU7xqKfbx3oMfowb0y42OL0_AxkM Thanks & Regards, Shruti Jaiswal From: [email protected] [mailto:[email protected]] On Behalf Of Michael Brenner Sent: Monday, May 1, 2017 10:04 PM To: denghui (L) <[email protected]> Cc: onap-discuss <[email protected]> Subject: Re: [onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th Thanks Deng Hui for the clarification. Best regards, Michael On Mon, May 1, 2017 at 12:29 PM, denghui (L) <[email protected]<mailto:[email protected]>> wrote: “Them” I mean you mentioned down below here “ETSI NFV VNF UML Model”, and you also said “we cannot translate it into any data model - it takes manual work” In this case, we should help them to improve their model to better match with ONAP implementation. Thanks DENG Hui From: Michael Brenner [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, April 26, 2017 11:11 AM To: denghui (L) <[email protected]<mailto:[email protected]>> Cc: Brian Hedstrom <[email protected]<mailto:[email protected]>>; onap-discuss <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th 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) <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>, Brian Hedstrom <[email protected]<mailto:[email protected]>> Cc: "JANA, RITTWIK \(RITTWIK\)" <[email protected]<mailto:[email protected]>>, onap-discuss <[email protected]<mailto:[email protected]>>, onap-tsc <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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, <[email protected]<mailto:[email protected]>> 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); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; 日期: 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of GILBERT, MAZIN E (MAZIN E) Sent: Thursday, April 20, 2017 8:30 AM To: denghui (L); JANA, RITTWIK (RITTWIK) Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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) <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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=731fuCUnXbuPSOGHEcVf4U29cHpOGPKmwevRHGAoeiY&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 [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-tsc [图像已被发件人删除。] _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-discuss -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com<http://oamtechnologyconsulting.com> [email protected]<mailto:[email protected]> 720-470-7091<tel:(720)%20470-7091> -- Michael Brenner, Chief Architect NFV [图像已被发件人删除。] ________________________________ M: +1-732-895-5772<tel:(732)%20895-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> -- Michael Brenner, Chief Architect NFV [https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-27020792c3e94269b883d9a828be029f56c08986b2ab208a46143b169592c35a.png] ________________________________ 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://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]<https://twitter.com/CloudifySource> [https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png] <https://www.linkedin.com/company-beta/17918192/> [https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/6f7421bc5b9a93a0649735bbc8589b200c678bf08af9d7e0cebf1b3cffcdac94.png] <https://github.com/cloudify-cosmo> [https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/4be4d1377f4c1afe70a25e78926b6aad4e0a4fb1d45a7727e31d5a807eb3aae7.png] <https://www.youtube.com/cloudifysource> [https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-218433c43f71db1180fd27884e3650b01b94c578c594b32c6f49c3daa3151366.png]<http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer> Amdocs Development Centre India Private Limited having CIN: U72200PN2004PTC0188320 converted into Amdocs Development Centre India LLP (A limited liability partnership with LLP Identification Number: AAI-6901 effective 28th Feb 2017)
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
