[openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function
Tomas Sedovic
tsedovic at redhat.com
Thu Feb 20 13:29:33 UTC 2014
On 19/02/14 08:48, Clint Byrum wrote:
> Since picking up Heat and trying to think about how to express clusters
> of things, I've been troubled by how poorly the CFN language supports
> using lists. There has always been the Fn::Select function for
> dereferencing arrays and maps, and recently we added a nice enhancement
> to HOT to allow referencing these directly in get_attr and get_param.
>
> However, this does not help us when we want to do something with all of
> the members of a list.
>
> In many applications I suspect the template authors will want to do what
> we want to do now in TripleO. We have a list of identical servers and
> we'd like to fetch the same attribute from them all, join it with other
> attributes, and return that as a string.
>
> The specific case is that we need to have all of the hosts in a cluster
> of machines addressable in /etc/hosts (please, Designate, save us,
> eventually. ;). The way to do this if we had just explicit resources
> named NovaCompute0, NovaCompute1, would be:
>
> str_join:
> - "\n"
> - - str_join:
> - ' '
> - get_attr:
> - NovaCompute0
> - networks.ctlplane.0
> - get_attr:
> - NovaCompute0
> - name
> - str_join:
> - ' '
> - get_attr:
> - NovaCompute1
> - networks.ctplane.0
> - get_attr:
> - NovaCompute1
> - name
>
> Now, what I'd really like to do is this:
>
> map:
> - str_join:
> - "\n"
> - - str_join:
> - ' '
> - get_attr:
> - "$1"
> - networks.ctlplane.0
> - get_attr:
> - "$1"
> - name
> - - NovaCompute0
> - NovaCompute1
>
> This would be helpful for the instances of resource groups too, as we
> can make sure they return a list. The above then becomes:
>
>
> map:
> - str_join:
> - "\n"
> - - str_join:
> - ' '
> - get_attr:
> - "$1"
> - networks.ctlplane.0
> - get_attr:
> - "$1"
> - name
> - get_attr:
> - NovaComputeGroup
> - member_resources
>
> Thoughts on this idea? I will throw together an implementation soon but
> wanted to get this idea out there into the hive mind ASAP.
I think it's missing lambdas and recursion ;-).
Joking aside, I like it. As long as we don't actually turn this into
anything remotely resembling turing-completeness, having useful data
processing primitives is good.
Now onto the bikeshed: could we denote the arguments with something
that's more obviously looking like a Heat specific notation and not a
user-entered string?
E.g. replace "$1" with {Arg: 1}
It's a bit uglier but more obvious to spot what's going on.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
More information about the OpenStack-dev
mailing list