Hi Michael,
I'm glad that we have reached agreement on the necessity of the cooperation
between TOSCA and the standard workflow DSLs.
Actually we are not "changing" TOSCA but bringing back what had been supported
before the v1.1 workflow modification which make TOSCA completed.
TOSCA ideally should have both the topology model and the process model to
facilitate the orchestration, and NFV is an important greenfield for TOSCA in
Telecom industry, so if proces model is missing for general NFV use cases,
seems to me it is incompleted.
So the debate rasing out is should we limited TOSCA only on some specific use
cases which can be done by the declarative workflow/ internal imperative
workflow, or we want to embrace broader domain with more general use cases? I
believe the intention of TOSCA is the later one.
Thanks, Huabing
Original Mail
Sender: ＜[email protected]＞
To: zhaohuabing10201488
CC: ＜[email protected]＞ ＜[email protected]＞
＜[email protected]＞ ＜[email protected]＞
Date: 2017/04/28 02:05
Subject: Re: 答复：Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday
May 5th
Hi Huabing,
I think you still don't understand my main point - since you are trying to
convince me of something I already accept: the fact that certain workflows may
not be easily solvable "within TOSCA" and therefore need external workflow
engine help.
My main point is that in order to leverage those external workflow engines for
what they do best, we do not need to make changes to the TOSCA standard. But,
if we do decide that we want changes to the TOSCA standard, we should be
careful to provide changes that make the standard consistent/complete and
overall better, rather than weaker. The current proposal does not make the
TOSCA standard consistent/complete/better wrt workflows, but achieves rather
the contrary effect - allows for too many interpretations regarding the
"contract" between a TOSCA-consuming orchestrator and the external workflow
engine it delegates the work to. If we could solve all those issues before
pushing them into the TOSCA standard, I would have no objections.
Getting back to what you are trying to achieve - i.e. leverage BPEL/BPMN in
ONAP (like in Open-O, or otherwise) - this is a discussion to take place in
ONAP the same is true for a discussion of what the role of TOSCA is in ONAP.
I think we get into these debates here because we are conflating standards
approaches with implementations needs, and more often than not, complete
implementations/solutions should not be part of a standard, or at least not
part of the SAME standard. Standards are best when they have a clear boundary
of the domain they cover, and the smaller the domain, the more granular the
standard, and the better the standard.
Best regards,
Michael
On Thu, Apr 27, 2017 at 1:53 PM, ＜[email protected]＞ wrote:
Hi Michael,
As far as I know, besides GSO, NFVO also uses BPEL, I'm not aware of any use of
other workflow both .
The main reason is that they don't have the capability to support the OPENO use
case.
The declarative workflow is suitable for simple scenarios,but it can't meet
most of the requirements of Telecom cloud service, which is usually across
multiple data center and need interactions with entities outside of the TOSCA
service template.
For example, when carriers deploy the vCPE service for a residential
subscriber, the user plan vnf, such as VSTB, should be located in the data
center which is the most close to the user to minimize latency. To achieve
that, the workflow need to ask a placement service which know the resource and
geographic info of all the data centers to get the best placement location to
create the vnf.
It's a very common use case for NFV, Neither declarative workflow nor the
imperative workflow inside TOSCA can accomplish this job because obviously the
global placement service is an external service out of TOSCA template, so it
can't be invoked by the declarative or internal workflow of TOSCA. It can't be
implemented as a node operation as well because the node operation is provided
by vnf vendor, who have no idea of the Orchestration system components.
Thanks,
Huabing
原始邮件
发件人: MichaelBrenner
收件人:Lingli Deng
抄送:onap-discuss JANA,RITTWIK (RITTWIK) [email protected]
日期: 2017-04-27 00:58:12
主题:Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday May 5th
Lingli, all:
I though we are now discussing ONAP and how to improve it, and not Open-O?
Furthermore, ONAP is indeed using BPEL/BPMN workflows, but that is as part
of the MSO. MSO may decide to delegate certain portion of the orchestration to
a TOSCA-based orchestration engine, and what is delegated to such engine may
have to use its own internal/native workflows.
The real question here is: are we trying to leverage the best of all we have
available, or are we trying to keep replicating the status-quo forever.
Regardless of the answer, I find it that it is a very narrow perspective if we
only want to discuss workflows in the context of what was implemented initially
in Open-O or ECOMP, instead of opening a broader discussion of what makes sense
where in the overall architecture.
Best regards,
Michael
On Wed, Apr 26, 2017 at 2:10 AM, Lingli Deng ＜[email protected]＞
wrote:
Hi Michael,
You may consult your gigaspace's colleage, as my recollection, native workflow
proposed by gigaspaces was turned down by the consensus of the OPENO
community, we decided to use BPMN/BPEL type of workflow, you can also find out
the workflow in MSO /APPC of OPENCOMP are also using BPMN/DG
Thanks,
Lingli
From: [email protected]
[mailto:[email protected]] On Behalf Of Michael Brenner
Sent: 2017年4月26日 11:09
To: denghui (L) ＜[email protected]＞
Cc: [email protected] JANA, RITTWIK (RITTWIK) ＜[email protected]＞
[email protected]
Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th
But no TOSCA native workflows ... why?
Michael
On Tue, Apr 25, 2017 at 8:03 PM, denghui (L) ＜[email protected]＞ wrote:
Hi Michael,
Thanks for your suggestion, workflow is already covered in the Shitao’s
session, they will discuss
1) OPENCOMP Workflow
2) OPEN-O Workflow.
Best regards,
DENG Hui
From: Michael Brenner [mailto:[email protected]]
Sent: Friday, April 21, 2017 7:14 AM
To: Amir Levy
Cc: JANA, RITTWIK (RITTWIK) Nguyenphu, Thinh (Nokia - US/Irving) denghui (L)
[email protected] Nati Shalom [email protected]
Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th
I'll be happy to attend and take part in the discussion and would like to
suggest to add workflows to the agenda ...a topic which I offer to moderate.
Best regards,
Michael
On Apr 20, 2017 4:51 PM, "Amir Levy" ＜[email protected]＞ wrote:
Thanks DENG for leading this initiative.
I would love to share few quick links to prepare for this meeting:
We have a two parts video that provides TOSCA in practice training : Part 1:
https://www.youtube.com/watch?v=aMkqLI6o-58 and
https://www.youtube.com/watch?v=6xGmpi--7-A
And Michael Brenner for ETSI/NFV and TOSCA has recently drafted a in-depth
comparison between model-driven and task-driven workflows:
http://getcloudify.org/brochures/tosca-workflows-Apr-2017.pdf
— amir
[email protected] +1 408 916 8572
On Apr 20, 2017, at 10:29 AM, Nguyenphu, Thinh (Nokia - US/Irving)
＜[email protected]＞ wrote:
Hi Rittwik and DENG,
Is modeling discussion covering network service and VNF descriptors? Or it is
broader to cover all of the ONAP functions?
Yes, I am planning to attend.
Thinh
From: [email protected]
[mailto:[email protected]] On Behalf Of denghui (L)
Sent: Thursday, April 20, 2017 3:35 AM
To: denghui (L) ＜[email protected]＞ [email protected]
[email protected]
Cc: JANA, RITTWIK (RITTWIK) ＜[email protected]＞
Subject: [onap-discuss] Modelling discussion on Friday May 5th
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-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
--
Michael Brenner, Chief Architect NFV
--------------------------------------------------------------------------------
M: +1-732-895-5772
http://getcloudify.org
@cloudifysource
--
Michael Brenner, Chief Architect NFVM:
+1-732-895-5772http://getcloudify.org@cloudifysource
--
Michael Brenner, Chief Architect NFVM:
+1-732-895-5772http://getcloudify.org@cloudifysource_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
