On 25/05/17 18:34, Matt Riedemann wrote:
On 5/22/2017 11:01 AM, Zane Bitter wrote:
If the user does a stack update that changes the network from 'auto'
to 'none', or vice-versa.
OK I guess we should make this a side discussion at some point, or hit
me up in IRC, but if you're requesting networks='none' with microversion
= 2.37 then nova should not allocate any networking, it should not
event attempt to do so.
Maybe the issue is the server is created with networks='auto' and has a
port, and then when you 'update the stack' it doesn't delete that server
and create a new one, but it tries to do something with the same server,
Yes, exactly. There are circumstances where Heat will replace a server
because of a change in the configuration, but we want to have as few as
possible of them and this is not one.
and in this case you'd have to detach the port(s) that were previously
created?
Yep, although this part is not that much different from what we had to
do already when ports/networks change. The new part is handling the case
where the user updates the network from 'none' -> 'auto'.
I don't know how Heat works, but if that's the case, then yeah that
doesn't sound fun, but I think Nova provides the APIs to be able to do
this.
Yep, it's all possible, since Nova talks to Neutron over a public API.
Here is the implementation in Heat:
https://review.openstack.org/#/c/407328/16/heat/engine/resources/openstack/nova/server_network_mixin.py
The downside is that (in the update case) Heat has to call Neutron's
get_auto_allocated_topology() itself rather than let Nova do it, so we
now have some amount of duplicated logic that has to be kept in sync if
anything ever changes in Nova/Neutron. It's definitely not the end of
the world, but it's not entirely ideal either.
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
