Open Stack

On 19/04/18 08:59, Harald Jensås wrote:
> The problem is getting there using heat ...

The real answer is to make everything explicit - create a Subnet 
resource and a Port resource and don't allow Neutron/Nova to make any 
decisions for you that would have the effect of hiding data that you 
need. However, since that's impractical in this particular case...

> a couple of ideas:
> 
> a) Use heat's ``external_resource`` to create a port resource,
>     and then  a external subnet resource. Then get the data
>     from the external resources. We probably would have to make
>     it possible for a ``external_resource`` depend on the server
>     resource, and verify that these resource have the required
>     attributes.

Yeah, I don't know why we don't allow depends_on for resources with 
external_id. (There's also a bug where we don't recognise dependencies 
contributed by any functions used in the external_id field, like 
get_resource or get_attr, even though we allow those functions.) 
Apparently somebody had a brain explosion at a design summit session 
that nobody remembers attending, and here we are :D

The difficulty is that the fix should be tied to a template version, but 
the offending check is in the template-independent part of the code base.

Nevertheless, a workaround is trivial:

   ext_port:
     type: OS::Neutron::Port
     external_id: {get_attr: [<server>, addresses, <net name>, 0, port]}
     metadata:
       do_something_to_add_a_dependency: {get_resource: <server>}

> b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
>     well probably) to include the data.
> 
>     If we do this we should probably aim to be in parity with
>     what is made available to clients getting the configuration
>     from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
>     gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
>     etc.)

This makes sense to me. If we're allowing people to let Nova/Neutron 
make implicit choices for them then we also need to allow them to see 
the result.

> c) Create a new heat function to read properties of any
>     openstack resource, without having to make use of the
>     external_resource in heat.

I'm pretty -1 on this, because I think you want to have the same caching 
behaviour as a resource, not a function. At that point you're just 
implementing syntactic sugar that makes things _less_ consistent, not to 
mention the enormous implementation hacks required.

cheers,
Zane.