<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div><br></div>
<div><br></div>
<div><br></div>
<div>On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote:<br></div>
<blockquote type="cite"><div>Top posting with general comment...<br></div>
<div><br></div>
<div>It sounds like there's some consensus in Nova-land around these traits (née "capabilities"). The API Working Group [4] is <br></div>
<div>also aware of similar efforts in Cinder [1][2] and Glance [3].<br></div>
</blockquote><div><br></div>
<div>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.<br></div>
<div><br></div>
<div><br></div>
<blockquote type="cite"><div><br></div>
<div>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.<br></div>
</blockquote><div><br></div>
<div>Here's what all of these different things look like to me:<br></div>
<div><br></div>
<div>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.<br></div>
<div><br></div>
<div>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.<br></div>
<div><br></div>
<div>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.<br></div>
<div><br></div>
<div><br></div>
<div>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.<br></div>
<div><br></div>
<div>-Andrew</div>
<div><br></div>
<blockquote type="cite"><div><br></div>
<div>Cheers,<br></div>
<div>Everett<br></div>
<div><br></div>
<div>[1] <a href="https://review.openstack.org/#/c/306930/" defang_rel="noreferrer" defang_data-ss1472145685="1">https://review.openstack.org/#/c/306930/</a><br></div>
<div>[2] <a href="https://review.openstack.org/#/c/350310/" defang_rel="noreferrer" defang_data-ss1472145685="1">https://review.openstack.org/#/c/350310/</a><br></div>
<div>[3] <a href="https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#value-discovery" defang_rel="noreferrer" defang_data-ss1472145685="1"> https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#value-discovery</a><br></div>
<div>[4] <a href="http://specs.openstack.org/openstack/api-wg/" defang_rel="noreferrer" defang_data-ss1472145685="1">http://specs.openstack.org/openstack/api-wg/</a><br></div>
<div><br></div>
<div><br></div>
<div><blockquote type="cite"><div>On Aug 16, 2016, at 3:16 AM, Sylvain Bauza <<a href="mailto:sbauza@redhat.com" defang_rel="noreferrer" defang_data-ss1472145685="1">sbauza@redhat.com</a>> wrote:<br></div>
<div><br></div>
<div><div><br></div>
<div><br></div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Le
 15/08/2016 22:59, Andrew Laski a écrit :</span></span><br></div>
<div> <br></div>
<blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;-webkit-text-stroke-width:0px;" type="cite"><div>On Mon, Aug 15, 2016, at 10:33 AM, Jay Pipes wrote:<br></div>
<div> <br></div>
<blockquote type="cite"><div>On 08/15/2016 09:27 AM, Andrew Laski wrote:<br></div>
<div> <br></div>
<blockquote type="cite"><div>Currently in Nova we're discussion adding a "capabilities" API to expose<br></div>
<div> to users what actions they're allowed to take, and having compute hosts<br></div>
<div> expose "capabilities" for use by the scheduler. As much fun as it would<br></div>
<div> be to have the same term mean two very different things in Nova to<br></div>
<div> retain some semblance of sanity let's rename one or both of these<br></div>
<div> concepts.<br></div>
<div> <br></div>
<div> An API "capability" is going to be an action, or URL, that a user is<br></div>
<div> allowed to use. So "boot an instance" or "resize this instance" are<br></div>
<div> capabilities from the API point of view. Whether or not a user has this<br></div>
<div> capability will be determined by looking at policy rules in place and<br></div>
<div> the capabilities of the host the instance is on. For instance an<br></div>
<div> upcoming volume multiattach feature may or may not be allowed for an<br></div>
<div> instance depending on host support and the version of nova-compute code<br></div>
<div> running on that host.<br></div>
<div> <br></div>
<div> A host "capability" is a description of the hardware or software on the<br></div>
<div> host that determines whether or not that host can fulfill the needs of<br></div>
<div> an instance looking for a home. So SSD or x86 could be host<br></div>
<div> capabilities.<br></div>
<div> <a href="https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py" defang_rel="noreferrer" defang_data-ss1472145685="1">https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py</a><br></div>
<div> has a list of some examples.<br></div>
<div> <br></div>
<div> Some possible replacement terms that have been thrown out in discussions<br></div>
<div> are features, policies(already used), grants, faculties. But none of<br></div>
<div> those seemed to clearly fit one concept or the other, except policies.<br></div>
<div> <br></div>
<div> Any thoughts on this hard problem?<br></div>
</blockquote><div>I know, naming is damn hard, right? :)<br></div>
<div> <br></div>
<div> After some thought, I think I've changed my mind on referring to the<br></div>
<div> adjectives as "capabilities" and actually think that the term<br></div>
<div> "capabilities" is better left for the policy-like things.<br></div>
<div> <br></div>
<div> My vote is the following:<br></div>
<div> <br></div>
<div> GET /capabilities <-- returns a set of *actions* or *abilities* that the<br></div>
<div> user is capable of performing<br></div>
<div> <br></div>
<div> GET /traits <-- returns a set of *adjectives* or *attributes* that may<br></div>
<div> describe a provider of some resource<br></div>
<div> <br></div>
</blockquote><div>Traits sounds good to me.<br></div>
<div> <br></div>
</blockquote><div><br></div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Yeah,
 it wouldn't be dire, trait.</span></span><br></div>
<div> <br></div>
<div> <br></div>
<blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;-webkit-text-stroke-width:0px;" type="cite"><blockquote type="cite"><div>I can rename os-capabilities to os-traits, which would make Sean Mooney<br></div>
<div> happy I think and also clear up the terminology mismatch.<br></div>
<div> <br></div>
<div> Thoughts?<br></div>
<div> -jay<br></div>
<div> <br></div>
<div> __________________________________________________________________________<br></div>
<div> OpenStack Development Mailing List (not for usage questions)<br></div>
<div> Unsubscribe:<br></div>
<div> <a href="mailto:OpenStack-dev-request@lists.openstack.org" defang_rel="noreferrer" defang_data-ss1472145685="1">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br></div>
<div> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer" defang_data-ss1472145685="1">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</blockquote><div>__________________________________________________________________________<br></div>
<div> OpenStack Development Mailing List (not for usage questions)<br></div>
<div> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" defang_rel="noreferrer" defang_data-ss1472145685="1"> OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br></div>
<div> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer" defang_data-ss1472145685="1">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</blockquote><div><br></div>
<div><br></div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">__________________________________________________________________________</span></span><br></div>
<div> <span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">OpenStack
 Development Mailing List (not for usage questions)</span></span><br></div>
<div> <span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Unsubscribe:<span> </span></span></span><a style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;-webkit-text-stroke-width:0px;" href="mailto:OpenStack-dev-request@lists.openstack.org" defang_rel="noreferrer" defang_data-ss1472145685="1">OpenStack-dev-request@lists.openstack.org</a><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">?subject:unsubscribe</span></span><br></div>
<div> <a style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;-webkit-text-stroke-width:0px;" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer" defang_data-ss1472145685="1">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</div>
</blockquote></div>
<div><br></div>
<div><u>__________________________________________________________________________</u><br></div>
<div>OpenStack Development Mailing List (not for usage questions)<br></div>
<div>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></div>
<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer" defang_data-ss1472145685="1">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</blockquote><div><br></div>
</body>
</html>