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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
