Open Stack

On 09/08/13 08:11, Chan, Winson C wrote:
> I tested FnGetRefId() in LaunchConfiguration to return unicode(self.physical_resource_name()).  It doesn't work so well.  When InstanceGroup resolve runtime data and resolve resource refs, the physical resource name (I.e.test_stack-JobServerConfig-jnzjnpomcxv5) replaced { 'Ref': 'JobServerConfig' }.  So when InstanceGroup tries to look up the LaunchConfiguration resource during handle_create, it throws a KeyError on the physical resource name.  The LaunchConfiguration is using key 'JobServerConfig' in the stack's resources dictionary.  Any I missing something here?

Yeah, if you change the meaning of the input to the LaunchConfiguration 
property then obviously you need to change what you look up with that 
data at the same time. The hacky way to do this is to search through the 
stack looking for a resource with that physical resource name. (We used 
to have a wrongly-implemented physical_resource_name_find() function for 
this purpose, but it has mercifully been removed.) This approach shares 
with the existing one the problem of not being able to refer to 
LaunchConfigurations outside the same stack. We really need to be able 
to orchestrate anything in Heat without having the Resource object that 
corresponds to it (in fact, this shouldn't even need to exist - users 
should be able to define the resource outside of Heat and pass 
references in).

A better way is probably to store the configuration details in the 
ResourceData table in the database, and use the id of that row (which 
should be a uuid, but isn't) for the resource_id (and Ref id) of the 
LaunchConfiguration. There will be some tricky security stuff to get 
this right though.

The long-term solution to this is a separate Autoscaling API (or, at 
least, database tables) so that we can use the physical name or uuid to 
look up a particular launch configuration.

cheers,
Zane.