Top posting with general comment... It sounds like there's some consensus in Nova-land around these traits (née "capabilities"). The API Working Group [4] is also aware of similar efforts in Cinder [1][2] and Glance [3].
If these are truly the same concepts being discussed across projects, it would be great to see consistency in the APIs and have the projects come together under a new guideline. I encourage the projects and people to propose such a guideline and for someone to step up and champion it. Seems like good fodder for a design session proposal at the upcoming summit. Cheers, Everett [1] https://review.openstack.org/#/c/306930/ [2] https://review.openstack.org/#/c/350310/ [3] https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#value-discovery [4] http://specs.openstack.org/openstack/api-wg/ On Aug 16, 2016, at 3:16 AM, Sylvain Bauza <sba...@redhat.com<mailto:sba...@redhat.com>> wrote: Le 15/08/2016 22:59, Andrew Laski a écrit : On Mon, Aug 15, 2016, at 10:33 AM, Jay Pipes wrote: On 08/15/2016 09:27 AM, Andrew Laski wrote: Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute hosts expose "capabilities" for use by the scheduler. As much fun as it would be to have the same term mean two very different things in Nova to retain some semblance of sanity let's rename one or both of these concepts. An API "capability" is going to be an action, or URL, that a user is allowed to use. So "boot an instance" or "resize this instance" are capabilities from the API point of view. Whether or not a user has this capability will be determined by looking at policy rules in place and the capabilities of the host the instance is on. For instance an upcoming volume multiattach feature may or may not be allowed for an instance depending on host support and the version of nova-compute code running on that host. A host "capability" is a description of the hardware or software on the host that determines whether or not that host can fulfill the needs of an instance looking for a home. So SSD or x86 could be host capabilities. https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py has a list of some examples. Some possible replacement terms that have been thrown out in discussions are features, policies(already used), grants, faculties. But none of those seemed to clearly fit one concept or the other, except policies. Any thoughts on this hard problem? I know, naming is damn hard, right? :) After some thought, I think I've changed my mind on referring to the adjectives as "capabilities" and actually think that the term "capabilities" is better left for the policy-like things. My vote is the following: GET /capabilities <-- returns a set of *actions* or *abilities* that the user is capable of performing GET /traits <-- returns a set of *adjectives* or *attributes* that may describe a provider of some resource Traits sounds good to me. Yeah, it wouldn't be dire, trait. I can rename os-capabilities to os-traits, which would make Sean Mooney happy I think and also clear up the terminology mismatch. Thoughts? -jay __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ 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