Open Stack

2016-07-14 10:38 GMT+08:00 Cheng, Yingxin <yingxin.cheng at intel.com>:

>
> 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.
>

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: 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/20160716/480e6bab/attachment.html>