Open Stack

On 08/15/2016 12:56 AM, Yingxin Cheng wrote:
> Hi,
>
> 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
> "storage";

-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
> cross-project;
> * 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 
administrator.

Best,
-jay