Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Michał Dulko]

On 08/25/2016 07:52 PM, Andrew Laski wrote:
>  On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote:
>> 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].
>
> To be clear, we're looking at exposing both traits and capabilities in
> Nova. This puts us in a weird spot where I think our concept of traits
> aligns with cinders capabilities, but I don't see any match for the
> Nova concept of capabilities. So I'm still open to naming suggestions
> but I think capabilities most accurately describes what it is. Dean
> has it right, I think, that what we really have are 'api capabilities'
> and 'host capabilities'. But people will end up just using
> 'capabilities' and cause confusion.

I think I need to clarify this a bit. In Cinder we're already having a
resource called "capabilities". It returns possible hardware features of
a particular volume backend, like compression or QoS support. This is
returned in a form similar to Glance's Metadata Catalog API (aka
Graffiti), so should be easily consumable by Horizon to produce a
structured UI letting admin define meaningful volume type metadata that
will enable particular backend options. As it's based on internal host
and backend names, it's rather admin-facing API. This is what in current
Nova's definition would be called "traits", right?

Now what we're looking to also expose is possible actions per
deployment, volume type, or maybe even a particular volume. An API that
will make answers to questions like "can I create a volume backup in
this cloud?", "can volumes of this type be included in consistency
groups?" easily discoverable. These are more like Nova's "capabilities".

>> 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.
>
> Here's what all of these different things look like to me:
>
> Cinder is looking to expose hardware capabilities. This pretty closely
> aligns with what traits are intending to do in Nova. This answers the
> question of "can I create a resource that needs/does X in this
> deployment?" However in Nova we ultimately want users to be able to
> specify which traits they want for their instance. That may be
> embedded in a flavor or arbitrarily specified in the request but a
> trait is not implicitly available to all resources like it seems it is
> in Cinder. We assume there could be a heterogeneous environment so
> without requesting a trait there's no guarantee of getting it.

Requesting "traits" in Cinder is still based on an admin-defined volume
types and there are no plans to change that yet, so I think that's one
of the main differences - in Nova's case "traits" API must be user-facing.

> Nova capabilities are intended to answer the question of "as user Y
> with resource X what can I do with it?" This is dependent on user
> authorization, hardware "traits" where the resource lives, and service
> version. I didn't see an analog to this in any of the proposals below.
> And one major difference between this and the other proposals is that,
> if possible, we would like the response to map to the API action that
> will perform that capability. So if a user can perform a resize on
> their instance the response might include 'POST
> .../servers//action -d resize' or whatever form we come up with.

Yup, that's basically what [1] wants to implement in Cinder. I think we
should hold up this patch until either we come up with consistent
cross-project solution, or agree that all the projects should go their
own way on this topic.

> The Glance concept of value discovery maps closely to what Nova
> capabilities are in intent in that it answers the question of "what
> can I do in this API request that will be valid?" But the scope is
> completely different in that it doesn't answer the question of which
> API requests can be made, just what values can be used in this
> specific call.
>
>
> Given the above I find that I don't have the imagination required to
> consolidate those into a consistent API concept that can be shared
> across projects. Cinder capabilities and Nova traits could potentially
> work, but the rest seem too different to me. And if we change
> traits->capabilities then we should find another name for what is
> currently Nova capabilities.
>
> -Andrew

I see similarities between Nova's and Cinder's problem space and I
believe we can come up with a consistent API here. This sounds like a
topic suitable for a cross-project discussion at the Design Summit.

[1] https://review.openstack.org/#/c/350310

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Andrew Laski]

On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote:
> 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].

To be clear, we're looking at exposing both traits and capabilities in
Nova. This puts us in a weird spot where I think our concept of traits
aligns with cinders capabilities, but I don't see any match for the Nova
concept of capabilities. So I'm still open to naming suggestions but I
think capabilities most accurately describes what it is. Dean has it
right, I think, that what we really have are 'api capabilities' and
'host capabilities'. But people will end up just using 'capabilities'
and cause confusion.


>
> 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.

Here's what all of these different things look like to me:

