Open Stack

>
> ...then there's no way I can know ahead of time what all those might be.
>  (In particular, if I want to support new devices without updating my
> code.)  I.e. I *can't* write the corresponding
> provider_tree.remove_trait(...) condition.  Maybe that never becomes a
> real problem because we'll never need to remove a dynamic trait.  Or
> maybe we can tolerate "leakage".  Or maybe we do something
> clever-but-ugly with namespacing (if
> trait.startswith('CUSTOM_DEV_VENDORID_')...).  We're consciously kicking
> this can down the road.
>
> And note that this "dynamic" problem is likely to be a much larger
> portion (possibly all) of the domain when we're talking about aggregates.
>
> Then there's ironic, which is currently set up to get its traits blindly
> from Inspector.  So Inspector not only needs to maintain the "owned
> traits" list (with all the same difficulties as above), but it must also
> either a) communicate that list to ironic virt so the latter can manage
> the add/remove logic; or b) own the add/remove logic and communicate the
> individual traits with a +/- on them so virt knows whether to add or
> remove them.


Just a nit, Ironic doesn't necessarily get its traits from inspector.
Ironic gets them from *some* API client, which may be an operator, or
inspector, or something else. Inspector is totally optional.

Anyway, I'm inclined to kick this can down the road a bit, as you mention.
I imagine that the ideal situation is for Ironic to remove traits from
placement
on the fly when they are removed in Ironic. Any other traits that
nova-compute
knows about (but Ironic doesn't), nova-compute can manage the removal
the same way as another virt driver.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180316/4e4ffd4b/attachment.html>