Thanks, all good points, Viswa.
Just to clarify my rather glib comment about "intelligence" and cloud
native applications -- my intention was to underscore VNFs that are able to
intelligently manage themselves, specifically their own lifecycle and
resource use. Such intelligent cloud native VNFs can scale out on their own
(with parameters defined by policy) when they detect a need. They can heal
themselves when things go wrong. Some of this involves reconfiguration, but
some of this involves provisioning or borrowing new cloud resources. They
can (and should) do all this independently without necessarily having to go
through upper levels of orchestration. Within traditional cloud it's
already quite common to see VNFs being able to spin up new VMs ("VDUs") on
their own using OpenStack or other APIs, and with Kubernetes it's going to
be much more common (see: Kubernetes operators).
My point is just to emphasize that top-down approach to orchestration is
sure to have blind spots as VNFs embrace such cloud native approaches more
and more. So, BPM is great for establishing centralized control, but I want
to make sure that we remember that control is distributed both horizontally
and vertically in the cloud. In other words, "orchestration" might not
always be the best metaphoric paradigm: it's not always about a conductor
standing in front of an orchestra all playing the same music, often it's
more like an air traffic control tower coordinating -- that's the key word!
-- between airplanes, each having a pilot making independent decisions
based on policies of that airline as well as national and international
regulations.
ONAP can't embrace the future all it once, but at least we can make sure
that we don't make architectural decisions that would make it impossible to
evolve.
Have a great weekend everyone. :)
On Fri, Jul 27, 2018 at 11:33 AM Viswanath V Kumar Skand Priya <
viswanath.kumarskandpr...@verizon.com> wrote:
> 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 (#11488): https://lists.onap.org/g/onap-discuss/message/11488
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]
-=-=-=-=-=-=-=-=-=-=-=-
