Open Stack

2016-07-20 11:08 GMT-07:00 Jay Pipes <jaypipes at 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-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/20160720/5ccc06d8/attachment.html>