Open Stack

On Tue, 2018-04-24 at 16:12 -0400, Zane Bitter wrote:
> 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...
> 
Yeah, I wish the ctlplane network in tripleo was defined in THT. But
since it's created by undercloud installer we are where we are. Moving
it is impractical for the same reasons migrating from server resources
with implicit ports is ...

Another non tripleo use case is when connecting the instance to a
provider network, in this case the network and subnet resource is
beyond the user control. (External resource probably, but there seem to
be the issues Zane mentions below.)

> > 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.
> 
I like this idea best as well. I will open an rfe against Heat.

> > 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.
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev