software-config lacks docs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
High
|
Steve Baker |
Bug Description
The new software-config functionality lacks sufficient documentation, in particular I noticed:
- Most of the resources don't have class level docstrings describing what they do, so we're lacking overview information in the generated template guide
- The API reference doesn't document the new API interfaces
- We (IMO) need a howto style document in addition to the template guide showing simple end-to-end examples of how the resources should be combined, along with some information on what happens wrt signalling etc (so folks have a nice tutorial to refer to when learning about the functionality, and some info on what's happening behind the resources when debugging is needed)
I know some of the functionality is indirectly demonstrated by proposed additions to heat-templates, but I think we probably need something in docs.openstack.org too.
Changed in heat: | |
assignee: | nobody → Steve Baker (steve-stevebaker) |
milestone: | none → icehouse-rc1 |
Changed in heat: | |
importance: | Undecided → High |
Changed in heat: | |
status: | New → Triaged |
Changed in heat: | |
milestone: | icehouse-rc1 → next |
Changed in heat: | |
milestone: | next → kilo-rc1 |
tags: | added: kilo-rc-potential |
Changed in heat: | |
milestone: | kilo-rc1 → next |
Few more observations having looked at some of the examples:
- Need to describe clearly the difference between Software* and Structured* resources
- Some documentation related to the hook scripts is needed
- The *Deployment "action" property description is unclear "Which actions the deployment will be triggered in.", it's not clear to me if this means we now have a hook which can be applied only on certain lifecycle/action transitions?
Overall I think we really need more very simple examples to provide an accessible introduction to folks not familiar with the new software config abstractions, combined with more detailed descriptions of the underlying interfaces and expected workflow.