>
> ...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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
