Open Stack

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 <sbauza at redhat.com<mailto:sbauza at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto: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/20160825/6b8b0e4d/attachment.html>