Open Stack

On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote:
> Top posting with general comment...
>
> It sounds like there's some consensus in Nova-land around these traits
> (née "capabilities"). The API Working Group [4] is
> also aware of similar efforts in Cinder [1][2] and Glance [3].

To be clear, we're looking at exposing both traits and capabilities in
Nova. This puts us in a weird spot where I think our concept of traits
aligns with cinders capabilities, but I don't see any match for the Nova
concept of capabilities. So I'm still open to naming suggestions but I
think capabilities most accurately describes what it is. Dean has it
right, I think, that what we really have are 'api capabilities' and
'host capabilities'. But people will end up just using 'capabilities'
and cause confusion.


>
> If these are truly the same concepts being discussed across projects,
> it would be great to see consistency in the APIs and have the projects
> come together under a new guideline. I encourage the projects and
> people to propose such a guideline and for someone to step up and
> champion it. Seems like good fodder for a design session proposal at
> the upcoming summit.

Here's what all of these different things look like to me:

Cinder is looking to expose hardware capabilities. This pretty closely
aligns with what traits are intending to do in Nova. This answers the
question of "can I create a resource that needs/does X in this
deployment?" However in Nova we ultimately want users to be able to
specify which traits they want for their instance. That may be embedded
in a flavor or arbitrarily specified in the request but a trait is not
implicitly available to all resources like it seems it is in Cinder. We
assume there could be a heterogeneous environment so without requesting
a trait there's no guarantee of getting it.

Nova capabilities are intended to answer the question of "as user Y with
resource X what can I do with it?" This is dependent on user
authorization, hardware "traits" where the resource lives, and service
version. I didn't see an analog to this in any of the proposals below.
And one major difference between this and the other proposals is that,
if possible, we would like the response to map to the API action that
will perform that capability. So if a user can perform a resize on their
instance the response might include 'POST .../servers/<uuid>/action -d
resize' or whatever form we come up with.

The Glance concept of value discovery maps closely to what Nova
capabilities are in intent in that it answers the question of "what
can I do in this API request that will be valid?" But the scope is
completely different in that it doesn't answer the question of which
API requests can be made, just what values can be used in this
specific call.


Given the above I find that I don't have the imagination required to
consolidate those into a consistent API concept that can be shared
across projects. Cinder capabilities and Nova traits could potentially
work, but the rest seem too different to me. And if we change traits-
>capabilities then we should find another name for what is currently
Nova capabilities.

-Andrew

>
> Cheers,
> Everett
>
> [1] https://review.openstack.org/#/c/306930/
> [2] https://review.openstack.org/#/c/350310/
> [3]  https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#value-discovery
> [4] http://specs.openstack.org/openstack/api-wg/
>
>
>> On Aug 16, 2016, at 3:16 AM, Sylvain Bauza <sbauza at redhat.com> wrote:
>>
>>
>>
>> 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
>>
>>
>> ___________________________________________________________________-
>> _______
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160825/9165f20d/attachment.html>