Topics

[onap-tsc] 答复:Re: Modelling discussion on Friday May 5th


Brian Hedstrom
 

The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...; onap-tsc@...;
日期: 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@....org [mailto:onap-tsc-bounces@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@...; onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
720-470-7091


Ed Warnicke <hagbard@...>
 

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@...> wrote:
The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...; onap-tsc@...;
日期: 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@...g [mailto:onap-tsc-bounces@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@...; onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



Ash Young <ash@...>
 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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@...> wrote:
The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...; onap-tsc@...;
日期: 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@...g [mailto:onap-tsc-bounces@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@...; onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss


Michael Brenner <michael@...>
 

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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@...onap-tsc@...;
日期: 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@...g [mailto:onap-tsc-bounces@lists.onap.orgOn Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: Thursday, April 20, 2017 8:30 AM
To: denghui (L); JANA, RITTWIK (RITTWIK)
Cc: onap-discuss@...onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc


Brian Hedstrom
 

See https://tools.ietf.org/html/draft-betts-netmod-framework-data-schema-uml-04
Framework for Deriving Interface Data Schema from UML Information Models

See https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-03

Guidelines for Translation of UML Information Model to YANG Data Model


On Mon, Apr 24, 2017 at 11:01 AM, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@...; onap-tsc@...;
日期: 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@...g [mailto:onap-tsc-bounces@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@...; onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss





--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
720-470-7091


Brian Hedstrom
 

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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@lists.onap.org [mailto:onap-tsc-bounces@...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@....orgonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
720-470-7091


Michael Brenner <michael@...>
 

... 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@...> 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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


Ed Warnicke <hagbard@...>
 

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@...> 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@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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



Sridhar Ramaswamy <srics.r@...>
 

+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@...> 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@...> 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@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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



Ash Young <ash@...>
 

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@...> 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@...> 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@...> 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@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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



Brijesh Khandelwal
 

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@... [mailto:onap-discuss-bounces@...] 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@...> 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@...> 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@...> 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@...> 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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@...>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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@...> wrote:

The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...onap-tsc@...;

日期: 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@... [mailto:onap-tsc-bounces@...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@...onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


Ed Warnicke <hagbard@...>
 

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@...> 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@...> 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@...> 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@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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




Brian Hedstrom
 

It is the master requirements document for what the data models contain.  It also contains other master requirements and architecture diagrams to convey both static information like what's in the data models as well as behavioral information.
Data models are not designed to be an architecture modeling language. In general, a developer cannot start developing a data model without some form of higher level requirements. What component is the consumer, the server, what methods/actions are supported, what data can pass through the interface and what data is constrained to each components functionality? What are the various use cases that trigger such functionality, and their resulting subset of scenarios?  Which components play an active role in the information exchange to support the use cases? etc.

On Mon, Apr 24, 2017 at 5:25 PM, Michael Brenner <michael@...> 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@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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...> 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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...
https://lists.onap.org/mailman/listinfo/onap-tsc

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
720-470-7091


Ed Warnicke <hagbard@...>
 

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@...> 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@lists.onap.org [mailto:onap-discuss-bounces@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@...> 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@...> 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@...> 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@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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...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@lists.onap.orgonap-tsc@....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@lists.onap.org [mailto:onap-tsc-bounces@...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@....orgonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



Brian Hedstrom
 

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@...> 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@...> 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@...p.org [mailto:onap-discuss-bounces@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@...> 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@...> 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@...> 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@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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
720-470-7091


Ed Warnicke <hagbard@...>
 

Brian,

I'm sympathetic.  I had Model Driven Development experience with UML prior to being involved in yang based modeling.  There's unquestionably a learning curve in learning a new modeling language.  My experience in crossing that chasm though is that had I tried to do modeling in UML intended for yang... I  would have been pushing deeply suboptimal models because yang is different enough than UML that you loose a lot in the translation.  I'm back to being relatively new on Tosca, so again, I feel your pain.  My gut though is that the end experience will be the same: it's worth the investment to learn the tools being used on the ground.

Do we have someone in the community who would be willing to do some intro to Tosca for modelers talks to help us close this gap and get our existing modeling talent up to productive speed faster?  It would be a great service to the community.

Ed

On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@...> wrote:
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@...> 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@...> 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@...p.org [mailto:onap-discuss-bounces@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@...> 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@...> 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@...> 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@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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...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@lists.onap.orgonap-tsc@....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@...nap.org [mailto:onap-tsc-bounces@...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@...gonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC


SULLIVAN, BRYAN L <bs3131@...>
 

I would recommend someone from Gigaspaces to help out with a TOSCA intro. Cloudify has one of the most developed TOSCA-based data models. I’ve been using the Cloudify model and also the more limited TOSCA for NFV Simple Profile model features supported by Tacker in OPNFV as part of the Models project (https://wiki.opnfv.org/display/models).

 

Thanks,

Bryan Sullivan | AT&T

 

From: onap-discuss-bounces@... [mailto:onap-discuss-bounces@...] On Behalf Of Ed Warnicke
Sent: Tuesday, April 25, 2017 11:18 AM
To: Brian Hedstrom <brian.hedstrom@...>
Cc: onap-discuss <onap-discuss@...>
Subject: Re: [onap-discuss] [onap-tsc]
答复:Re: Modelling discussion on Friday May 5th

 

Brian,

 

I'm sympathetic.  I had Model Driven Development experience with UML prior to being involved in yang based modeling.  There's unquestionably a learning curve in learning a new modeling language.  My experience in crossing that chasm though is that had I tried to do modeling in UML intended for yang... I  would have been pushing deeply suboptimal models because yang is different enough than UML that you loose a lot in the translation.  I'm back to being relatively new on Tosca, so again, I feel your pain.  My gut though is that the end experience will be the same: it's worth the investment to learn the tools being used on the ground.

 

Do we have someone in the community who would be willing to do some intro to Tosca for modelers talks to help us close this gap and get our existing modeling talent up to productive speed faster?  It would be a great service to the community.

 

Ed

 

On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@...> wrote:

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@...> 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@...> 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@... [mailto:onap-discuss-bounces@...] 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@...> 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@...> 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@...> 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@...> 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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@...>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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@...> wrote:

The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...onap-tsc@...;

日期: 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@... [mailto:onap-tsc-bounces@...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@...onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


Ed Warnicke <hagbard@...>
 

I'll I take this moment to suggest a 'Technical Workstream' call weekly to present a bunch of technical topics to the community that are of interest cross project?  Tosca might be a good one to start with :)

Ed

On Tue, Apr 25, 2017 at 11:42 AM, SULLIVAN, BRYAN L <bs3131@...> wrote:

I would recommend someone from Gigaspaces to help out with a TOSCA intro. Cloudify has one of the most developed TOSCA-based data models. I’ve been using the Cloudify model and also the more limited TOSCA for NFV Simple Profile model features supported by Tacker in OPNFV as part of the Models project (https://wiki.opnfv.org/display/models).

 

Thanks,

Bryan Sullivan | AT&T

 

From: onap-discuss-bounces@lists.onap.org [mailto:onap-discuss-bounces@lists.onap.org] On Behalf Of Ed Warnicke
Sent: Tuesday, April 25, 2017 11:18 AM
To: Brian Hedstrom <brian.hedstrom@oamtechnologies.com>
Cc: onap-discuss <onap-discuss@...>
Subject: Re: [onap-discuss] [onap-tsc]
答复:Re: Modelling discussion on Friday May 5th

 

Brian,

 

I'm sympathetic.  I had Model Driven Development experience with UML prior to being involved in yang based modeling.  There's unquestionably a learning curve in learning a new modeling language.  My experience in crossing that chasm though is that had I tried to do modeling in UML intended for yang... I  would have been pushing deeply suboptimal models because yang is different enough than UML that you loose a lot in the translation.  I'm back to being relatively new on Tosca, so again, I feel your pain.  My gut though is that the end experience will be the same: it's worth the investment to learn the tools being used on the ground.

 

Do we have someone in the community who would be willing to do some intro to Tosca for modelers talks to help us close this gap and get our existing modeling talent up to productive speed faster?  It would be a great service to the community.

 

Ed

 

On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@oamtechnologies.com> wrote:

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@...> 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@...> 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@lists.onap.org [mailto:onap-discuss-bounces@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@...> 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@...> 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@...> 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@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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@oamtechnologies.com>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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 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, 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@...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@lists.onap.orgonap-tsc@....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@lists.onap.org [mailto:onap-tsc-bounces@...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@....orgonap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 



Amir Levy <amir@...>
 

Thanks Bryan

We will be more than happy to provide TOSCA primer, and much more. I will set something up after the face2face and have it recorded. 

(for TOSCA itself - we already recorded some videos in: https://www.youtube.com/watch?v=aMkqLI6o-58 and  https://www.youtube.com/watch?v=6xGmpi--7-A ) but my offer is to cater a TOSCA specific topics for the ONAP community - if the team interested?

Thanks!

— amir



On Apr 25, 2017, at 11:42 AM, SULLIVAN, BRYAN L <bs3131@...> wrote:

I would recommend someone from Gigaspaces to help out with a TOSCA intro. Cloudify has one of the most developed TOSCA-based data models. I’ve been using the Cloudify model and also the more limited TOSCA for NFV Simple Profile model features supported by Tacker in OPNFV as part of the Models project (https://wiki.opnfv.org/display/models).
 
Thanks,
Bryan Sullivan | AT&T
 
From: onap-discuss-bounces@... [mailto:onap-discuss-bounces@...] On Behalf Of Ed Warnicke
Sent: Tuesday, April 25, 2017 11:18 AM
To: Brian Hedstrom <brian.hedstrom@...>
Cc: onap-discuss <onap-discuss@...>
Subject: Re: [onap-discuss] [onap-tsc] 
答复:Re: Modelling discussion on Friday May 5th
 
Brian,
 
I'm sympathetic.  I had Model Driven Development experience with UML prior to being involved in yang based modeling.  There's unquestionably a learning curve in learning a new modeling language.  My experience in crossing that chasm though is that had I tried to do modeling in UML intended for yang... I  would have been pushing deeply suboptimal models because yang is different enough than UML that you loose a lot in the translation.  I'm back to being relatively new on Tosca, so again, I feel your pain.  My gut though is that the end experience will be the same: it's worth the investment to learn the tools being used on the ground.
 
Do we have someone in the community who would be willing to do some intro to Tosca for modelers talks to help us close this gap and get our existing modeling talent up to productive speed faster?  It would be a great service to the community.
 
Ed
 
On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@...> wrote:
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@...> 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@...> 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@... [mailto:onap-discuss-bounces@...] 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@...> 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@...> 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@...> 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@...> 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@...> 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@...>
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@...>, Brian Hedstrom <brian.hedstrom@...>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>
 
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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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@...> wrote:
The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...onap-tsc@...;
日期: 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@... [mailto:onap-tsc-bounces@...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@...onap-tsc@...
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@...> 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
 
============================================================================================================================
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@...
 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 
--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 
-- 
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
 
_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss


Danny Lin
 

Since we have a whole day discussion next Friday on modeling, can we also arrange some network end to end service use case, ahead of the Friday meeting, so that we can put a context to our discussion which will for sure evolve around various modeling language mentioned below?

 

Danny

 

From: <onap-discuss-bounces@...> on behalf of Ed Warnicke <hagbard@...>
Date: Tuesday, April 25, 2017 at 11:44 AM
To: "SULLIVAN, BRYAN L" <bs3131@...>
Cc: onap-discuss <onap-discuss@...>
Subject: Re: [onap-discuss] [onap-tsc]
答复:Re: Modelling discussion on Friday May 5th

 

I'll I take this moment to suggest a 'Technical Workstream' call weekly to present a bunch of technical topics to the community that are of interest cross project?  Tosca might be a good one to start with :)

 

Ed

 

On Tue, Apr 25, 2017 at 11:42 AM, SULLIVAN, BRYAN L <bs3131@...> wrote:

I would recommend someone from Gigaspaces to help out with a TOSCA intro. Cloudify has one of the most developed TOSCA-based data models. I’ve been using the Cloudify model and also the more limited TOSCA for NFV Simple Profile model features supported by Tacker in OPNFV as part of the Models project (https://wiki.opnfv.org/display/models).

 

Thanks,

Bryan Sullivan | AT&T

 

From: onap-discuss-bounces@... [mailto:onap-discuss-bounces@...] On Behalf Of Ed Warnicke
Sent: Tuesday, April 25, 2017 11:18 AM
To: Brian Hedstrom <brian.hedstrom@...>
Cc: onap-discuss <onap-discuss@...>
Subject: Re: [onap-discuss] [onap-tsc]
答复:Re: Modelling discussion on Friday May 5th

 

Brian,

 

I'm sympathetic.  I had Model Driven Development experience with UML prior to being involved in yang based modeling.  There's unquestionably a learning curve in learning a new modeling language.  My experience in crossing that chasm though is that had I tried to do modeling in UML intended for yang... I  would have been pushing deeply suboptimal models because yang is different enough than UML that you loose a lot in the translation.  I'm back to being relatively new on Tosca, so again, I feel your pain.  My gut though is that the end experience will be the same: it's worth the investment to learn the tools being used on the ground.

 

Do we have someone in the community who would be willing to do some intro to Tosca for modelers talks to help us close this gap and get our existing modeling talent up to productive speed faster?  It would be a great service to the community.

 

Ed

 

On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom@...> wrote:

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@...> 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@...> 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@... [mailto:onap-discuss-bounces@...] 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@...> 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@...> 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@...> 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@...> 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@...> 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@...>

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@...>, Brian Hedstrom <brian.hedstrom@...>

Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana@...>, onap-discuss <onap-discuss@...>, onap-tsc <onap-tsc@...>

 

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


On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard@...> 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@...> wrote:

The way to put all these different data models under a single umbrella is to create a UML 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, 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@...> 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@...onap-tsc@...;

日期: 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@... [mailto:onap-tsc-bounces@...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@...onap-tsc@...
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@...> 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@...
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
ONAP-TSC@...

https://lists.onap.org/mailman/listinfo/onap-tsc

 

_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss

 


_______________________________________________
onap-discuss mailing list
onap-discuss@...
https://lists.onap.org/mailman/listinfo/onap-discuss



 

--

Brian Hedstrom

Founder/CEO

OAM Technology Consulting LLC