[openstack-dev] Is the pendulum swinging on PaaS layers?

Zane Bitter zbitter at redhat.com
Fri May 26 14:21:02 UTC 2017


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.



More information about the OpenStack-dev mailing list