Open Stack

On 08/15/2016 03:57 AM, Alex Xu wrote:
> 2016-08-15 12:56 GMT+08:00 Yingxin Cheng <yingxincheng at gmail.com
> <mailto:yingxincheng at gmail.com>>:
>
>     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.
>
>
> +1 for the concern, this is good point. +1 for the hide os-capability
> behind the placement service and expose consistent interfaces.
>
>
>
>     So IMHO, the possible solution is:
>     * Let each services (Nova, Ironic ...) themselves manage their
>     capabilities under proper namespaces such as "compute", "ironic" or
>     "storage";
>
>
> Actually I think we won't catalog the capabilities by services, we will
> catalog the capabilities by resource types. Like nova and ironic may
> share some capabilities, due to they provider compute resource.
>
>
>     * 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.
>
>
> This solution sounds complex for me, you need define the capabilities
> many different places(in os-capabilities for cross-project caps, in each
> service for project-only caps), and this may leads to different service
> define same caps but with own naming. And due to the dependence is a
> library. When you upgrade the os-capabilities, you have to restart all
> the services.
>
> I'm thinking of another solution:
>
> 1. os-capabilities just define the capabilities into the JSON/YAML files.
> 2. We expose the capabilities through the REST API of placement engine,
> this REST API will read the capabilities from the JSON/YAML files
> defined by os-capabilities.
>
> This resolves some problems as below:
> 1. your concern, hide the os-capabilities behind one single API
> 2. when os-capabilities upgrade, you needn't update all the
> os-capabilities library for all control nodes. You only need update the
> os-capabilities for the node running placement engine. Due to the
> capabilities in the JSON/YAML files, you even needn't restart the
> placement engine service.
>
> But yes, this also can be done by glance metadata API.

Yeah, I think hiding the catalog of constant trait strings behind the 
placement API is probably a good thing to do.

However, I envision that os-traits (I'm now calling it this...) will 
contain some modules for discovery of various traits on a resource 
provider as well as modules that can detect conflicts in a request for a 
list of traits. Those modules would clearly be something that various 
services would want to import, irrespective of the import of the 
constant trait string catalog.

Thoughts?
-jay