Huabing,

I like your direction of giving concrete examples for possible implementation 
that you did in some other branch of this thread. Following that, could you 
please illustrate how the following scenario will be addressed with a BPMN 
workflow:

Let say I am deploying an EPC P-GW, and in that process I need to configure 
DIAMETER-peers on a physical MME so it can communicate with my newly created 
GW. So, after creating some server nodes, TOSCA will need to call an external 
BPMN workflow and pass as a parameter the IP address of one of the newly 
created server nodes. Also, after the workflow is completed, a port number is 
allocated for the DIAMETER session and it needs to be configured on a security 
group, so it needs to be passed back to TOSCA as a parameter. Could you 
elaborate on how this back and forth switch of control and information exchange 
could happen?

Thanks,

Ranny.

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Nati Shalom
Sent: Thursday, May 11, 2017 6:41 AM
To: Michael Brenner <mich...@gigaspaces.com>; Huabing Zhao 
<zhao.huab...@zte.com.cn>
Cc: onap-discuss <onap-disc...@lists.onap.org>; onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposal 
at OASIS TOSCA WG

"The proposal has been discussed in the OASIS TOSCA for a couple of weeks and 
most of the members agreed on it except the strong pushback from Michael of 
Gigaspaces."

Huabing et al

I wanted to ask that we will keep the discussion on a professional and not a 
personal level.

First i want to clarify what were discussing here right now is not a question 
of declarative vs impressive workflow as it is being coined for some reason.
What were really discussing is whether we use TOSCA as a configuration input or 
as a model that represent a live system and allow continues interaction with 
system through the model e.g. Model Driven.

So the discussion is wether ONAP orchestration should be truly model driven or 
not and not whether we should support declarative vs imperative workflow and 
whether that workflow should be written in BPMN or some other language.

There is also no real argument on whether you can or can't use BPMN as a 
workflow engine.  Intact if things done right we should't even care about it.

I think that we all agreed that an implementor can choose to run the workflow 
in what ever language or format he wishes and that should become a "black-box" 
from the Orchestrator perspective.

To allow this kind of flexibility i.e. allow the implementor to choose the 
workflow language that fits best to his needs we need to define a clear 
interface on how the execution get called and also how the state of the model 
get effected once that execution is completed.

That's what Michael is basically trying to say repetitively but unfortunately 
he's comment are being ignored.

Both Michael myself are more than happy to work with you or anyone else on the 
proposal for defining those interfaces assuming that we agree with the goal and 
scope toward a true Model Driven orchestration.

Speaking of a community process.
I would appreciate if you could respond to the questions that was raised here 
an on the OASIS discussion about the proposal in order that we could have a 
constructive dialogue and move forward.

Here is a summary of some of those questions that were left un answered:

1. What's in your proposal should be the effect on the model after the 
execution is completed?  (I assume that right now this is considered out of 
scope in the current proposal right?)

2. Your making assumption on what works for Telco vs Simple use cases. (This 
goes with the declarative vs imperative for some reason even though i'm not 
sure how the two are even related). Can you share on what basis are you making 
those assumptions?

3. If we agree to leave that the implementation of the workflow should be 
treated as a blackbox why do we need a specific specification proposal for BPMN 
?

Let's start with that.
As i mentioned we would be more than happy to work with you on those areas and 
put more clarity behind those items.

Nati S.








On Wed, May 10, 2017 at 9:03 AM Michael Brenner 
<mich...@gigaspaces.com<mailto:mich...@gigaspaces.com>> wrote:
Huabing,

I recognize the need in ONAP to support delegation in TOSCA to external 
workflow engines. I have said this repeatedly, and still am miss-interpreted.
This has nothing to do with backward compatibility to TOSCA 1.0, it only has to 
do with supporting "facts on the ground/existing implementations". We should 
get this agreed once for all, and it became obvious in ONAP's Friday modeling 
discussion.

It also became clear that some of these "facts-on-the-ground" use TOSCA in a 
limited way. This is OK, and I have no issue with that. I can support in TOSCA 
TC to find the right mechanism to delegate externally, but only if we do it in 
a way that is complete: that means we need to not only specify how to "get out 
of TOSCA" but also has to include how to "get back to TOSCA", and "what is the 
TOSCA orchestrator supposed to do after it delegates externally". I suggest we 
work jointly to resolve these issues.

Further, your claim that I am the only one opposing the half-way solution on 
the table is incorrect, and you know it. Luc Boutier in the TOSCA TC is also 
vehemently opposed, and partly at least for the same reasons as those quoted by 
me.

It would be great if we stop making unfounded claims in one community, by 
quoting only partially what happens in another community, and it would be 
better to focus joint energy to resolve the issue in a consistent and complete 
technical manner in the TOSCA TC. Please realize that you absolutely CANNOT 
resolve TOSCA TC discussions/debates in the ONAP community alone, and this is 
not the appropriate way for you to convince me to drop my opposition in TOSCA 
TC.
The right way to have me support this is by resolving the technical issues that 
I raised.

Best regards,
Michael

On Wed, May 10, 2017 at 3:16 AM, 
<zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn>> wrote:

Hi Amir and all,

Both OPEN-O and OpenECOMP have used TOSCA for service topology modelling and 
BPMN/BPEL for lifecycle management process modelling. After the merger, ONAP 
will inherit the existing codes from OPEN-O and OpenECOMP and continue to use 
BPMN/BPEL in SO/VF-C.

However, I noticed that TOSCA has removed the support for BPMN/BPEL in v1.1[1] 
which is recommended in the Topology and Orchestration Specification for Cloud 
Applications Version 1.0[2].

This incompatible change of TOSCA specification may cause unpredictable effects 
to existing opensource projects, in particular, the ONAP, which have already 
adopted BPMN as its lifecycle management process modelling.

To harmonize the opensource and standards, I am co-proposing a proposal[3] with 
Lingli(CMCC), Claude(AT&T) and Shitaoto(Huawei) to suggest OASIS TOSCA revert 
standard workflow DSLs support such as BPMN/BPEL in the next version of simple 
YAML specification.

The proposal has been discussed in the OASIS TOSCA for a couple of weeks and 
most of the members agreed on it except the strong pushback from Michael of 
Gigaspaces.

I think this proposal is for the best interest of ONAP community, so I'm 
writing this mail to solicit supports from Gigaspaces and all the other 
community members who are both in ONAP and OASIS TOSCA WG.



[1] 
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html

[2] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html

[3] 
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support-v-2017-04-25.pptx



Thanks,

Huabing



_______________________________________________
onap-discuss mailing list
onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss



--
Michael Brenner, Chief Architect NFV

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-27020792c3e94269b883d9a828be029f56c08986b2ab208a46143b169592c35a.png]

________________________________

M: +1-732-895-5772

http://getcloudify.org<http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar>

@cloudifysource

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]<https://twitter.com/CloudifySource>
  
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png]
 <https://www.linkedin.com/company-beta/17918192/>   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/6f7421bc5b9a93a0649735bbc8589b200c678bf08af9d7e0cebf1b3cffcdac94.png]
 <https://github.com/cloudify-cosmo>   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/4be4d1377f4c1afe70a25e78926b6aad4e0a4fb1d45a7727e31d5a807eb3aae7.png]
 <https://www.youtube.com/cloudifysource>



[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-218433c43f71db1180fd27884e3650b01b94c578c594b32c6f49c3daa3151366.png]<http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar>

_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org<mailto:ONAP-TSC@lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to