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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
