Open Stack

2016-08-16 7:31 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:

> 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.
>

If we hide the trait strings behind the placement API, there will be an API
endpoint for validate the request caps. In nova, we can access this API
directly without os-traits.

One thing I'm not sure yet, we have different virt dirvers for different
hypervisors, so whether all the virt drivers have same dependence between
traits. For example, hyperV have gen1 and gen2 which support different
caps, there are some caps are conflicts between gen1 and gen2. But maybe in
another hypervisor, those caps aren't conflicts ether other. But I didn't
find out a real use-case yet. I need dig into more.

There are two solutions in my mind
1. There aren't different dependence for traits, that is easy. The
validation API in the placement engine API is enough.
2. There are different dependence for traits. We need API for compute node
report those dependence. This isn't easy, we need model the dependence in
the placement engine. This sounds like Chris will hate this way :)

Anyway I need to dig into more.


>
> Thoughts?
> -jay
>
>
> __________________________________________________________________________
> 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/20160816/af59cbfd/attachment.html>