Provide translation layer for TOSCA Service Template to Heat native DSL
Heat orchestration is currently based on AWS CloudFormation (CFN) templates, but work is in progress to define a neutral, native Heat Template format / DSL [1] that over time will become only format processed by the core Heat engine. Definition of this DSL is currently driven at [2]; more links are also provided in [1].
It is envisioned that this DSL [1] will be designed in a way that other formats such as TOSCA can be mapped to it, so translation modules can be implemented to translate from other formats into the native DSL. A corresponding future architecture for Heat is currently being discussed at [3].
The current BP proposed to build a translation tool to translate from TOSCA to native Heat DSL so TOSCA templates can be deployed on OpenStack Heat. This translator can be built as an add-on component outside core Heat intially. Later on, a pluggable translation layer could be built more closely into Heat and the TOSCA translation component could be refactored as a module into that pluggable layer.
This BP has BP [1] as a pre-req.
[1] https:/
[2] https:/
[3] https:/
Blueprint information
- Status:
- Complete
- Approver:
- Steve Baker
- Priority:
- High
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Steve Baker
Whiteboard
shardy: I've marked this as dependent on the DSL blueprint, and as mentioned below we can use this BP to track implementation of a TOSCA->native-dsl interpreter standalone tool
https:/
(thomas-spatzier) Updated BP title and summary according to latest discussions.
Question: should we capture the creation of a general pluggable translation layer in its own BP which can be picked up at the appropriate time?
---
https:/
---
(thomas-spatzier)
Capturing current state after discussions at Havana summit:
Heat is going to adopt a new native pattern language currently being defined in [1]. Discussions at summit were that this would be a superset language to address use cases of all involved parties, and this would be *the* language that the Heat core engine would support.
On-top of that language, other external renderings (such as TOSCA) can be supported as pluggable model interpreters that basically translate other formats into the core language. A desired architecture to support this is currently being discussed in [2].
So net outcome for the TOSCA support discussion: from a TOSCA perspective we have to make sure the concepts and features of TOSCA are properly reflected in [1] so that translation from/to TOSCA can work.
Implementation of support for [1] in Heat is then the highest priority item.
Based on that, we can then build a translation layer on-top (green box in upper right-hand corner in [2]). Initially, this translation component can be really an add-on (go into Heat tools). Later on, and depending on workload we can see to integrate this into Heat more seamlessly.
[1] Heat DSL proposal:
https:/
[2] Heat future vision and architecture proposal:
https:/
---
(thomas-spatzier) going to remove the discussion below from the whiteboard, because those have been initial discussions only that moved to the mailing list and have been carried on at the Havana summit.
Please object if anyone thinks this still belongs to the whiteboard.
(alexheneveld) +1 -- a standardised (and more extensive) alternative to Cloudformation, would be great to see Heat expand (ha ha that's the effect of heat!) to encompass this
Useful links:
TOSCA site: https:/
Recent spec draft: http://
Primer draft: http://
(asalkeld) What a torture to read!
Can we have some concrete examples?
1) wikimedia web server
2) autoscaling version of the above with loadbalancer
That spec seems to be carefully designed to chase people away screeming :-O
Also can you actually use tosca without having to zip up a bunch of files? - that's a fail (plain text please).
(alexheneveld) yeah could do with a primer for the primer at the moment. there are various works in progress for more examples. the point is, it's a lot more flexible than cloudformation -- pros and cons of being heavyweight.
(thomasspatzier) the question for concrete examples is a good one, and we are actually working on such examples and related documentation in the interop SC. Regarding requirement for a zipped file: this is not required in all cases; in some use cases providing a single ServiceTemplate is enough; in other cases where you want to provide a consistent package with artifacts related to your model, it does make sense, though.
We also think about a subset profile for certain scenarios.
(zaneb) This whole blueprint is putting the cart before the horse. I see a lot of talk about things we should implement here, but nothing about how this would create value for users. You haven't even identified a single relevant feature of TOSCA except for template composition, which Heat already supports. Why don't you start a discussion on the mailing list about ways in which you feel that CloudFormation templates are limiting users? _Then_ we can discuss whether those limitations are important and how we might remove them.
(thomas-spatzier) Ok, let me try to clarify: the actual use case is being able to import and deploy patterns defined in a standardized format that many companies have agreed on. There are companies creating content using the TOSCA specification, and this is partly complex content for enterprise-level workloads where we would not really want to recode this in CF format.
Don't get me wrong, we are not proposing to replace anything that is there, but we are proposing to provide an alternative input format.
If Heat already supports template composition, dynamic substitution of components based on requirements, capabilities and constraints, etc. that is great. If this maps to TOSCA nicely, even better. Then supporting this additional input/output format would be easier.
Our goal (based on the fundamental use case stated in my 1st sentence) would be to make concepts in Heat and TOSCA aligned while this evolves. Especially, as new features get developed based on specific use cases, see if we can do it in a way that we have good alignment.
And this can be a synergetic approach, i.e. we are also interested in feeding experience and feedback from implementation work back into the standard to improve it.
Another point worth mentioning: we probably do not want to apply 100% of TOSCA here, but for example define a sub-set profile that makes sense in context of Heat, maybe also an alternative rendering (compared to the XML rendering in the spec). TOSCA has a meta-model and concepts, so the goal would be to have concepts and model aligned well.
(zaneb) If Heat turns out to map isomorphically to TOSCA, then why not create a standalone tool for translating templates (bonus: AWS support for free!). And if it doesn't then let's discuss what's missing, whether that's a part of the subset that's relevant here, and how we can fix it.
(thomas-spatzier) Personally, I think that an external tool could increase the complexity exposed to the user, i.e. something is visibly added to the system. And it often ends up being in catch-up mode. Anyway, this is a really good discussion evolving here. Would it be possible to get together for a slot at the summit in two weeks to further discuss? I think a lot of the folks interested in this topic will be there, so that would be a good chance to have some detail talks.
(clint-fewbar) Hi guys! Great discussion. However, this is the white board, not a discussion forum. Lets include the rest of the OpenStack community and take it to the openstack-dev mailing list. The session can be where we resolve anything that is problematic on the mailing list. Don't wait for the summit to get your ideas into peoples' heads! Thanks.
(thomas-spatzier) Good point, Clint. I will start a thread on the mailing list and copy a link to this BP.
(Andrew Farrell) Happy to contribute to this dev wise. Spare time activity.
(stevebaker) spzala is about to raise a replacement blueprint for this feature
(spzala) Thanks stevebaker! I have created a new one, https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
