Open Stack

On 7/14/16, 05:42, "Ed Leafe" <ed at leafe.com> wrote:
    On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin <yingxin.cheng at intel.com> 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. 


-- 
Regards
Yingxin