<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-20 11:08 GMT-07:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/18/2016 01:45 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 7/15/2016 8:06 PM, Alex Xu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Actually I still think aggregates isn't good for Manage Caps, just as I<br>
said in previous reply about Aggregates. One of reason is just same with<br>
#2 you said :) And It's totally not managable. User is even no way to<br>
query a specific host in which host-aggregate. And there isn't a<br>
interface to query what metadata was related to the host by<br>
host-aggregate. I prefer just keep the Aggregate as tool to group the<br>
hosts. But yes, user still can use host-aggregate to manage host with<br>
old way, let's user decide what is more convenient.<br>
</blockquote>
<br>
+1 to Alex's point. I just read through this thread and had the same<br>
thought. If the point is to reduce complexity in the system and surface<br>
capabilities to the end user, let's do that with resource provider tags,<br>
not a mix of host aggregate metadata and resource provider tags so that<br>
an operator has to set both, but also know in what situations he/she has<br>
to set it and where.<br>
</blockquote>
<br></span>
Yeah, having the resource provider be tagged with capabilities versus having to manage aggregate tags may make some of the qualitative matching queries easier to grok. The query performance won't necessarily be any better, but they will likely be easier to read...<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm hoping Jay or someone channeling Jay can hold my hand and walk me<br>
safely through the evil forest that is image properties / flavor extra<br>
specs / scheduler hints / host aggregates / resource providers / and the<br>
plethora of scheduler filters that use them to build a concrete<br>
picture/story tying this all together. I'm thinking like use cases, what<br>
does the operator need to do<br>
</blockquote>
<br></span>
Are you asking how things are *currently* done in Nova? If so, I'll need to find some alcohol.<br>
<br>
If you are asking about how we'd *like* all of the qualitative things to be requested and queried in the new placement API, then less alcohol is required.<br>
<br>
The schema I'm thinking about on the placement engine side looks like this:<br>
<br>
CREATE TABLE tags (<br>
  id INT NOT NULL,<br>
  name VARCHAR(200) NOT NULL,<br>
  PRIMARY KEY (id),<br>
  UNIQUE INDEX (name)<br>
);<br>
<br>
CREATE TABLE resource_provider_tags (<br>
  resource_provider_id INT NOT NULL<br>
  tag_id INT NOT NULL,<br>
  PRIMARY KEY (resource_provider_id, tag_id),<br>
  INDEX (tag_id)<br>
);<br>
<br>
On the Nova side, we need a mechanism of associating a set of capabilities that may either be required or preferred. The thing that we currently use for associating requested things in Nova is the flavor, so we'd need to define a mapping in Nova for the tags a flavor would require or prefer.<br>
<br>
CREATE TABLE flavor_tags (<br>
  flavor_id INT NOT NULL,<br>
  tag_name VARCHAR(200) NOT NULL,<br>
  is_required INT NOT NULL<br>
);<br>
<br>
We would need to have a call in the placement REST API to find the resource providers that matched a particular set of required or preferred capability tags. Such a call might look like the following:<br>
<br>
GET /resource_providers<br>
{<br>
  "resources": {<br>
    "VCPU": 2,<br>
    "MEMORY_MB": 2048,<br>
    "DISK_GB": 100<br>
  },<br>
  "requires": [<br>
    "storage:ssd",<br>
    "compute:hw:x86:avx2",<br>
  ],<br>
  "prefers": [<br>
    "compute:virt:accelerated_whizzybang"<br>
  ]<br>
}<br></blockquote><div><br></div><div>so GET with a request body? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Disregard the quantitative side of the above request right now. We could answer the qualitative side of the equation with the following SQL query in the placement engine:<br>
<br>
SELECT rp.uuid<br>
FROM resource_providers AS rp, tags AS t1, tags AS t2, tags AS t3<br>
INNER JOIN resource_provider_tags AS rpt1<br>
ON <a href="http://rp.id" rel="noreferrer" target="_blank">rp.id</a> = rpt1.resource_provider_id<br>
AND rpt1.tag_id = <a href="http://t1.id" rel="noreferrer" target="_blank">t1.id</a><br>
INNER JOIN resource_provider_tags AS rpt2<br>
AND rpt1.resource_provider_id = rpt2.resource_provider_id<br>
AND rpt2.tag_id = <a href="http://t2.id" rel="noreferrer" target="_blank">t2.id</a><br>
LEFT JOIN resource_provider_tags AS rpt3<br>
ON <a href="http://rp.id" rel="noreferrer" target="_blank">rp.id</a> = rpt3.resource_provider_id<br>
AND rpt3.tag_id = <a href="http://t3.id" rel="noreferrer" target="_blank">t3.id</a><br>
GROUP BY rp.uuid<br>
ORDER BY COUNT(COALESCE(rpt3.resource_provider_id, 0)) DESC<br>
WHERE <a href="http://t1.name" rel="noreferrer" target="_blank">t1.name</a> = 'storage:ssd'<br>
AND <a href="http://t2.name" rel="noreferrer" target="_blank">t2.name</a> = 'compute:hw:x86:avx2'<br>
AND <a href="http://t3.name" rel="noreferrer" target="_blank">t3.name</a> IN ('compute:virt:accelerated_whizzybang')<br>
<br>
The above returns all resource providers having the 'storage:ssd' and 'compute:hw:x86:avx2' tags and returns resource providers *first* that have the 'compute:virt:accelerated_whizzybang' tag.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, what does the end user of the cloud need<br>
to do, etc. I think if we're going to do resource providers tags for<br>
capabilities we also need to think about what we're replacing. Maybe<br>
that's just host aggregate metadata, but what's the deprecation plan for<br>
that?<br>
</blockquote>
<br></span>
Good question, as usual. My expectation would be that in Ocata, when we start adding the qualitative aspects to the placement REST API, we would introduce documentation that operators could use to translate common use cases that they were using flavor extra_specs and aggregate metadata for in the pre-placement world to the resource provider tags setup that would replace that functonality in the placement API world. Unlike most of the quantitative side of things, there really isn't a good way to "autoheal" or "autosetup" these things.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is a ton to talk about here, so I'll leave that for the midcycle.<br>
But let's think about what, if anything, needs to land in Newton to<br>
enable us working on this in Ocata - but our priority for the midcycle<br>
is really going to be focused on what things we need to get done yet in<br>
Newton based on what we said we'd do in Austin.<br>
<br>
Also, a final nit - can we please be specific about roles in this thread<br>
and any specs? I see 'user' thrown around a lot, but there are different<br>
kinds of users. Only admins can see host aggregates and their metadata.<br>
And when we're talking about how these tags will be used, let's be clear<br>
about who the actors are - admins or cloud users. It helps avoid some<br>
confusion.<br>
</blockquote>
<br></span>
Correct. ONLY administrators can set, delete and associate tags with resource providers. End users only see a flavor name IMHO. It would be up to the deployer to document for end users whether and what capabilities a particular flavor provides...<br></blockquote><div><br></div><div>One more for end users: Capabilities Discovery API, it should be 'GET /resource_providers/tags'. Or a proxy API from nova to the placement API....?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>