Open Stack

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.

> 
> 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.

> 
> 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?

> 
>> 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

-- 

Thanks,

Matt