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 <https://coreos.com/blog/introducing-operator-framework>" 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 TOSCA's intent, but it was missing such an intermediary format. Perhaps Clout can fill in this gap. Workflows are important, but so is telemetry. Domain-specific models can be used for that, too. What makes YANG so great is exactly that it allows you to model for domain-specific needs. TOSCA has the potential do all that and a lot more. > > - 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. > > Of course Kubernetes has its own internal YAML (or JSON) specs (that are in a state of flux). Istio adds more. And there's Heat for OpenStack. And well-documented APIs for each. Of course you can and should use the native technology for your platform. TOSCA does not have to change that. (I'm arguing exactly that it *shouldn't* if it's to succeed.) The point is not to replace native specifications, but to provide a common grammar and tool chain for working with them. A common language does not magically smooth away the differences between platforms, but it can help you manage those differences intelligently.
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
