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

Zane Bitter zbitter at redhat.com
Mon May 22 16:01:35 UTC 2017


On 19/05/17 17:59, Matt Riedemann wrote:
> On 5/19/2017 9:36 AM, Zane Bitter wrote:
>>
>> The problem is that orchestration done inside APIs is very easy to do
>> badly in ways that cause lots of downstream pain for users and
>> external orchestrators. For example, Nova already does some
>> orchestration: it creates a Neutron port for a server if you don't
>> specify one. (And then promptly forgets that it has done so.) There is
>> literally an entire inner platform, an orchestrator within an
>> orchestrator, inside Heat to try to manage the fallout from this. And
>> the inner platform shares none of the elegance, such as it is, of Heat
>> itself, but is rather a collection of cobbled-together hacks to deal
>> with the seemingly infinite explosion of edge cases that we kept
>> running into over a period of at least 5 releases.
>
> I'm assuming you're talking about how nova used to (years ago) not keep
> track of which ports it created and which ones were provided when
> creating a server or attaching ports to an existing server. That was
> fixed quite awhile ago, so I assume anything in Heat at this point is no
> longer necessary and if it is, then it's a bug in nova. i.e. if you
> provide a port when creating a server, when you delete the server, nova
> should not delete the port. If nova creates the port and you delete the
> server, nova should then delete the port also.

Yeah, you're right, I believe that (long-fixed) bug may have been the 
genesis of it: https://bugs.launchpad.net/nova/+bug/1158684 but I could 
be mixing some issues up in my head, because I personally haven't done a 
lot of reviews in this specific area of the code.

Here is the most recent corner-case fix, which is a good example some of 
the subtleties involved in managing a combination of explicit and 
'magical' interactions with other resources:

https://review.openstack.org/#/c/450724/2/heat/engine/resources/openstack/nova/server_network_mixin.py

>> The get-me-a-network thing is... better, but there's no provision for
>> changes after the server is created, which means we have to copy-paste
>> the Nova implementation into Heat to deal with update.[1] Which sounds
>> like a maintenance nightmare in the making. That seems to be a common
>> mistake: to assume that once users create something they'll never need
>> to touch it again, except to delete it when they're done.
>
> I'm not really sure what you're referring to here with 'update' and [1].
> Can you expand on that? I know it's a bit of a tangent.

If the user does a stack update that changes the network from 'auto' to 
'none', or vice-versa.

>> Don't even get me started on Neutron.[2]
>>
>> Any orchestration that is done behind-the-scenes needs to be done
>> superbly well, provide transparency for external orchestration tools
>> that need to hook in to the data flow, and should be developed in
>> consultation with potential consumers like Shade and Heat.
>
> Agree, this is why we push back on baking in more orchestration into
> Nova, because we generally don't do it well, or don't test it well, and
> end up having half-baked things which are a constant source of pain,
> e.g. boot from volume - that might work fine when creating and deleting
> a server, but what happens when you try to migrate, resize, rebuild,
> evacuate or shelve that server?

Yeah, exactly. There is a really long tail of stuff that is easy to forget.

>>> Am I missing the point, or is the pendulum really swinging away from
>>> PaaS layer services which abstract the dirty details of the lower-level
>>> IaaS APIs? Or was this always something people wanted and I've just
>>> never made the connection until now?
>>
>> (Aside: can we stop using the term 'PaaS' to refer to "everything that
>> Nova doesn't do"? This habit is not helping us to communicate clearly.)
>
> Sorry, as I said in response to sdague elsewhere in this thread, I tend
> to lump PaaS and orchestration / porcelain tools together, but that's
> not my intent in starting this thread. I was going to say we should have
> a glossary for terms in OpenStack, but we do, and both are listed. :)
>
> https://docs.openstack.org/user-guide/common/glossary.html

Hmm, I don't love the example in that definition either.
https://review.openstack.org/466773

cheers,
Zane.



More information about the OpenStack-dev mailing list