Accordingly, I think we can close the heat part of this as until rich-network-prop lands, this can probably be categorized as a known issue, rather than a bug.
I've associated the rich-network-prop with this bug anyway, so we have some connection between the two issues,
Ok, so following the ML discussion with stevebaker, I'm proposing we do the following:
1. Get the AUTO workaround into tripleo- heat-templates to mitigate the immediate problem
2. Wait for https:/ /blueprints. launchpad. net/heat/ +spec/rich- network- prop to land, then convert to using that, so we get less undesirable behaviour in the various update patterns AUTO doesn't handle so well (ref http:// lists.openstack .org/pipermail/ openstack- dev/2014- October/ 049491. html which contains a very nice summary of the current pros/cons to each replacement_ property setting.
Accordingly, I think we can close the heat part of this as until rich-network-prop lands, this can probably be categorized as a known issue, rather than a bug.
I've associated the rich-network-prop with this bug anyway, so we have some connection between the two issues,