Icehouse Design Summit

The nice thing about the CloudFormation template format is that it contains no magic whatsoever. The 'Ref' function returns a string reference to a resource ID that is the same string that you might use to identify the resource if you were calling an API directly. You can pass these strings e.g. between templates or as parameters based on pre-existing resources you have created yourself and everything behaves exactly as it should.

Heat, on the other hand, is full of magical hacks cobbled together in such as way that they are completely invisible to the user until they hit a case that doesn't work. A probably-incomplete list:

* AutoscalingGroup resources can use a LaunchConfiguration only if it is created in the same stack.
* ScalingPolicies work only with AutoscalingGroups created in the same stack.
* AccessKeys can reference only a User created in the same stack.
* User resources access their associated Policies by looking up the RefId of the policy by name(!) in the same stack.
* Neutron Ports can reference only SecurityGroups created in the same stack.
* Neutron RouterGateways have hidden dependencies on RouterInterfaces and Subnets, but only if they are defined in the same stack. This means things may not work if they are defined in different stacks, and dependencies are impossible to debug as they are hidden from the user.
* Neutron Ports have similar hidden dependencies on Subnets.
* WaitConditions must be defined in the same stack as their WaitConditionHandles.
* AutoscalingGroup resources can use a LoadBalancer only if it is created in the same stack.
* The CeilometerAlarm resource uses a magic automatic reference to an action in the same stack if the user passes a resource name instead of using Fn::GetAtt to retrieve the AlarmUrl attribute.

We need to exorcise the magic from Heat. There are a number of different strategies we may want to use to attack different parts of the problem.

Most of the issues relate to 'resources' that have no actual underlying physical resource (with a UUID, and API &c.) outside of Heat. We need a way of accessing these without needing to spread authentication code (which is currently confined to the API middleware) throughout the engine.

In the case of Neutron, the problem is a bad API design that was only discovered after we had implemented resources. IMO it is a mistake to tie the resource design to mirror exactly the current API, since new API versions are released regularly. We should consider redesigning the resources with the primary criterion that they actually work, and fidelity to a particular version of the underlying API well down the list.

(Session proposed by Zane Bitter)