On 08/15/2016 03:57 AM, Alex Xu wrote:
2016-08-15 12:56 GMT+08:00 Yingxin Cheng <yingxinch...@gmail.com <mailto:yingxinch...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
