2016-08-15 12:56 GMT+08:00 Yingxin Cheng <[email protected]>: > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
