On 08/15/2016 12:56 AM, Yingxin Cheng wrote:
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.
It may seem unnecessary and inconvenient, but I honestly don't
anticipate it being particularly onerous for developers to keep track of.
So IMHO, the possible solution is:
* Let each services (Nova, Ironic ...) themselves manage their
capabilities under proper namespaces such as "compute", "ironic" or
"storage";
-1. What if Ironic wants to utilize a capability that is "compute" --
say, an x86 CPU instruction set extension feature? Clearly, we don't
want a situation where Ironic needs to import Nova in order to get a
list of these constants?
* 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.
User-defined capabilities should be in the placement API only I think.
There simply isn't anything to do for these in a shared library because,
well, they aren't shared things. They are deployment-specific and belong
as just data that is returned from the deployment's particular placement
API after being added as a custom trait/capability string by an
administrator.
Best,
-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
