Add proposal for nova-compute-api

Change-Id: Ib33e78ff25636430677a6d487110f23424620b7b
This commit is contained in:
Clint Byrum 2016-12-15 14:46:58 -08:00
parent d2e35099da
commit 7086083711
1 changed files with 33 additions and 0 deletions

View File

@ -0,0 +1,33 @@
Introduction
============
In the beginning there was Nova. It included volumes, networking,
hypervisors, and scheduling. Since then, Nova components have either
been replaced (nova-network with Neutron) or forklifted out and enhanced
(Cinder). In so doing, interfaces were defined for how Nova would
continue to make use of these now-external services, but nova-compute,
the place where the proverbial rubber meets the road, was left inside
Nova. This meant that agents for Cinder and Neutron had to interact with
nova-compute through the high level message bus, despite being right
on the same physical machine in many (but not all) cases. Likewise,
some cases take advantage of that, and require operator cooperation in
configuring for certain drivers.
This has led to implementation details leaking all over the API's that
these services use to interact. Neutron and Nova do a sort of haphazard
dance to plug ports in, and Cinder has drivers which require locking files
on the local filesystem a certain way. These implementation details are
leaking into public API's because it turns out nova-compute is actually
a shared service that should not belong to any of the three services,
and which should define a more clear API which Nova, Cinder, and Neutron,
should be able to use to access the physical resources of machines from
an equal footing.
proposed next steps
===================
* Produce an accurate analysis on the current state of nova-compute's
interaction with other OpenStack services.
* Produce a cross-project spec for moving nova-compute out of Nova
and defining an API for it that meets the needs of all other projects.