Open Stack

On 05/18/2017 08:19 PM, Matt Riedemann wrote:
> I just wanted to blurt this out since it hit me a few times at the
> summit, and see if I'm misreading the rooms.
> 
> For the last few years, Nova has pushed back on adding orchestration to
> the compute API, and even define a policy for it since it comes up so
> much [1]. The stance is that the compute API should expose capabilities
> that a higher-level orchestration service can stitch together for a more
> fluid end user experience.
> 
> One simple example that comes up time and again is allowing a user to
> pass volume type to the compute API when booting from volume such that
> when nova creates the backing volume in Cinder, it passes through the
> volume type. If you need a non-default volume type for boot from volume,
> the way you do this today is first create the volume with said type in
> Cinder and then provide that volume to the compute API when creating the
> server. However, people claim that is bad UX or hard for users to
> understand, something like that (at least from a command line, I assume
> Horizon hides this, and basic users should probably be using Horizon
> anyway right?).
> 
> While talking about claims in the scheduler and a top-level conductor
> for cells v2 deployments, we've talked about the desire to eliminate
> "up-calls" from the compute service to the top-level controller services
> (nova-api, nova-conductor and nova-scheduler). Build retries is one such
> up-call. CERN disables build retries, but others rely on them, because
> of how racy claims in the computes are (that's another story and why
> we're working on fixing it). While talking about this, we asked, "why
> not just do away with build retries in nova altogether? If the scheduler
> picks a host and the build fails, it fails, and you have to
> retry/rebuild/delete/recreate from a top-level service."
> 
> But during several different Forum sessions, like user API improvements
> [2] but also the cells v2 and claims in the scheduler sessions, I was
> hearing about how operators only wanted to expose the base IaaS services
> and APIs and end API users wanted to only use those, which means any
> improvements in those APIs would have to be in the base APIs (nova,
> cinder, etc). To me, that generally means any orchestration would have
> to be baked into the compute API if you're not using Heat or something
> similar.
> 
> 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?

Lots of people just want IaaS. See the fact that Google and Microsoft
both didn't offer it at first in their public clouds, and got pretty
marginal uptake while AWS ate the world. They have both reversed course
there.

The predictability of whether an intent is going to be fullfilled, and
"POST /servers" is definitely pretty clear intent, is directly related
to how much will are going to be willing to use the platform, build
tools for it. If it's much more complicated to build tooling on
OpenStack IaaS because that tooling needs to put everything in it's own
retry work queue, lots of folks will just give up.

I do get the concerns of extra logic in Nova, but the decision to break
up the working compute with network and storage problem space across 3
services and APIs doesn't mean we shouldn't still make it easy to
express some pretty basic and common intents.

	-Sean

-- 
Sean Dague
http://dague.net