[openstack-dev] Is the pendulum swinging on PaaS layers?
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
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
Yep, it's all possible, since Nova talks to Neutron over a public API.
Here is the implementation in Heat:
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.
More information about the OpenStack-dev