On 7/14/16, 05:42, "Ed Leafe" <e...@leafe.com> wrote:
On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin <yingxin.ch...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
