Open Stack

I'm implementing predictable control plane IPs for spine/leaf, and I'm
running into a problem implementing this in the TripleO Heat templates.

I have a review in progress [1] that works, but fails on upgrade, so I'm
looking for an alternative approach. I'm trying to influence the IP
address that is selected for overcloud nodes' Control Plane IP. Here is
the current construct:

  Controller:
    type: OS::TripleO::Server
    metadata:
      os-collect-config:
        command: {get_param: ConfigCommand}
    properties:
      image: {get_param: controllerImage}
      image_update_policy: {get_param: ImageUpdatePolicy}
      flavor: {get_param: OvercloudControlFlavor}
      key_name: {get_param: KeyName}
      networks:
        - network: ctlplane  # <- Here's where the port is created

If I add fixed_ip: to the networks element at the end of the above, I
can select an IP address from the 'ctlplane' network, like this:

      networks:
        - network: ctlplane
          fixed_ip: {get_attr: [ControlPlanePort, ip_address]}

But the problem is that if I pass a blank string to fixed_ip, I get an
error on deployment. This means that the old behavior of automatically
selecting an IP doesn't work.

I thought I has solved this by passing an external Neutron port, like this:

      networks:
        - network: ctlplane
          port: {get_attr: [ControlPlanePort, port_id]}

Which works for deployments, but that fails on upgrades, since the
original port was created as part of the Nova::Server resource, instead
of being an external resource.

I'm now looking for a way to use Heat conditionals to apply the fixed_ip
only if the value is not unset. Looking at the intrinsic functions [2],
I don't see a way to do this. Is what I'm trying to do with Heat possible?

Another option I'm exploring is conditionally applying resources. It
appears that would require duplicating the entire TripleO::Server stanza
in *-role.yaml so that there is one that uses fixed_ip and one that does
not. Which one is applied would be based on a condition that tested
whether fixed_ip was blank or not. The downside of that is that it would
make the role definition confusing because there would be a large
resource that was implemented twice, with only one line difference
between them.

Does anyone have any ideas how to go about this?

[1] - https://review.openstack.org/#/c/413278/
[2] -
https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#intrinsic-functions

-- 
Dan Sneddon         |  Senior Principal Software Engineer
dsneddon at redhat.com |  redhat.com/openstack
dsneddon:irc        |  @dxs:twitter