[openstack-dev] [nova][placement] update_provider_tree design updates

Jim Rollenhagen jim at jimrollenhagen.com
Fri Mar 16 14:41:37 UTC 2018

> ...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
on the fly when they are removed in Ironic. Any other traits that
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>

More information about the OpenStack-dev mailing list