I would like to add the following point which seems to be forgotten from the discussion. VNF packages are supposed to be put together by the VNF vendor. The VNF package will include the description of the VNF (let's refer to it as a VNFD), and all the accompanying artifacts (s/w images, scripts to react to lifecycle events, etc). Vendors can only be held responsible when that VNF package is processed as intended - including all the artifacts. TOSCA gives a VNF vendor the ability to both comply to, and rely to this "handshake" between vendor and service provider. The vendor writes its own TOSCA service template that refers to the artifacts the vendor includes in the package, in ordert to express "the vendor's INTENT" about how its VNF is to be deployed and (lifecycle) managed. That is a contract between vendor and service provider. If one changes the service template or the artifacts provided by the vendor, the vendor can deby accountability for the way its VNF functions when deployed.
Now, let's look at the use of "external workflows" executed by a particular workflow engine, specified by name (BPMN, BPEL, etc), vs one un=specified (declarative). If we allow in the tOSCA service template to specify ANY workflow engine (and that is the path of your proposal), then the VNF vendor has the following options: 1. specify a declarative workflow (no particular workflow engine is specified). The vendor cares only that the workflow is executed (e.g. by the script it provided); it is opaque to the orchestrator, whio just has to execute the script. ANY orchestrator can do that, does not need to know how to interface with any external systems - or, if it has to, it is left to the implementation. 2. the other option is for the vendor to specifically indicate in the service template that the orchestrator must use BPMN or BPEL or some other workflow engine. First of all, that implies that the VNF vendor has created and tested its VNF using sich a workflow engine. I wonder how many VNF vendors will actually create their VNFs relying on BPMN or BPEL for executing its deployment and orchestration. I do not know a single vendor that does that - but perhaps we need to ask VNF vendors themselves, and include them in this discussion. More importantly though - imagine that vendor X indicates BPMN, vendor Y indicates BPEL, vsndor Z indicates Drules, vendor U indicates XACML, vendor V indicates "my preferred fantastic workflow engine that nobody else is using because it was invented by me, and attached as an artifact in the VNF package"). That case forces EVERY orchestrator to be capable of interactions with EVERY possible workflow engine out there, including some that it could have never anticipated. Very few, if any, orchestrators can keep up with such an implementation, because it is unheard of. Nobody would build it ... because nobody can guarantee that "if they build it, they (VNFs) will come". My point is that orchestrator's interaction with external entities, whether based on a standard spec or not, should be left to implementation, and not specified in a standard. Once you create in a standard such a precedent, it is difficult to not perpetually replicate it, because you cannot grant such lattitude for use case X (e.g. use of BPMN) but not to use case Y (e.g. BPEL), and then the floodgate is open for everyone to claim "precedence" and push their preferred external engine into the standard spec. And the poor standard guys have no standing to stop that, because they already allowed that once before. And poor orchestrator builders now have the choice of developing something 5 times more complex than may be needed, or held in non-compliance to standards. For practical reasons, may I ask any VNF vendors on this thread (e.g. Metaswitch) - would they consider including a specific artifact for BPMN and/or BPEL for their VNF install/un-install, instead of an opaque script and relying on the TOSCA orchestrator declarative model to decide what workflow engine (if any) to use? Best regards, Michael On Fri, May 12, 2017 at 6:45 AM, Michael Brenner <[email protected]> wrote: > Huabing, > > The way you propose it ... you might as well ask the question "why use > TOSCA at all"? This was one of my points in our discussion last Friday. > I cannot understand why one tries to cannibalize a good standard that was > purposefully defined for cloud workloads intent-driven deployment and > orchestration. TOSCA should be used as it was intended, and take advantage > of its characteristics, instead of twisted around to fit some existing > implementation. > > Best regards, > Michael > > > On Fri, May 12, 2017 at 3:39 AM, <[email protected]> wrote: > >> Hi Ranny, >> >> Thanks for your comments. >> >> >> It's an interesting use case, in my opinion, why not put all these >> activities into a BPMN workflow, including the creation of VNF, the IP >> config of the peer physical MME and the port config of the security group, >> the parameters exchange is supported between different BPMN task nodes. >> >> >> OPEN-O has a workflow design tool which can design Lifecycle Management >> workflows for a Network Service. The designer can design a BPMN task to >> call the operation of a tosca node, and an external service as well, >> including Catalog, Inventory(A&AI), NFV-O, VNFM, etc. So the parameters >> needed for a specific orchestration activity can get from either the BPMN >> task parameter or a service call to an external service. >> >> >> For this use case, if we put it in the context of OPEN-O, the creation >> request of VNF is passed to NFV-O by a BPMN task node, which creates VNF >> and returns the IP as an output parameter. The output parameter can be used >> as an input parameter of the next BPMN task node, which uses this parameter >> to config the physical MME, in turn, the output of this task can be passed >> to the next task to config the security group. The actual workflow may have >> more tasks, including the interactions with Catalog(get VNF Package) and >> Inventory(Update the service instance), etc. >> >> >> Furthermore, normally there're multiple nodes in a network service >> template, OPEN-O use parser to get all the nodes from service template and >> sort the nodes based on their topology dependency and then pass the nodes >> list to a BPMN loop. By this approach, we can see that BPMN is not an >> opposite of topology driven( aka declarative workflow), on the contrary, >> BPMN can complement and enhance declarative approach to include external >> service as well when needed. >> >> >> Thanks, >> >> Huabing >> >> >> Original Mail >> *Sender: * ＜[email protected]＞; >> *To: * ＜[email protected]＞; ＜[email protected]＞;zhaoh >> uabing10201488; >> *CC: * ＜[email protected]＞; ＜[email protected]＞; >> *Date: *2017/05/12 01:52 >> *Subject: **RE: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support >> proposalat OASIS TOSCA WG* >> >> >> 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:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Nati Shalom >> *Sent:* Thursday, May 11, 2017 6:41 AM >> *To:* Michael Brenner ＜[email protected]＞; Huabing Zhao ＜ >> [email protected]＞ >> *Cc:* onap-discuss ＜[email protected]＞; [email protected] >> *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 ＜[email protected]＞ >> 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, ＜[email protected]＞ 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 >> [email protected] >> https://lists.onap.org/mailman/listinfo/onap-discuss >> >> >> >> >> >> -- >> >> *Michael Brenner, **Chief Architect NFV* >> >> ------------------------------ >> >> M: +1-732-895-5772 <(732)%20895-5772> >> >> http://getcloudify.org >> <http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> >> >> @cloudifysource >> >> <https://twitter.com/CloudifySource> >> <https://www.linkedin.com/company-beta/17918192/> >> <https://github.com/cloudify-cosmo> >> <https://www.youtube.com/cloudifysource> >> >> >> >> >> >> >> <http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> >> >> >> >> _______________________________________________ >> ONAP-TSC mailing list >> [email protected] >> https://lists.onap.org/mailman/listinfo/onap-tsc >> >> >> >> > > > -- > Michael Brenner, Chief Architect NFV > ------------------------------ > 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://twitter.com/CloudifySource> > <https://www.linkedin.com/company-beta/17918192/> > <https://github.com/cloudify-cosmo> > <https://www.youtube.com/cloudifysource> > > <http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> > > -- Michael Brenner, Chief Architect NFV ------------------------------ 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://twitter.com/CloudifySource> <https://www.linkedin.com/company-beta/17918192/> <https://github.com/cloudify-cosmo> <https://www.youtube.com/cloudifysource> <http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar>
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
