On 19/07/16 11:04, Steven Hardy wrote:
On Fri, Jul 15, 2016 at 10:25:39AM +0100, Steven Hardy wrote:
Hi all,
I'm trying to figure out the cleanest way to do a replacement of values in
a mapping (json parameter) in a heat template, e.g:
ServiceNetMap:
type: json
default:
IronicApiNetwork: internal_api
CephPublicNetwork: storage
NetIpMap:
type: json
default:
storage: 192.0.2.2
internal_api: 192.0.2.5
How do I get
OutputMap:
IronicApiNetwork: 192.0.2.5
CephPublicNetwork: 192.0.2.2
It seems like something yaql should be able to do, but I've so far failed
to figure out the syntax.
The other (possibly simpler) possibility is to implement a new hot
function, e.g something like:
map_replace:
template: {get_param: ServiceNetMap}
value_replacements: {get_param: NetIpMap}
As a follow-up to this, I have posted this spec and implementation for
map_replace (syntax differs slightly from the keys above):
https://review.openstack.org/#/c/343696/
https://review.openstack.org/#/c/343731/
My aim is a simpler interface to the yaql example previously discussed, and
a better error path when things like key collisions occur. Reviews welcome! :)
This all merged in super-quick time before I even had the chance to
look, but I was wondering... is there really any difference between this
and str_replace?
Right now str_replace requires the template to be a string, but I can't
see any reason for that to be the case. Why not just relax that
requirement so the user can pass map or a list and any strings in the
values/items will get (recursively) replaced by values from the params?
That'd be simpler than adding a separate function, and more flexible too
since you can replace parts of values not just the whole thing (and it
would also handle lists and nested data). The map_replace is very tied
to this one particular use case, where the input is a map and the things
you want to replace are top-level values in their entirety.
Just a thought.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
