On Mon, Aug 15, 2016 at 8:27 AM, Andrew Laski <and...@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 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