SoftwareDeploymentGroup does not accept any attribute from ResouceGroup for "servers" property

[Christopher Hultin]

OS::Heat::SoftwareDeploymentGroup requires a Map containing the server IDs/names to apply the SoftwareConfig to. OS::Heat::ResourceGroup returns a list of server IDs, rather than a map. There are no intrensic functions that permit the conversion of a List to a Map, preventing the usage of a ResourceGroup and a SoftwareDeploymentGroup.

[Randall Burt (randall-burt)]

Steve Baker: maybe I'm missing something, but I can't find a good way to match these two up though it should be the easiest thing. Thoughts?

[Steve Baker (steve-stevebaker)]

Here is the pattern to follow

Define an attribute in the resource group:
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/compute.yaml#L697

Fetch the attributes in map form:
https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud.yaml#L1303

[Randall Burt (randall-burt)]

randallburt stevebaker: though that seems to be a lot of hoop jumping for two things that should "just work" together. Would there be any objection to adding another property to SDG that accepts a list of server ids? The names of the resources in the SDC nested stack don't seem terribly important on the surface.
3:23 stevebaker randallburt: it is important, the key in the map determines the name of the deployment resources
3:24 randallburt stevebaker: but why should we care if its some provided name or an index?
3:25 stevebaker randallburt: because servers may come and go from the list, so an index may end up refering to different servers - which would be bad
3:26 stevebaker randallburt: this way we can use ResourceGroup's behaviour of not reusing names (which are incrementing numbers)
3:26 randallburt stevebaker: so I'm assuming here that I *have* to use a nested stack that simply redefines the server resource, but I could just use a server?
3:27 stevebaker randallburt: sure you could define your own servers map with arbitrary keys
3:27 randallburt stevebaker: I'm talking about using a ResourceGroup that has vanilla OS:::Nova::Servers in it
3:28 Drago get_attr: [rg, attributes, accessIPv4] ?
3:28 stevebaker oh, yeah. that should work
3:28 randallburt Drago: well, not the ip address. SDG needs server ids
3:28 Drago randallburt: ah right
3:30 randallburt stevebaker: so OS::Nova::Server doesn't have an attribute for its id, how would that work, then?
3:31 dprince left the room (quit: Quit: leaving).
3:32 randallburt stevebaker: seems like we would have to change https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/resource_group.py#L420-L422 to return refs if no path were specified or something similar
3:33 stevebaker randallburt: I suspect its already possible, just poorly documented
3:33 Drago get_attr: [rg, attributes, show, id] ?
3:34 stevebaker randallburt: don't you want get_attr: [rg, refs] ?
3:34 randallburt stevebaker: yep, but that's not a map, is it?
3:35 stevebaker randallburt: heh, is there a problem with putting the server in a nested stack?
3:35 stevebaker Drago: that would work but would hit nova for every server
3:36 Drago oh
3:36 randallburt stevebaker: seems hoop-jumpy and really unnessisary. I'd define a template thats just a wrapper around OS::Nova::Server just to get this to work...
3:36 randallburt stevebaker: and again, it seems odd to me that these two things don't "just work"
3:36 randallburt together
3:37 stevebaker randallburt: sure, but I'd rather rg be enhanced to create a refs map than sdg be enhanced to take a list
3:38 randallburt stevebaker: that works too
3:38 vijendar left the room (quit: Quit: Leaving.).
3:38 randallburt stevebaker: so copy pasta this convo into the bug and re-open. I can hack the change into RG.
3:39 randallburt stevebaker: that was a question, btw. I type dumb.
3:39 stevebaker randallburt: +1
3:39 randallburt stevebaker: cool, thanks!