The latest release of Puccini <https://github.com/tliron/puccini>, 0.6, features many big fixes, support for "quirks <https://github.com/tliron/puccini/blob/master/tosca/parser/QUIRKS.md>" (varying behavior according to varying interpretations of gaps in the TOSCA spec), but probably most intriguing is support for the HOT (Heat Orchestration Template) language in addition to TOSCA 1.2 and TOSCA 1.1.
HOT? What? Why? First, a quick recap of what Puccini does. It compiles TOSCA into an intermediary form, called Clout, which is a normalized, flattened version of the template described by TOSCA. It is still a "template" at this stage, rather than an instantiated deployment, but it contains JavaScript scriptlets to do the work of actually instantiating the template into a cloud deployment. This work usually means integrating with an orchestrator, such as Ansible or Kubernetes. In Puccini you "bring your own orchestrator" (BYOO). (And, yes, Kubernetes is best understood as an orchestrator in this case, not an infrastructure manager.) If you're just doing a "day 1" installation then you won't even notice this intermediary form. It comes to play in "day 2" topology-changing toolchains, such as scaling and healing, while maintaining the authored rules (requirements-and-capabilities), policies, and boundaries expressed in TOSCA. The scriptlets will be re-run by the toolchain to dynamically re-orchestrate the updated topology. Among other profiles, Puccini comes with an initial OpenStack profile, which intends to model the resources similarly to HOT <https://docs.openstack.org/heat/rocky/template_guide/openstack.html>, but with the much enhanced object-oriented, strictly-typed grammar of TOSCA. The "bring your own orchestrator" approach means that you don't need Heat: the embedded scriptlet outputs Ansible playbooks instead to deploy your template. The default end result is the same, however Ansible has some advantages over Heat, specifically opening the door to fine-grained custom integrations with your orchestration environment, such as OSS/BSS, security audits, external policy frameworks, etc. For all its strengths, Heat is very much tied to OpenStack and cannot so easily interact with other systems. So, where does HOT fit in? Puccini can now compile HOT in the same way it compiles TOSCA with the OpenStack profile, with the resulting Clout being indistinguishable if we assume the same resources and topology. This feature was a classic case of "low-hanging fruit", relatively easy to implement due to HOT's grammar being so similar to TOSCA's while being vastly simpler (HOT has no type system and only a handful of entities). There was very little code that needed to be added to Puccini. (It would likewise be relatively easy to add support for the Cloudify DSL if there's interest. The basic compilation engine in Puccini is designed for any TOSCA-like language or dialect.) Understanding the "why" might be less immediately obvious. Wouldn't you be using Puccini specifically because it's a TOSCA compiler? Well, possibly, but you might also be choosing it for its orchestration integrations. Using HOT with Puccini gives you the same Ansible playbooks and the same "day 2" opportunities as it would with TOSCA and the OpenStack profile. Generally speaking, if you're using Puccini then TOSCA is a better choice than HOT for new OpenStack templating projects. But if you are already invested in Heat, this new feature can provide a less jarring migration path towards using Ansible and other orchestrators. Which orchestrators, exactly? In ONAP's world it could be VF-C, App-C, Multi-Cloud, or existing VIM investments by telcos. But you might already guess which orchestrator is on my mind. In my "Let's Move Everything to Kubernetes" presentation I argued that we could soon be able to use Kubernetes (with KubeVirt, Multus, and other additions) as an orchestrator instead of Heat, allowing us to support the most commonly used OpenStack resources -- Nova servers, Neutron networks, Mistral workflows -- without actually requiring OpenStack. Imagine taking an existing Heat template for a VNF and deploying it in a single command directly to Kubernetes. We're not quite there yet, but the pieces are coming together. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15848): https://lists.onap.org/g/onap-discuss/message/15848 Mute This Topic: https://lists.onap.org/mt/30213382/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
