Open Stack

On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon <dsneddon at redhat.com> wrote:
> 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.

Can you detail how it fails? I was under the impression we never
replaced servers no matter what (or we try to do that, at least). Is
the issue that your new port is not the correct one?

> 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?

You should be able to write something like that (not tested):

networks:
  if:
    - <my condition>
    - network: ctlplane
      fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
    - network: ctlplane

The question is how to define your condition. Maybe:

conditions:
  fixed_ip_condition:
     not:
        equals:
          - {get_attr: [ControlPlanePort, ip_address]}
          - ''

To get back to the problem you stated first.


> 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.

You can define properties with conditions, so you shouldn't need to
rewrite everything.

-- 
Thomas