Author: spzala
Source: Planet OpenStack

Recently I had a discussion with the team about the great progress we have made with Heat-Translator development and the vast potential that we have going forward. I would like to share some of that conversation with you.

TOSCA Parser
Our first topic of conversation was the TOSCA parser development and the incredible strides we have made since we were recently elevated from the StackForge project to an OpenStack project under the Heat program. The team has put in a lot of work to capture the recent changes in the TOSCA Simple Profile in YAML specification. Some of the ongoing efforts to add in new TOSCA support and update related functionality are enumerated below.

Networking: TOSCA specs has completed networking modeling and parser work is going on to provide support for networking node, related types used to describe logical network information, port definition and network endpoint capability with a single port or a complex endpoint with multiple ports.

Support for new TOSCA capabilities: New capabilities have been introduced in the recent revision of the current specification. Besides new networking endpoint capability, other major capabilities that need a new implementation include specialized database endpoint capability and TOSCA compute capabilities for operating system and scalability.

Cloud Service Archive (CSAR): The TOSCA CSAR is a container file. It typically includes a TOSCA service template containing reference to one or more file definitions of needed TOSCA base types as well as custom types and all artifacts that are required to deploy and manage lifecycle of the corresponding cloud application. The original CSAR specification, developed for the TOSCA XML specification, needs to be updated considering new features added in the ongoing TOSCA Simple Profile in YAML specification. The parser, which currently is tested with the YAML template, also needs to support CSAR as an input.

Enhanced validation: The parser does a good job validating various sections and properties of service template but misses validation for nested sections specifically for interfaces and capabilities. Work is in progress to correct these issues so that there is better validation of TOSCA templates.

Containers, Monitoring and Policies: The modeling of container semantics is in progress by the TOSCA Container Ad Hoc Working Group. A similar effort is going on for monitoring types as well by the Monitoring Ad Hoc Working Group. Policies are generally used to convey a set of capabilities, requirements and general characteristics of an entity and this work is in progress too. As these things are addressed in the TOSCA specification, the TOSCA translator team will be working diligently to consume these new requirements and update the code accordingly.

Other major items: The support for node substitution, artifacts definition, new topology_template section, modified requirement definition, implementation of setting output variables to an attribute and updated definition with new or renamed properties and attributes etc.

HOT Generator
One of the other conversations the team and I had was surrounding the mapping of the TOSCA language to Heat Orchestration Templates (HOT). We have made good progress in generating HOT from a TOSCA template and it’s only getting better with the following ongoing work.

Template library: The TOSCA parser produces an in-memory graph of relationship and dependencies between various nodes. The basic generator code is already there to read this graph and provide a mapping to the HOT. Currently it’s been tested for basic use cases like WordPress web application with a MySQL database hosted on a single server and node.js with MongoDB deployed on multiple servers. The extension to node.js and MongoDB template with other components like Elasticsearch, Logstash, Kibana, Collectd and Rsyslog with sample application running on node.js is in progress. We are expecting this work to be done during the OpenStack Kilo release cycle. As this will be a really good use case covering many aspects of TOSCA, I will follow up in more detail with a possible new blog post as we complete it. We are emphasizing on creating many new use cases and their mapping to the HOT.

Mapping to the HOT: The current mapping to HOT uses Heat resource SoftwareConfig which supports storing single configuration script. Kudos to Steve Baker, Thomas Spatzier and other Heat developers for the new Heat resources like SoftwareComponent and SoftwareDeployments which now allows for storing multiple configurations to address handling of lifecycle operations like create, update, delete etc. for a software component in one place. We will be using these new resources for TOSCA node templates with multiple operations, this will provide a concise output HOT template compared to creating a SoftwareConfig resource to process individual configuration operation.

TOSCA CSAR support: Currently the Heat-Translator doesn’t fully support processing user input provided on the CLI but work is in progress and expected to be completed soon. Also it only supports translation of a TOSCA template when provided as a YAML file. In addition to this, the plan is to support translation of TOSCA Cloud Service Archive (CSAR) file. The TOSCA Parser development section of this blog article covers an overview of CSAR file.

Consumability
When I spoke with the team we also discussed the consumability aspect and how to make the Heat-Translator available to Heat users. The current plan to make the tool available in Heat is via CLI. This will be achieved by creating new command(s) in the python-heatclient which will invoke the Heat-Translator with user input as in a TOSCA service template and provide a HOT as an output. In addition to this, we will be going for a next step where instead of just getting translated output, users can seamlessly deploy the TOSCA service temple. This will be achieved by silently invoking the Heat stack-create command with translated output. Once we achieve these two developments goal, per the current discussion within the team we will look into providing a possible API based translation. Another future consideration is to provide a graphical view of TOSCA node relationships in the Horizon dashboard something similar to how users can view Heat resources relationship in the dashboard.

Documentation
Finally, the team and I discussed one of the most important aspects of creating a tool for users and that is documentation. We all agreed, without clear concise documentation that makes the Heat-Translator easy to use it will never gain broad adoption and use.
High level documentation is available at the Heat-Translator documentation but as a team we are going to focus on creating high quality accurate documentation, technical and functional, as we reach important development milestones..

A detailed list of blueprints are available at the Heat-Translator Launchpad
The latest draft of the TOSCA Simple Profile in YAML specification can be found at the TOSCA – OASIS site.

Stay Tuned.

The post What’s Going On With Heat-Translator appeared first on IBM OpenTech.

Powered by WPeMatico