Greetings,
Essentially, two kind of models
1. Information Models: Which will define ?What? needs to be orchestrate. These
?What? model to get inputs from Data model parts of TOSCA, YAML, YANG, A&AI,
and SDC for standardization.
2. Behavior Models: Which will define ?How? to orchestrate. This is covered by
Workflow, BPMN/BPEL, UML-Activity/State models, Some behavior parts in TOSCA,
YANG/NETCONF.
2a. While BPMN/BPEL is good for process/workflow orchestration, but there
is increasing need to include Event-Driven orchestration for DCAE/Policy based
closed-loops, dynamic changes to process definitions, flexibility to execute
parts of process.
I think first focus on modeling standard can be on ?What? models. ?How? models
need to evolve further, can have multiple-options to use BPMN/BPEL, custom
state-machines or event-driven orchestration.
-Brijesh
From: onap-discuss-bounces at lists.onap.org
[mailto:[email protected]] On Behalf Of Ash Young
Sent: Tuesday, April 25, 2017 8:35 AM
To: Sridhar Ramaswamy
Cc: onap-discuss
Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday
May 5th
Can we please have parallel options then? This has disaster written all over
it. I have no problem with people moving fast. I have spent the past almost 5
years listening to the same people going down this path. So while I fail to see
the speed that keeps being promised, I'm quite certain that our overall
manageability has not really improved across the industry with this TOSCA only
world.
I really don't want to fight and this is Open Source. So can we leave room for
some of the other folks too?
Thanks,
Ash
On Mon, Apr 24, 2017 at 11:54 PM, Sridhar Ramaswamy <srics.r at
gmail.com<mailto:srics.r at gmail.com>> wrote:
+1, couldn?t agree more. Also, we need to keep in mind the inherent time lag in
consuming Information Model -> Data Model -> Implementation which will slow us
down.
Based on my experience working between TOSCA NFV and Tacker project, an
iterative approach works the best - consume an available, sufficiently flexible
data model in the implementation to validate and incorporate feedback based its
outcome back into the data model. I say this with a huge respect for the
modelers who are critical in taking us towards a harmonized Data Model /
Information model for NFV.
- Sridhar
On Mon, Apr 24, 2017 at 4:47 PM, Ed Warnicke <hagbard at
gmail.com<mailto:hagbard at gmail.com>> wrote:
I strongly second this.
My experience is that there is a huge service for the good modelers who engage
with the community to do incredible good... but modeling in a vacuum, away from
the implementation, and then just expecting the implementers to follow
directions works poorly.
I'd say that a far better activity for the long term health would be to plug
good model people into the places in the community where models are in
progress. Their wisdom as participants can be huge, but they need to
*participate*, not work off in a tower of UML.
Ed
On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner <michael at
gigaspaces.com<mailto:michael at gigaspaces.com>> wrote:
... on the other hand, what does one do with a smooth cohesive model, if you
can't easily translate it to a data model? Without any intent to dive into a
debate about whether the example is right or not ... we have an ETSI NFV VNF
UML model ... and we cannot translate it into any data model - it takes manual
work. The other issue is sort of the reverse - i.e. you don't actually KNOW
that the UML model is right, until you implement it. And it is difficult to
implement it, when you don't have the automatic translation tools. So you end
up building an ideal model, but you don't know if it works ... until you have
the right translation tools. How long is one to wait ... instead of
implementing and iterating?
Like with any other project, it really comes down to a schedule, and knowing
what you want to achieve within that schedule.
Best,
Michael
On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom <brian.hedstrom at
oamtechnologies.com<mailto:brian.hedstrom at oamtechnologies.com>> wrote:
While the tools are maturing and advancing, if we choose to close that door
now, there's no cohesive UML Common Information Model for ONAP. Consequently,
we would lack a protocol agnostic information model and when the next cool data
modeling language or encoding scheme comes out, we have to start again with
working backward. Another key benefit is that UML is much easier to comprehend
due to it's graphical diagram nature, versus needing to understand a data
modeling language and/or data encoding mechanism.
Consensus can be made on class diagrams for example, then translation to a data
modeling language can be easily done by hand or by the emerging tools (see my
previous email with the links).
On Mon, Apr 24, 2017 at 12:29 PM, Michael Brenner <michael at
gigaspaces.com<mailto:michael at gigaspaces.com>> wrote:
Hi all,
I actually tend to agree with Ed. While it may be an ideal approach in theory,
tools for automatic generation from UML to Yang, or other modeling languages
for that matter are improving, they are still too far from perfect, and require
a lot of hand-holding so-to-speak, and as a result - too many headaches. We may
be mired in tool debugging, instead on progressing on ONAP.
Michael
From: Ash Young <ash at yunify.org<mailto:[email protected]>>
Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday
May 5th
Date: April 24, 2017 at 10:09:22 AM PDT
To: Ed Warnicke <hagbard at gmail.com<mailto:hagbard at gmail.com>>, Brian
Hedstrom <brian.hedstrom at oamtechnologies.com<mailto:brian.hedstrom at
oamtechnologies.com>>
Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana at research.att.com<mailto:rjana at
research.att.com>>, onap-discuss <onap-discuss at
lists.onap.org<mailto:onap-discuss at lists.onap.org>>, onap-tsc <onap-tsc at
lists.onap.org<mailto:onap-tsc at lists.onap.org>>
I'm actually in agreement with Brian on approach and tool. So much work has
been going on here that I really don't want to see us go backwards by thinking
Yang solves everything.
Ash
Sent from my iPhone
On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard at gmail.com<mailto:hagbard at
gmail.com>> wrote:
I love UML in a variety of contexts, but for expressing things that are
destined to be expressed in yang, or for creating things to be rendered to
yang, in my experience its been a very poor fit.
Ed
On Mon, Apr 24, 2017 at 9:41 AM, Brian Hedstrom <brian.hedstrom at
oamtechnologies.com<mailto:brian.hedstrom at oamtechnologies.com>> wrote:
The way to put all these different data models under a single umbrella is to
create a UML<https://en.wikipedia.org/wiki/Unified_Modeling_Language>
Information Model using Eclipse/Papyrus (as an open source tool).
Unified Modeling Language (UML) is a standard syntax for describing the
architectural design of a system
? Object Management Group (OMG) & ISO standard
? Originated from object-oriented software development methods
UML includes many diagrams types to graphically represent parts of a system?s
model, including
? Structural Views: The static nature of the system using objects,
attributes and relationships (e.g., information or components that must be
present in the system). This includes class diagrams and component diagrams.
? Behavioral: The dynamic nature of the system through collaboration of
objects and state changes (e.g., activities performed by the system). This
includes use case diagrams, sequence diagrams, state machines.
UML is protocol agnostic and therefore these "Information Models" are protocol
agnostic.
UML models can then be transformed into protocol specific data models such as
YANG, XML, SMIv2, etc.
Creating a UML Information Model allows data cohesion across the various
interfaces in the system. Using Interface
Realizations<http://www.uml-diagrams.org/realization.html>, specific interfaces
can be modeled. In fact, an interface Information Model could be transformed
into multiple data models to support multiple management protocols.
Therefore, the focus first is on building a UML Information Model, then once
that's approved by the organization, then data models and encodings can be
generated based on the chosen interface protocols.
Thanks,
Brian
On Sun, Apr 23, 2017 at 5:13 AM, <zhao.huabing at
zte.com.cn<mailto:zhao.huabing at zte.com.cn>> wrote:
Hi Brijesh,
You brought up a great topic, we may need to converge at the same aspect, but
for different aspects, there are different modelling languages which can better
meet the specific requirement of that aspect, and they are very complementary.
For example, TOSCA(Heat is another, come with openstack) is a good choice for
the topology modelling of cloud application , YANG can be used for the
configuration model( normally using for L2 L3, can be used for L4-L7 as well),
and BPMN is good at workflow orchestration.
It's difficult to put all these different modelling capabilities in a single
data model or using an unique DSL, and we don't need to. But It's possible to
make them work together smoothly under a unified umbrella system to accomplish
the automated close loop and I'm glad to see ONAP has already make a very good
start at that job.
Thanks,
Huabing
????
???: BrijeshKhandelwal;
???:GILBERT, MAZIN E (MAZIN E); denghui (L); JANA,RITTWIK (RITTWIK);
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>; onap-tsc
at lists.onap.org<mailto:onap-tsc at lists.onap.org>;
??: 2017-04-22 11:56:56
??:Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th
Greetings,
Adding some thoughts on information model:
Orchestration need to interoperate among different interfaces, which in turn
need to deal with very different payloads in form of YAML, YANG, JSON etc.
There will be lots of data processing among these models to process complete
service. Handling these templates in orchestrator will impose limitations on
capability and performance of orchestrator.
So, there should have standardized data model for smooth processing among
orchestration steps.
Probably first time, orchestration is composing 3 different worlds of Network,
Infra, IT, with different tunes of YANG, YAML, JSON/XML.
Is there a play to develop standardized data models for orchestration, which
will meet needs of each area? Is TOSCA sufficient? Or need some extended JSON
data models?
-Brijesh
From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at
lists.onap.org> [mailto:onap-tsc-bounces at
lists.onap.org<mailto:[email protected]>] On Behalf Of GILBERT,
MAZIN E (MAZIN E)
Sent: Thursday, April 20, 2017 8:30 AM
To: denghui (L); JANA, RITTWIK (RITTWIK)
Cc: onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>;
onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>
Subject: Re: [onap-tsc] Modelling discussion on Friday May 5th
Rittwik, Deng,
This is great. Thank you for taking the lead.
I realize the focus is on TOSCA and parsers. Wonderful!
I want to take you one level higher to start by discussing
what the framework look like for the information model. Perhaps invite folks
who have
operational experience. Then start describing the differernt
data models and how TOSCA plays a role in driving service chaining and micro
services
(like analytics, data collections, etc).
It would be great if the outcome of this mini session to
be a recommendation position/paper or a proposal for a project.
Mazin
On Apr 20, 2017, at 4:34 AM, denghui (L) <denghui12 at
huawei.com<mailto:denghui12 at huawei.com>> wrote:
Hello all
We are happy to let you know that we are hosting a modeling session on Friday,
May 5th, AT&T Lab.
9:00-10:30 Shitao moderate: TOSCA NFV Profile
10:30-12:00 Rittwik moderate: AT&T Parser
13:30-16:00 DengHui moderate: Modelling & Opendeployment
Please kindly help to let us know if you are interested in joining us, so that
we can book a proper meeting room for our discussion
Best regards,
Rittwik & DENG Hui
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HRoKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA&s=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 at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss
--
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
oamtechnologyconsulting.com<http://oamtechnologyconsulting.com>
brian.hedstrom at oamtechnologies.com<mailto:brian.hedstrom at
oamtechnologies.com>
720-470-7091<tel:(720)%20470-7091>
_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/7b087736/attachment.html>
