> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
