Hey Yunhong, The thing about 'group' and 'flavor' and 'whitelist' is that they once meant distinct things (and I think we've been trying to reduce them back from three things to two or one):
- group: equivalent devices at a host level - use any one, no-one will care, because they're either identical or as near as makes no difference - flavor: equivalent devices to an end user - we may re-evaluate our offerings and group them differently on the fly - whitelist: either 'something to match the devices you may assign' (originally) or 'something to match the devices you may assign *and* put them in the group (in the group proposal) Bearing in mind what you said about scheduling, and if we skip 'group' for a moment, then can I suggest (or possibly restate, because your comments are pointing in this direction): - we allow extra information to be added at what is now the whitelisting stage, that just gets carried around with the device - when we're turning devices into flavors, we can also match on that extra information if we want (which means we can tag up the devices on the compute node if we like, according to taste, and then bundle them up by tag to make flavors; or we can add Neutron specific information and ignore it when making flavors) - we would need to add a config param on the control host to decide which flags to group on when doing the stats (and they would additionally be the only params that would work for flavors, I think)
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev