<div dir="ltr">Hey Yunhong,<br><div class="gmail_extra"><span lang="EN-US"><br></span>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):<br>

<div class="gmail_quote"><br></div><div class="gmail_quote">- 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<br></div><div class="gmail_quote">

- flavor: equivalent devices to an end user - we may re-evaluate our offerings and group them differently on the fly<br></div><div class="gmail_quote">- 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)<br>

<br><div>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):<br><br></div><div>- we allow extra information to be added at what is now the whitelisting stage, that just gets carried around with the device<br>

</div><div>- 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)<br>

</div><div>- 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)<br></div></div>

</div></div>