Open Stack

On Mon, Aug 15, 2016 at 8:27 AM, Andrew Laski <andrew at lascii.com> 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
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160815/47fd10cc/attachment.html>