Open Stack

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?

[1] https://docs.openstack.org/developer/nova/project_scope.html#api-scope
[2] 
https://etherpad.openstack.org/p/BOS-forum-openstack-user-api-improvements

-- 

Thanks,

Matt