Open Stack

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