Open Stack

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