Re: [onap-tsc] [E] [onap-discuss] TOSCA on Kubernetes: Puccini

[Tal Liron]

Thank you, Kumar, for taking a look and for the good questions. I'll
respond with big wall-of-text answers. :)

>
>- As you had rightly mentioned in your AriaTosca message in
>mailinglist, ONAP has already got handful of parsers, including very own
>aria and it is not fully integrated with SO yet ( please correct me if I'm
>wrong ). What unique advantages would puccini bring, apart from being yet
>another, fresh, tosca 1.1 compliant, standalone, golang-js-based parser ?
>I'm not debating the arguments that you made on the aria-mailing list, am
>just trying to understand your argument on how it could benefit ONAP in
>particular?
>
> I would frame this question even more broadly: Why does ONAP need TOSCA at
all?

The current uses of TOSCA in ONAP don't make much sense to me. We're just
using it as a place to dump ETSI descriptor properties. Packaging in CSAR
is not interesting: it's just a ZIP file. We could have just as easily
packaged VNFs in a ZIP file with a few YAML descriptor files of the agreed
upon attributes and without any of the TOSCA parsing overhead. (I imagine
that's what many ONAP engineers would have preferred.)

But TOSCA, if used as fully intended, has the potential to allow
cloud-native VNFs to more fully cooperate with ONAP. "Cloud native" means
that they can manage their own lifecycle, but by exposing their internals
to the high-level orchestrator (ONAP) they can delegate some control to the
orchestrator and provide better visibility.

VNFs know themselves best. They know what they need to do in order to scale
and heal. They know what metrics make sense for their workloads. All these
details are very implementation-specific, but TOSCA provides a general
grammar for describing these things, including custom configurable policies
for adaptive behavior. The idea is that neither orchestrator nor VNF is a
"black box", but still we let each component do what it does best.

For TOSCA to live up to its potential it has to be used by and useful for
VNFs. To be useful, it must interact with the cloud-native domain. And
that's always implementation-specific. As I have argued for a long time:
the TOSCA grammar is good, the TOSCA normative types—not so good. The key
to making TOSCA useful is to model the infrastructure directly and
precisely. Instead of a generic "Compute" type, Puccini provides node,
capability, data, and policy types that model the Kubernetes platform, so a
VNF can use TOSCA to deploy itself with full specificity. TOSCA should not
be overhead, but a solution: a desirable solution for both the VNF and for
the orchestrator.

By the way, cloud-native Kubernetes is not just about YAML specs. In my
other talk in Beijing (I'm planning two) I will introduce the growing
necessity for writing custom "operators
" for Kubernetes,
to manage the specialized, non-generic lifecycle needs. Specifically, I
will show how Clearwater can scale its SIP routers/edge-proxies on its own
terms by embedding operators into Kubernetes. This is not something that
Kubernetes can do out-of-the-box, because it's highly application-specific.
All of this can be modeled in a higher level with TOSCA, so it can be
comprehensible by both the VNF and the orchestrator.

>
>- Since today, SO is predominantly BPMN driven, how much effort does
>it take to come up with BPMN backend ? Is it feasible ?
>
> It is entirely feasible. Puccini's innovation here is in providing an
intermediary format (Clout). TOSCA compiles to Clout, and then Clout can be
processed by a workflow engine. Again, as I keep emphasizing, the key to
making such solutions work well is domain-specific modeling. Once you free
yourself from being locked into generic types you can really make TOSCA do
a lot for you. The TOSCA service templates should include types
(interfaces, policies) that would make sense specifically for a your custom
BPMN workflow environment. Moreover, the Clout can contain simple
JavaScript to automagically spit out the format that you need.

TOSCA is very good at this because it allows you to inherit/compose
existing types. So, a VNF vendor can provide a detailed model of its
components (and their internal requirements-and-capabilities). To interact
with BPMN properly it would be possible to "import" both sets of types and
model and configure them together. There's always on-boarding work to be
done, but this could allow you to work with the VNF instead of against it.

Clout also attempts to solve the "day 2" problem. TOSCA is only your day 1
model: after you deploy a VNF, it is expected that it will change
(scale/heal), making the original TOSCA no longer relevant. But, that Clout
has all the attributes and functions compiled into it. So all you need to
do is read from the live deployment and update your existing Clout with the
updated topology and attributes. And your tool chain will continue to work
as usual. This has always been part of 

Re: [onap-tsc] [E] [onap-discuss] TOSCA on Kubernetes: Puccini

[Kumar Skand Priya, Viswanath V via ONAP-TSC]

Hi Tal,

I had a glance of puccini and am yet to explore more by getting my hands
dirty. But then I have following questions, based on my glance.

   - As you had rightly mentioned in your AriaTosca message in mailinglist,
   ONAP has already got handful of parsers, including very own aria and it is
   not fully integrated with SO yet ( please correct me if I'm wrong ). What
   unique advantages would puccini bring, apart from being yet another, fresh,
   tosca 1.1 compliant, standalone, golang-js-based parser ? I'm not debating
   the arguments that you made on the aria-mailing list, am just trying to
   understand your argument on how it could benefit ONAP in particular?
   - Since today, SO is predominantly BPMN driven, how much effort does it
   take to come up with BPMN backend ? Is it feasible ?
   - IMHO Kubern8s space is already (kinda) standardized and deployment of
   ONAP components may not need another language. Personally I am interested
   to know if puccini would ease the job of parsing SOL 001 compliant NSDs &
   VNFDs and seamlessly translate to ONAP specific workflows ( BPMN, DAGs etc
   ) with minimum efforts.

Looking forward to your talk at Beijing summit.

BR,
Viswa




Viswanath Kumar Skand Priya
Architect
Technology, Architecture & Planning


On Tue, Jun 12, 2018 at 10:42 PM, Tal Liron  wrote:

> Hi folks,
>
> I'm happy to finally reveal a project I've been working on for a few
> months:
>
> https://github.com/tliron/puccini
> 
>
> The gist of Puccini:
>
> 1) Very fast and full-featured stateless TOSCA compiler
> 2) Targets Kubernetes directly (more targets to come)
> 3) Finally introduces an "intermediary format" for TOSCA, called "Clout"
>
> For ONAP, I humbly suggest that it could provide 1) a way to deploy
> containerized VNFs while staying entirely in TOSCA and CSAR, and 2) a
> possible alternative to Helm in order to minimize the number of modeling
> languages in the project. Or neither! This is not an official proposal,
> just the beginning of a discussion that with hopefully expand our
> imagination on ways to solve some thorny architectural problems.
>
> I'll be presenting it in Beijing next week, but will be happy to answer
> questions here, too.
>
> Also, to be clear: this is *not* an official or endorsed Red Hat project.
>
> For a comparison with AriaTosca, see this message
> 
> .
>
> ___
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=
> udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=9F3pNUkzjE-
> 2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ=
> MJRff2sguAcB41OPSRvEKIOauXFg2qB1GXlB6-k40Yg=gsMHRQj-
> oDHwMcitvir9lRjevH7VUwkUECsh5qCiSeQ=
>
>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc