2016-07-14 10:38 GMT+08:00 Cheng, Yingxin <[email protected]>: > > On 7/14/16, 05:42, "Ed Leafe" <[email protected]> wrote: > On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin <[email protected]> > wrote: > > 4. Capabilities are managed/grouped/abstracted by namespaces, and > scheduler can make decisions based on either cap_names or cap_namespaces > > 5. Placement service DON’T have any specific knowledge of a > capability, it only know the its name, namespaces, its relationship to > resource providers. They are used for scheduling, capability management and > report. > > Thinking about that a bit, it would seem that a host aggregate could > also be represented as a namespace:name tag. That makes sense, since the > fact that a host belongs to a particular aggregate is a qualitative aspect > of that host. > > > Thanks for the feedback! > > We’ve thought about the relationship between capability tags and host > aggregates carefully. And we decide not to blend it with host aggregates, > for several reasons below: > 1. We want to manage capabilities in only ONE place, either in host > aggregates, compute_node records or with resource_provider records. > 2. Compute services may need to attach discovered capabilities to its > host. It is inconvenient if we store caps with host aggregates, because > nova-compute needs to create/search host aggregates first, it can’t > directly attach caps. > 3. Other services may need to attach discovered capabilities to its > resources. So the best place is to its related resource pool, not > aggregates, nor compute_node records. Note the relationship between > resource pools and host aggregates are N:N. > 4. It’s logically correct to store caps with resource_providers, because > caps are actually owned by nodes or resource pools. > 5. Scheduling will be faster if resource-providers are directly attached > with caps. > > However, for user-defined caps, it still seems easier to manage them with > aggregates. We may want to manage them in a way different from pre-defined > caps. Or we can indirectly manage them through aggregates, but they are > actually stored with compute-node resource-providers in placement db. >
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. > > > -- > Regards > Yingxin > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
