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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
