<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-14 10:38 GMT+08:00 Cheng, Yingxin <span dir="ltr"><<a href="mailto:yingxin.cheng@intel.com" target="_blank">yingxin.cheng@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 7/14/16, 05:42, "Ed Leafe" <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br>
On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin <<a href="mailto:yingxin.cheng@intel.com">yingxin.cheng@intel.com</a>> wrote:<br>
> 4. Capabilities are managed/grouped/abstracted by namespaces, and scheduler can make decisions based on either cap_names or cap_namespaces<br>
> 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.<br>
<br>
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.<br>
<br>
<br>
</span>Thanks for the feedback!<br>
<br>
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:<br>
1. We want to manage capabilities in only ONE place, either in host aggregates, compute_node records or with resource_provider records.<br>
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.<br>
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.<br>
4. It’s logically correct to store caps with resource_providers, because caps are actually owned by nodes or resource pools.<br>
5. Scheduling will be faster if resource-providers are directly attached with caps.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Regards<br>
Yingxin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>