Open Stack

> In a chat with Dan Smith on IRC, he was suggesting that the important
> thing was not to use class paths in the config file. I can see that
> internal implementation should not be exposed in the config files -
> that way the implementation can change without impacting the nova
> users/operators.
> 
> Sandy, I'm not sure I really get the security argument. Python
> provides every means possible to inject code, not sure plugins are so
> different. Certainly agree on choosing which plugins you want to use
> though.

Yeah, so I don't think there's any security reason why one is better
than the other. I think that we've decided that providing a class path
is ugly, and I agree, especially if we have entry points at our disposal.

Now, the actual concern is not related to any of that, but about whether
we're going to open this up as a new thing we support. In general, my
reaction to adding new APIs people expect to be stable is "no". However,
I understand why things like the resource reporting and even my events
mechanism are very useful for deployers to do some plumbing and
monitoring of their environment -- things that don't belong upstream anyway.

So I'm conflicted. I think that for these two cases, as long as we can
say that it's not a stable interface, I think it's probably okay.
However, things like we've had in the past, where we provide a clear
plug point for something like "Compute manager API class" are clearly
off the table, IMHO.

--Dan