2016-07-20 11:08 GMT-07:00 Jay Pipes <jaypi...@gmail.com>: > On 07/18/2016 01:45 PM, Matt Riedemann wrote: > >> On 7/15/2016 8:06 PM, Alex Xu wrote: >> >>> >>> Actually I still think aggregates isn't good for Manage Caps, just as I >>> said in previous reply about Aggregates. One of reason is just same with >>> #2 you said :) And It's totally not managable. User is even no way to >>> query a specific host in which host-aggregate. And there isn't a >>> interface to query what metadata was related to the host by >>> host-aggregate. I prefer just keep the Aggregate as tool to group the >>> hosts. But yes, user still can use host-aggregate to manage host with >>> old way, let's user decide what is more convenient. >>> >> >> +1 to Alex's point. I just read through this thread and had the same >> thought. If the point is to reduce complexity in the system and surface >> capabilities to the end user, let's do that with resource provider tags, >> not a mix of host aggregate metadata and resource provider tags so that >> an operator has to set both, but also know in what situations he/she has >> to set it and where. >> > > 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... > > I'm hoping Jay or someone channeling Jay can hold my hand and walk me >> safely through the evil forest that is image properties / flavor extra >> specs / scheduler hints / host aggregates / resource providers / and the >> plethora of scheduler filters that use them to build a concrete >> picture/story tying this all together. I'm thinking like use cases, what >> does the operator need to do >> > > Are you asking how things are *currently* done in Nova? If so, I'll need > to find some alcohol. > > 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. > > The schema I'm thinking about on the placement engine side looks like this: > > CREATE TABLE tags ( > id INT NOT NULL, > name VARCHAR(200) NOT NULL, > PRIMARY KEY (id), > UNIQUE INDEX (name) > ); > > CREATE TABLE resource_provider_tags ( > resource_provider_id INT NOT NULL > tag_id INT NOT NULL, > PRIMARY KEY (resource_provider_id, tag_id), > INDEX (tag_id) > ); > > 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. > > CREATE TABLE flavor_tags ( > flavor_id INT NOT NULL, > tag_name VARCHAR(200) NOT NULL, > is_required INT NOT NULL > ); > > 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: > > GET /resource_providers > { > "resources": { > "VCPU": 2, > "MEMORY_MB": 2048, > "DISK_GB": 100 > }, > "requires": [ > "storage:ssd", > "compute:hw:x86:avx2", > ], > "prefers": [ > "compute:virt:accelerated_whizzybang" > ] > } >
so GET with a request body? > > 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: > > SELECT rp.uuid > FROM resource_providers AS rp, tags AS t1, tags AS t2, tags AS t3 > INNER JOIN resource_provider_tags AS rpt1 > ON rp.id = rpt1.resource_provider_id > AND rpt1.tag_id = t1.id > INNER JOIN resource_provider_tags AS rpt2 > AND rpt1.resource_provider_id = rpt2.resource_provider_id > AND rpt2.tag_id = t2.id > LEFT JOIN resource_provider_tags AS rpt3 > ON rp.id = rpt3.resource_provider_id > AND rpt3.tag_id = t3.id > GROUP BY rp.uuid > ORDER BY COUNT(COALESCE(rpt3.resource_provider_id, 0)) DESC > WHERE t1.name = 'storage:ssd' > AND t2.name = 'compute:hw:x86:avx2' > AND t3.name IN ('compute:virt:accelerated_whizzybang') > > 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. > > , what does the end user of the cloud need >> to do, etc. I think if we're going to do resource providers tags for >> capabilities we also need to think about what we're replacing. Maybe >> that's just host aggregate metadata, but what's the deprecation plan for >> that? >> > > 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. > > There is a ton to talk about here, so I'll leave that for the midcycle. >> But let's think about what, if anything, needs to land in Newton to >> enable us working on this in Ocata - but our priority for the midcycle >> is really going to be focused on what things we need to get done yet in >> Newton based on what we said we'd do in Austin. >> >> Also, a final nit - can we please be specific about roles in this thread >> and any specs? I see 'user' thrown around a lot, but there are different >> kinds of users. Only admins can see host aggregates and their metadata. >> And when we're talking about how these tags will be used, let's be clear >> about who the actors are - admins or cloud users. It helps avoid some >> confusion. >> > > 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... > 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....? > > Best, > -jay > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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