Open Stack

2016-08-15 12:56 GMT+08:00 Yingxin Cheng <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.


> My two cents,
> Yingxin
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160815/9db3907b/attachment.html>