Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Design Summit [clear filter]
Monday, April 15

9:50am PDT

How to run multiple heat-engines and scaling

Currently we have an archetecture that should support scalling but
some code is missing.

How does the heat-api find the correct engine to talk to?
How would a "heat list" work?


(Session proposed by Angus Salkeld)


Monday April 15, 2013 9:50am - 10:30am PDT

11:00am PDT

Heat credentials management/delegation
Heat has two problem areas related to managing keystone identities:

1 - Storing user credentials when creating a stack, such that subsequently we can perform actions on behalf of the user who created the stack (HA actions, Autoscaling events etc)

2 - We allow credentials (keystone ec2 keypair) to be deployed inside each instance, such that authentication with our API's is possible, for the purposes of reading updated resource metadata, and writing metric data used for Alarm evaluation.

(1) is likely to be solved by the Trusts work recently merged into keystone, but I'd like to clarify the details/design of how we will use trusts to perform actions on behalf of the stack-owner in a secure way.

(2) We currently have a sub-optimal solution for, but no clear path to improving it - I'd like to present the current-state of our in-instance credentials management, and brainstorm the way forward, I'm expecting some requirements for additional keystone features to come out of this.

(Session proposed by Steven Hardy)

Monday April 15, 2013 11:00am - 11:40am PDT

11:50am PDT

Adding support for OASIS TOSCA to Heat
Heat provides an orchestration layer in OpenStack on-top of base compute, network and storage capabilities and allows for defining more advanced patterns on top of those core capabilities. Heat is currently based on Amazon CloudFormation syntax so users have to adopt that specific format. Adding support for another, standardized format such as the OASIS TOSCA standard would allow for also deploying patterns that users have created using that standardized format. TOSCA also provides features for expressing requirements and capabilities of pattern components, that also allow for composing patterns out of (i.e. by re-using) other patterns. Therefore, as part of ongoing refactoring and evolutionary work on Heat, we propose to adopt TOSCA as one supported pattern format, and to align enhancements with concepts found in TOSCA (such as requirements/capabilities).

(Session proposed by Thoms Spatzier)

Monday April 15, 2013 11:50am - 12:30pm PDT

1:50pm PDT

Abstracting the AWS out of Heat
Heat adoption by cloud providers be slowed by the fact that users will be required to advertise for the competition just to write a template. While the format of Heat templates is about as basic as it comes, users should be able to express any capability of Heat with OpenStack/Heat resources entirely. It should also be possible for someone deploying heat to disable the usage of the AWS namespace entirely.

(Session proposed by Clint Byrum)

Monday April 15, 2013 1:50pm - 2:30pm PDT

2:40pm PDT

Autoscaling API for Heat
Heat has done an enormous amount of work towards feature-parity with AWS AutoScaling and CloudWatch. The intent of this session is to discuss what work remains left to be done, to fully explore the scope of that work, and to come to a consensus on a high-level implementation plan.

In particular, there is interest in creating an API for manipulating scaling groups, responding to alerts, scaling up/down, etc. There are many ways an API could be provided, and at least two different places it could live. This session aims to resolve any ambiguities around this.

Ideally, the outcome of these session would be a well-defined approach for 1) any additional implementation needed in Heat, and 2) a plan for creating an autoscaling API that a consensus agrees is the best approach.

(Session proposed by Duncan McGreggor)

Monday April 15, 2013 2:40pm - 3:20pm PDT

3:40pm PDT

Concurrent Resource Scheduling in Heat
Heat currently uses a strategy of only creating/deleting/updating one resource per stack at a time. It does this in in dependency-topology order which keeps the code simple and guarantees things happen in the intended order. With large stacks, this will mean a significant amount of time spent waiting unnecessarily. We should discuss the problem space and various strategies to reduce waiting.

(Session proposed by Clint Byrum)

Monday April 15, 2013 3:40pm - 4:20pm PDT

4:30pm PDT

Rolling Updates and Instance Specific Metadata
Rolling updates is a proposed feature for havana that will allow updating metadata for instance groups in a controlled fashion.

There is also a need to have per-instance metadata for sharing things like database credentials, as it is more robust to have per-instance credentials than shared credentials.

We need to have a discussion on how those two features will interact.

(Session proposed by Clint Byrum)

Monday April 15, 2013 4:30pm - 5:10pm PDT