Cinder is looking to expose hardware capabilities. This pretty closely
aligns with what traits are intending to do in Nova. This answers the
question of "can I create a resource that needs/does X in this
deployment?" However in Nova we ultimately want users to be able to
specify which traits they want for their instance. That may be embedded
in a flavor or arbitrarily specified in the request but a trait is not
implicitly available to all resources like it seems it is in Cinder. We
assume there could be a heterogeneous environment so without requesting
a trait there's no guarantee of getting it.

Nova capabilities are intended to answer the question of "as user Y with
resource X what can I do with it?" This is dependent on user
authorization, hardware "traits" where the resource lives, and service
version. I didn't see an analog to this in any of the proposals below.
And one major difference between this and the other proposals is that,
if possible, we would like the response to map to the API action that
will perform that capability. So if a user can perform a resize on their
instance the response might include 'POST .../servers//action -d
resize' or whatever form we come up with.

The Glance concept of value discovery maps closely to what Nova
capabilities are in intent in that it answers the question of "what
can I do in this API request that will be valid?" But the scope is
completely different in that it doesn't answer the question of which
API requests can be made, just what values can be used in this
specific call.


Given the above I find that I don't have the imagination required to
consolidate those into a consistent API concept that can be shared
across projects. Cinder capabilities and Nova traits could potentially
work, but the rest seem too different to me. And if we change traits-
>capabilities then we should find another name for what is currently
Nova capabilities.

-Andrew

>
> 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  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 

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Everett Toews]

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 
> 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?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


__
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

__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Sylvain Bauza]

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?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



__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Jim Meyer]

> On Aug 15, 2016, at 10:49 AM, Doug Hellmann  wrote:
> 
> Excerpts from Jim Meyer's message of 2016-08-15 09:37:36 -0700:
>> A fast reply where others will expand further (I hope):
>> 
>>> On Aug 15, 2016, at 9:01 AM, Doug Hellmann  wrote:
>>> 
 My vote is the following:
 
 GET /capabilities <-- returns a set of *actions* or *abilities* that the 
 user is capable of performing
>>> 
>>> Does this relate in any way to how DefCore already uses "capabilities”?
>> 
>> Only a bit, and not in a way I’d be deeply concerned about.
>> 
>> The Interoperability Working Group (née DefCore) points to a specific 
>> Tempest test which asserts that a service has a “capability” and determines 
>> if that capability is “core,” thus required to be provided in this way in 
>> order to claim that the underlying cloud is an OpenStack cloud.
> 
> Do you think that the meanings of "capability of a cloud" and
> "capability of a user of a cloud" are far enough apart to avoid
> confusion?

The two contexts are distinct enough and with little enough overlap that I 
believe the set of folks who might ever discuss both at the same time is less 
than twenty.

Unless Jay takes a sudden interest in DefCore. Then it might *equal* twenty. ;D

--j


__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Andrew Laski]

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.

> 
> 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?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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Doug Hellmann]

Excerpts from Jim Meyer's message of 2016-08-15 09:37:36 -0700:
> A fast reply where others will expand further (I hope):
> 
> > On Aug 15, 2016, at 9:01 AM, Doug Hellmann  wrote:
> > 
> >> My vote is the following:
> >> 
> >> GET /capabilities <-- returns a set of *actions* or *abilities* that the 
> >> user is capable of performing
> > 
> > Does this relate in any way to how DefCore already uses "capabilities”?
> 
> Only a bit, and not in a way I’d be deeply concerned about.
> 
> The Interoperability Working Group (née DefCore) points to a specific Tempest 
> test which asserts that a service has a “capability” and determines if that 
> capability is “core,” thus required to be provided in this way in order to 
> claim that the underlying cloud is an OpenStack cloud.

Do you think that the meanings of "capability of a cloud" and
"capability of a user of a cloud" are far enough apart to avoid
confusion?

Doug

__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Jim Meyer]

A fast reply where others will expand further (I hope):

> On Aug 15, 2016, at 9:01 AM, Doug Hellmann  wrote:
> 
>> My vote is the following:
>> 
>> GET /capabilities <-- returns a set of *actions* or *abilities* that the 
>> user is capable of performing
> 
> Does this relate in any way to how DefCore already uses "capabilities”?

