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

Mooney, Sean K sean.k.mooney at intel.com
Mon Aug 15 15:54:46 UTC 2016



> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Monday, August 15, 2016 3:34 PM
> To: openstack-dev at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list