OpenStack Mitaka Design Summit

https://etherpad.openstack.org/p/mitaka-heat-documentation

Most heat releated documentation is now generated from the heat tree to http://docs.openstack.org/developer/heat/,
so it is entirely up to us to write the content for our users, operators and developers.
This session will go through the documentation we have, identify areas which have gaps, and attempt to find volunteers to write content.

Heat Template Refactoring

Talk to Steve Hardy and TripleO team to learn from their experience in refactoring, managing templates. Magnum has recently merged code to use a master Jinja2 template that generates individual HOT files if they don't already exist. These HOT files are used for bay creation in Magnum.

https://bugs.launchpad.net/magnum/+bug/1501045

https://etherpad.openstack.org/p/mitaka-heat-tests

* Need to clarify our plans corresponding functional tests and tempest for Mitaka.
* Create list of tasks and assign volunteers.
* Related questions: https://review.openstack.org/#/c/216983/
- using tempest-lib for Heat finctional/intergration tests?
- migrating some tests from Heat repo to tempest or visa-versa

https://etherpad.openstack.org/p/mitaka-heat-convergence-migration

Will operators need a tool to convert stacks to and from convergence? Use cases...
1. If someone tries convergence and likes it/wants to stay with it, they may want to migrate their existing stacks +1 I think we need this & I don't think it's that hard (famous last words, I know). Not sure we need a session to discuss though; at least start on the ML.
2. If someone is using convergence and runs up on a deal-breaker bug, they may want to migrate existing stacks to "standard". Meh
If this is going to be too complex then it is problably too risky and not worth the trouble, but if we could just run abandon/adopt with the new mode then that might be a neat way to do this.
spec: https://review.openstack.org/232277

https://etherpad.openstack.org/p/mitaka-heat-large-stacks

During this session we want to discuss issues which happens during creating large stacks:
* token timeouts
* nova limitations (ResourceGroup batching should be ok for this - status)
* polling services during check_complete
* heat limits (resources, template size)
* validation for large stack may take a lot of time (looks like was fixed by caching mechanism)
* another part - we wait validation of all template, before sending response about starting creation (may be make validation separate?)

https://etherpad.openstack.org/p/mitaka-heat-user-ops

* pain points.
* feature requests.
* app catalog: what templates do users need in the app catalog, (should upstream Heat team need to be involved in this)?
* "Implement SecurityGroupIngress and SecurityGroupEgress" blueprint is very important. Could be in high priority ?

https://etherpad.openstack.org/p/mitaka-heat-autoscaling

* Status of Senlin, is there scope for Heat integration ref native ASG resources?
* Senlin has more knobs than Heat ASG: could we have something like: ASG leverages small set of senlin features,
but existing templates work; users who want full senlin features use new senlin resource types?
*Internal rework re scaling lib - how does this relate to the above, and what further work is planned/needed (& can/should any of this be used in Senlin?)

https://etherpad.openstack.org/p/mitaka-heat-break-stack-barrier

Right now, dependencies don't cross stack boundaries. That leads to weird behaviour when you start using nested stacks to break up your application into more maintainable components. What if we were to break down the barriers between nested stacks and treat a whole tree of stacks as one giant dependency graph? Or at least split the update and cleanup phases of nested stack updates. (Note: Phase 1 of Convergence is a likely prerequisite.)

https://etherpad.openstack.org/p/mitaka-heat-composition-improvements

Looking to clarify objections to the proposal to enhance HOT to support an optional capabilities annotation,
which is similar in concept to the TOSCA substitution_mapping definition.
This would move us closer to being a TOSCA capable orchestrator, and enable more control of the already
powerful composition capabilities exposed via our resource_registry interfaces.
Spec: https://review.openstack.org/#/c/196656/

This then raises some interesting questions around parameter interfaces (and resource_registry interfaces)
If you expect to have your heat templates widely consumed, the parameters inteface is effectively your "public API".
* How do you deprecate or rename anything, ever (we need a user-visible warning mechanism, combined with some sort of deprecated tag similar to how oslo config deprecation works?)
* Could we add some way to define cross parameter constraints (or multiple conflicting parameter_groups), such that you could e.g group certain parameters as deprecated and/or conflicting with some others?
* Related to the cross-parameter constraint but more general than deprecation/conflict, could we have e.g defaults defined derived from another parameter, or constraints (such as min/max) derived in a similar way?
The idea with all of this is to enable a more complete user-visible schema to be defined, and to enable that to evolve over time when those writing and consuming the templates are not the same folks.

https://etherpad.openstack.org/p/mitaka-heat-openstackclient

Lets aim for a python-heatclient 1.0.0 which has full support for all heat commands that work on python-openstackclient.
Topics to cover include:
* Namespacing top-level commands from plugins are uncoordinated. Other than 'stack', what other top-level commands will we claim?
* There are lots of commands to port over, this would be best shared by multiple developers, look for volunteers
* What higher-level commands are missing which would actually help users manage complex stacks (eg, debugging failed resources in deeply nested stacks)

https://etherpad.openstack.org/p/mitaka-heat-hooks-notifications

* Hooks are a big step forward to allowing users to quiesce workloads. But the current interface kind of sucks. The hooks trigger almost silently, and have to be polled. If they get set by accident, you'll likely never figure out why your stack is timing out. Some things to consider:
* A notification mechanism for hooks (Zaqar?). Related: https://review.openstack.org/232967
* A way to set hooks temporarily (so that even when you use PATCH and keep the same environment, they don't stick around)
* More types of hooks ("post-" hooks? "pre-delete"?)
* Hooks between batches of rolling ASG/RG updates. Or just pre- and post- hooks on whole (nested) stack updates?
* Resolve the issue with pre-update hooks running whether or not the resource in question is to be updated. (Can this even be resolved?) Define hook types with the desired behaviour w.r.t replace-on-update.
* Incorporating hooks in convergence

https://etherpad.openstack.org/p/mitaka-heat-convergence-ph1

Discuss current status of convergence:
* What was done, what also need to do for finishing.
* Current issues.
* Plans about collecting feedback from users.

https://etherpad.openstack.org/p/mitaka-heat-convergence-ph2

We want again refresh memories from previous summit and discuss existing specs.

Let's discuss the way forward for a service "protecting" Nova resources.

More info:
https://etherpad.openstack.org/p/mitaka-nova-service-users

The Heat contributors meetup is a informal gathering of the project contributors, with an open agenda.

Click here for details on the meetup agenda.