<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...then there's no way I can know ahead of time what all those might be.<br>
 (In particular, if I want to support new devices without updating my<br>
code.)  I.e. I *can't* write the corresponding<br>
provider_tree.remove_trait(...<wbr>) condition.  Maybe that never becomes a<br>
real problem because we'll never need to remove a dynamic trait.  Or<br>
maybe we can tolerate "leakage".  Or maybe we do something<br>
clever-but-ugly with namespacing (if<br>
trait.startswith('CUSTOM_DEV_<wbr>VENDORID_')...).  We're consciously kicking<br>
this can down the road.<br>
<br>
And note that this "dynamic" problem is likely to be a much larger<br>
portion (possibly all) of the domain when we're talking about aggregates.<br>
<br>
Then there's ironic, which is currently set up to get its traits blindly<br>
from Inspector.  So Inspector not only needs to maintain the "owned<br>
traits" list (with all the same difficulties as above), but it must also<br>
either a) communicate that list to ironic virt so the latter can manage<br>
the add/remove logic; or b) own the add/remove logic and communicate the<br>
individual traits with a +/- on them so virt knows whether to add or<br>
remove them.</blockquote><div><br></div><div>Just a nit, Ironic doesn't necessarily get its traits from inspector.</div><div>Ironic gets them from *some* API client, which may be an operator, or</div><div>inspector, or something else. Inspector is totally optional.</div><div><br></div><div>Anyway, I'm inclined to kick this can down the road a bit, as you mention.</div><div>I imagine that the ideal situation is for Ironic to remove traits from placement</div><div>on the fly when they are removed in Ironic. Any other traits that nova-compute</div><div>knows about (but Ironic doesn't), nova-compute can manage the removal </div><div>the same way as another virt driver.</div></div></div></div>