[openstack-dev] [nova] os-capabilities library created
jaypipes at gmail.com
Mon Aug 15 23:26:57 UTC 2016
On 08/15/2016 12:56 AM, Yingxin Cheng wrote:
> I'm concerned with the dependencies between "os-capabilities" library
> and all the other OpenStack services such as Nova, Placement, Ironic, etc.
> Rather than embedding the universal "os-capabilities" in Nova, Cinder,
> Glance, Ironic services that will introduce complexities if the library
> versions are different, I'd prefer to hide this library behind the
> placement service and expose consistent interfaces as well as caps to
> all the other services. But the drawback here is also obvious: for
> example, when nova wants to support a new capability, the development
> will require os-capabilities updates, and related lib version bumps,
> which is inconvenient and seems unnecessary.
It may seem unnecessary and inconvenient, but I honestly don't
anticipate it being particularly onerous for developers to keep track of.
> So IMHO, the possible solution is:
> * Let each services (Nova, Ironic ...) themselves manage their
> capabilities under proper namespaces such as "compute", "ironic" or
-1. What if Ironic wants to utilize a capability that is "compute" --
say, an x86 CPU instruction set extension feature? Clearly, we don't
want a situation where Ironic needs to import Nova in order to get a
list of these constants?
> * Let os-capabilities define as few as caps possible that are only
> * And also use os-capabilities to convert service-defined or
> user-defined caps to a standardized and distinct form that can be
> understood by the placement engine.
User-defined capabilities should be in the placement API only I think.
There simply isn't anything to do for these in a shared library because,
well, they aren't shared things. They are deployment-specific and belong
as just data that is returned from the deployment's particular placement
API after being added as a custom trait/capability string by an
More information about the OpenStack-dev