Tal, I was actually referring that, this view point was presented by you during the call and I second that. Now coming to the points raised on anti-cloud-native, IMHO cloud native doesn't have to be related with intelligence of the infrastructure. All it needs is to run anywhere without having legacy baggage and should fit into the description of "use-and-throw" . aka flexibility to introduce change without affecting the rest of the factory. Separating controllers from orchestrators exactly alludes such flexibility, which is much needed in operator environment.
Another reason why I bend towards BPMN is because it is a gigantic shell script, using which I can attain almost anything in any way I want. Whereas using TOSCA for orchestration constrain me with its limited primitives and extending the same would then call out for a proprietary version, thereby losing its "standard" mask. E2E TOSCA is an orchestration nirvana that even I'm dreaming of, provided if industry can derive a tosca_simple_profile_for_network_services.yaml . With regards to your point on "all your resources should have to be modelled in TOSCA & BPMN", if you look today, TOSCA is almost there to describe a network service, except for a well defined baseline of telco workflows. All it has is a list of primitives for cloud workflows and policies to enforce on the nodes. If we bridge this particular gap ( here in this case using BPMN ), then IMHO, TOSCA can successfully express all that is needed for a network service ( be it ETSI or ONAP or any other definition of service ). I would completely agree with your intent on making ONAP's SO flexible, but I would also like to point out that, IMHO ONAP's SO should be generic enough to create any network service with any workflow possible and here is one way of potentially achieving it in near term, considering present architecture. BR, Viswa <http://www.verizon.com> Viswanath Kumar Skand Priya Senior Architect Technology, Architecture & Planning On Fri, Jul 27, 2018 at 9:01 PM Tal Liron <tli...@redhat.com> wrote: > Thanks, Viswa. > > I just want to point out that the separation of orchestration from > controllers is not exactly my view. It's what we inherit from ETSI MANO > architecture, which has the noble goal of avoiding vendor lock-in. But it > comes at the huge cost of having to provide the glue between the layers, > and as we know the devil is in the details. Things get hairy quickly in > handling the specifics of lifecycle, data flows, telemetry, etc. An even > bigger cost, I think, is architectural. The "VNFM" is at the bottom of this > pyramid, a slave of the controllers. And so this top-down approach has no > room for intelligence baked into the infrastructure, and thud is > essentially anti-cloud-native. > > All this to say is that you *could* flatten the architecture. You *could* > potentially skip the controllers. You *could* have the entire deployment > modeled in TOSCA at the SO level, from the highest level of the service > chain and forwarding graph to the lowest level of mounting volumes on VMs > or defining ingress filters on Kubernetes pods. Your BPM solution would > then work directly against the infrastructure: fewer moving parts, fewer > things that can go wrong, etc. And it's very attractive in terms of having > the full picture and full control in one place. But it does mean that all > your resources would have to be modeled in TOSCA and BPMN, with wrappers > and adapters for a host of legacy technologies. The flip side that it's > also attractive to keep SO more pure and abstract and delegate the heavy > lifting to controllers. So, my personal opinion is neither here nor there, > I can see pros and cons to both approaches. > > TOSCA is good for us because it doesn't have an opinion about any of the > above. It's a BYOO ("bring your own orchestrator") situation. So, while > some operators might choose to use a "full stack" ONAP with SO plus VF-C, > App-C, and SDN-C, others might remix and bridge to other orchestration > environments that might not match the ETSI MANO model (e.g. working > directly against existing systems). On the side of the coin, BPM is good > for us because it's an open platform that can host the glue. It also > doesn't have a strong opinion about what any particular task or event does. > > In summary, what I tried to show in the demo is that this solution is > systematic rather than specific to any standardized models. I would like to > think that our goal in SO is flexibility: to be able to integrate fully > with the rest of ONAP, but also to allow for extensibility and integration > into existing platform investments and upcoming innovations. The next step > from this demo, as Seshu pointed out, would be to "bring your own > orchestrator". In this case, SO and the rest of ONAP. :) > > On Fri, Jul 27, 2018 at 6:28 AM Viswanath V Kumar Skand Priya < > viswanath.kumarskandpr...@verizon.com> wrote: > >> Dear All / SO team, >> >> During last SO call, I was caught inbetween 2 calls and wan't able to >> participate in SO call, was largely in hearing mode. I would like to add >> few points esp on the perspectives raised by Seshu ( reuse existing BPMN >> and do something about it ) & Alex ( adding HEAT / TOSCA backend for >> puccini ). >> >> One of the motivation behind this PoC ( atleast for me ) is to bridge gap >> between BPMN driven orchestration ( imperative style ) Vs TOSCA driven >> orchestration ( declarative style ). It is also important to note that, >> both styles has its own merits / demerits and both are suitable for >> specific set of use-cases. However in a typical service provider landscape, >> esp with the advent of NFV, the boundary between network orchestration & IT >> orchestration is becoming more fuzzy. We would normally need the >> flexibility of doing both styles. >> >> IMHO TOSCA is well suited for "expressing" what you want to do and what >> steps you want to take in doing that thing. However BPMN is really suited >> to actually "do" that orchestration. In current ONAP story ( where we don't >> have E2E TOSCA ), if I want to create a network service with a specific >> work flow, I have to "design a BPMN" for my case and then tie it with the >> engine. Though one can argue that, BPMNs are resuable, they are already >> abstract , they can be tied / chained with each other etc, practically it >> is still a complex process. TOSCA on other hands helps us to define what we >> want in more flexible & extendable way. So the idea here is to express what >> you want to do in TOSCA and execute it via BPMN. Thereby we get best of >> both worlds, with minimal impact to existing architecture. >> >> Now coming to the perspectives : >> >> - Re-use existing BPMN : Like I quoted above, the idea is to generate >> a BPMN flow dynamically from input TOSCA. This can be further refined to >> hook up with existing BPMN if it makes sense. The crux of this idea is to >> let the designer work completely in TOSCA mode even for workflows and then >> share the same in standard format for future purposes. >> - Having HEAT / TOSCA backend : I second Tal's view on this one. IMHO >> SO shouldn't be coupled with controller logic and SO's core logic should >> be >> based on BPMN. It is the BPMN engine which is at the heart of SO, which is >> making SO as a SO. Addition of new controller logic ( HEAT / any other >> format ) should follow existing adapter logic in SO, thereby it is >> extendable & scalable. This idea / PoC is actually providing a "friendly" >> wrapper on top of BPMN. that's it. >> >> Hope this sets the stage for future discussions on this topic. >> >> @Tal Liron <tli...@redhat.com> : It was a great show ! >> >> BR, >> Viswa >> >> <http://www.verizon.com> >> >> Viswanath Kumar Skand Priya >> Senior Architect >> Technology, Architecture & Planning >> >> >> >> On Thu, Jul 26, 2018 at 6:39 PM Steve Smokowski <ss8...@att.com> wrote: >> >>> Thank you for the readme >>> >>> >>> >>> -Steve >>> >>> >>> >>> >>> >>> *From: *<onap-discuss@lists.onap.org> on behalf of Tal Liron < >>> tli...@redhat.com> >>> *Reply-To: *"onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, >>> "tli...@redhat.com" <tli...@redhat.com> >>> *Date: *Thursday, July 26, 2018 at 9:07 AM >>> *To: *onap-discuss <onap-discuss@lists.onap.org> >>> *Subject: *Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018 >>> >>> >>> >>> Hi Steve, >>> >>> >>> >>> At your request I wrote a detailed README describing the solution and >>> the example: https://github.com/tliron/puccini-bpmn/ >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=wl1FD1fND7cuPeOEzE0FYxXfWxXz4hQcW_2AWtLRQdA&e=> >>> >>> >>> >>> For convenience, I will reproduce it here: >>> Features >>> >>> The imports directory has everything needed to generate BPMN from >>> TOSCA. Specifically there is bpmn.yaml >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_blob_master_imports_bpmn.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=dNdhlhIFjwpk0aq_f8qmQwtK36nT7UKlnz8_Buf8VCU&e=>, >>> which has the type information and in turn imports bpmn.js >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_blob_master_imports_bpmn.js&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=VdPzf1BX7bl-4ZxS7AMZr4PzzMsiuH0fg6bg8tJg31o&e=>, >>> which is the JavaScript code to generate BPMN. >>> >>> Two TOSCA features (introduced in TOSCA 1.1) are supported: >>> Workflows >>> >>> TOSCA declarative workflows are translated into BPMN processes. Because >>> a TOSCA workflow is essentially a graph of steps with sequential and >>> parallel sections, in BPMN we must represent the graph using parallel >>> gateways, diverging or converging as the case may be, as well as >>> conditional gateways to represent step success or failure. The JavaScript >>> analyzes the graph and inserts the appropriate gateways between the steps. >>> >>> Each step in TOSCA comprises zero or more activities that should happen >>> in sequence. In BPMN, all the activities in the step become a single >>> scriptTask entity. For now, we create a script made of pseudo-code that >>> calls these activities. A complete solution would require a BPM >>> orchestration environment and real code that would actually call node >>> instances deployed in a cloud. >>> >>> Once the BPMN process is imported into BPM software, you may include >>> this process as a sub-process within other BPM processes. The workflow may >>> or may not hand control back to another sub-process, so that it may or may >>> not be a continuation of a control loop. >>> Policies and Policy Triggers >>> >>> Policy triggers are also translated into BPMN processes. Because the >>> trigger must be executed from within an orchestrator on node instances >>> deployed in a cloud, within configurable time intervals or schedules, this >>> BPM process essentially hands over control of the loop to the orchestrator. >>> By launching a new sub-process when triggered, control is handed back to >>> the business process: an open loop. >>> >>> A single scriptTask entity is created for each target node of the >>> policy, and all are executed in parallel using diverging/converging >>> parallel gateways. A conditional gateway at the convergence is used to >>> launch a new sub-process if any of the tasks succeed. Again, the script is >>> made of pseudo-code that would call these operations within a BPM >>> orchestration environment. >>> Example >>> >>> Included is an example TOSCA service template, open-loop.yaml >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_blob_master_open-2Dloop.yaml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=iFiYk9ow9wzmmdlb6vlHRxxebiWlYuh81k74D7Y7JJo&e=>. >>> This example demonstrates an open loop policy, notify_on_high_load, >>> which has a trigger that runs an operation to get the CPU load on Compute >>> nodes. If this operation returns true then a BPM process named >>> NotifyUser would be launched. >>> >>> Also included is a TOSCA workflow named backup, which comprises a step >>> graph that calls an operation on an interface while making sure to set node >>> states, notify on failure, etc. This generated BPMN process can be executed >>> on its own, or included as a sub-process within larger business processes. >>> Because it does not hand control back to any other process when done, it >>> represents an end event within a control loop. >>> >>> We've already included sample output of this example in open-loop.bpmn2 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_blob_master_open-2Dloop.bpmn2&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=NrBOWJ3QNr7UKdyvZrEe3PCrzZBRve65REH0-SnF72A&e=> >>> . >>> >>> To recreate the output, run this command (tested with Puccini 0.2): >>> >>> puccini-tosca compile open-loop.yaml | puccini-js exec bpmn -o >>> open-loop.bpmn2 >>> >>> Also included is open-loop-design.bpmn2 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini-2Dbpmn_blob_master_open-2Dloop-2Ddesign.bpmn2&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=N0Wa3kMB5uCAs3nmwepI_HlMKCoT7GHTti0B3U4reEc&e=>, >>> which is the same file with added diagram information so that it would >>> appear more nicely in a BPMN GUI. We used the Eclipse BPMN2 modeler >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_bpmn2-2Dmodeler_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=SJl3qOG7SyLszHL6Ph4dGgKvZd43z7mzpHB8RQ-FwT8&e=> >>> to edit the diagram. >>> >>> You can import either file into your BPM software. Tested with jBPM >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jbpm.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=shs6nPzThSiGJml9VXN0Eg&m=JzO-UjYTbJGUMdAp-GBJsvFFs6ShpUxOx1OcnoUcxyA&s=W1qHS9fU6rfTyZgCQIfd6G0KXepK18Hxj3t4z-1bc1s&e=> >>> 7.8.0. >>> >>> >>> >>> On Thu, Jul 26, 2018 at 6:51 AM Steve Smokowski <ss8...@att.com> wrote: >>> >>> Is there a readme or walkthrough of how we can reproduce the demo >>> shown? Or can you share the command used to take Puccini and have it >>> output the bpmn? >>> >>> >>> >>> It appears to be something like >>> >>> >>> >>> -Parse CSAR using Puccini >>> >>> -Output to Clout >>> >>> -Utilize Clout output to the javascript file to transform to bpmn >>> >>> >>> >>> >>> >>> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11486): https://lists.onap.org/g/onap-discuss/message/11486 Mute This Topic: https://lists.onap.org/mt/23830970/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