Only a bit, and not in a way I’d be deeply concerned about.

The Interoperability Working Group (née DefCore) points to a specific Tempest 
test which asserts that a service has a “capability” and determines if that 
capability is “core,” thus required to be provided in this way in order to 
claim that the underlying cloud is an OpenStack cloud.

> 
>> 
>> GET /traits <-- returns a set of *adjectives* or *attributes* that may 
>> describe a provider of some resource

+1 for where this is going.

—j

__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Jay Pipes]

On 08/15/2016 12:01 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-08-15 10:33:49 -0400:

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


Does this relate in any way to how DefCore already uses "capabilities"?


Sorry, I have no idea, Doug :( I don't really pay attention to defcore. 
Could you explain how defcore uses the term capabilities, please?


Thanks!
-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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2016-08-15 10:33:49 -0400:
> 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

Does this relate in any way to how DefCore already uses "capabilities"?

Doug

> 
> GET /traits <-- returns a set of *adjectives* or *attributes* that may 
> describe a provider of some resource
> 
> 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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Mooney, Sean K]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Monday, August 15, 2016 3:34 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova][API] Need naming suggestions for
> "capabilities"
> 
> 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_capabilitie
> > s/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
> 
> I can rename os-capabilities to os-traits, which would make Sean Mooney
> happy I think and also clear up the terminology mismatch.
[Mooney, Sean K] yep I like that suggestion though I'm fine with either.
os-traits is nice and short and I like the delineation between attributes and 
abilities.
> 
> 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

__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Jay Pipes]

On 08/15/2016 10:50 AM, Dean Troyer wrote:

On Mon, Aug 15, 2016 at 9:33 AM, Jay Pipes > wrote:

On 08/15/2016 09:27 AM, Andrew Laski wrote:

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

I can rename os-capabilities to os-traits, which would make Sean
Mooney happy I think and also clear up the terminology mismatch.


/me didn't stop writing previous email to read this first...

I think traits may be preferable to what I wrote a minute ago (using
qualifiying words) as this definition maintains separation for the
semantics of 'what can I do' vs 'what am I like'.

Plus 'trait' is a word that if/when surfaced into the UI will not
collide with anything else yet (that I know of).  It is a lot like how
OSC uses 'property', but may not be totally incompatible.


Right, the difference being a property has a key/value structure whereas 
a trait in this context is a simple string tag structure.


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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Dean Troyer]

On Mon, Aug 15, 2016 at 9:33 AM, Jay Pipes  wrote:

> On 08/15/2016 09:27 AM, Andrew Laski wrote:
>
>> 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
>
> I can rename os-capabilities to os-traits, which would make Sean Mooney
> happy I think and also clear up the terminology mismatch.
>

/me didn't stop writing previous email to read this first...

I think traits may be preferable to what I wrote a minute ago (using
qualifiying words) as this definition maintains separation for the
semantics of 'what can I do' vs 'what am I like'.

Plus 'trait' is a word that if/when surfaced into the UI will not collide
with anything else yet (that I know of).  It is a lot like how OSC uses
'property', but may not be totally incompatible.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Dean Troyer]

On Mon, Aug 15, 2016 at 8:27 AM, Andrew Laski  wrote:

> 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.
>

We have spent a good amount of time thinking about naming resources in
OpenStackClient and I think you have just stated what I would see as the
best compromise here, just qualifying 'capability' to get specific.  There
are far too many things in OpenStack to be able to use bare words to name
anymore, we passed that a while back.

Even though this hinges on using capability slightly differently (actions
vs properties), 'api capability' and 'host capability' are themselves a
good solution, if not ideal.

If the difference between action and property is too strong to overcome, I
would suggest just using 'host property' or 'host attribute'.  It looks
like that list will include a variety of specific things, all of which
though are intended to convey information about the host.

Also, if these terms get surfaces to the user-visible level, I would like
to see them fit existing usage as much as possible so we don't get another
version of the 'metadata' vs 'properties' debate.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Jay Pipes]

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


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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

[Andrew Laski]

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?

__
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