Open Stack

On 7/14/16, 12:18, "Edward Leafe" <ed at leafe.com> wrote:
    On Jul 13, 2016, at 9:38 PM, Cheng, Yingxin <yingxin.cheng at intel.com> wrote:
    >>    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.
    
    Oh, I think you misunderstood me. Capabilities definitely belong with resource providers, not host aggregates, because not all RPs are hosts.
    I'm thinking that host aggregates themselves are equivalent to capabilities for hosts. Imagine we have 10 hosts, and put 3 of them in an aggregate. How is that different than if we give those three a tag with the 'host_agg' namespace, and with tag named for the agg?
    I'm just thinking out loud here. There might be opportunities to simplify a lot of the code between capability tags and host aggregates in the future, since it looks like host aggs are a structural subset of RP capability tags.
    
    -- Ed Leafe
    

Your concerns are correct. The major goal of “Capability Tags” series is to *replace* existing capability-like functionalities in Nova and Scheduler with a more generic and extensible implementation.

As you said, host aggregates themselves are equivalent to capabilities for hosts. We should continue support this way with the new “Capability Tags” implementation. Currently users can write free-formed metadata to host aggregates, then scheduler can process them through “AggregateImagePropertiesIsolation” and “AggregateInstanceExtraSpecsFilter”, when users can specify those caps in image-props and flavor extra-specs. This means we need to support capability tags in group granularity, i.e. to tag caps to host aggregates. It can be in a separate implementation called “Aggregate Capability Tags”, replacing current implementation with the two mentioned aggregate filters.

As for “Resource Provider Capability Tags”, we are managing capabilities in a finer granularity: host and resource pool level. Currently users can only use pre-defined caps such as “architecture”, “hypervisor-types”, “hypervisor-versions” and “vm-mode” in host states, which can be processed by “ImagePropertiesFilter” and “ComputeCapabilitiesFilter” and “JsonFilter”, when users can specify them in image-props, flavor extra-specs and scheduler hints. We are designing “Resource Provider Capability Tags” to replace them and providing extensibility to add more service-defined and user-defined caps in a generic way.

The above also means we may want to manage caps in a separate table, and maintain their relationship with resource providers and host aggregates. So we can query existing caps, validate them in image-props, flavor extra-specs and scheduler hints, and manage them in a consistent way.


---
Regards
Yingxin