> FWIW, I do actually agree with not exposing plugin points to things > that are not stable APIs and if they didn't already exist, I'd not > approve adding them. I'd actually go further and say not even the > virt driver API should be a plugin point, since we arbitrarily change > it during development any time we need to. The latter is not a serious > or practical view right now though given our out of tree Docker/Ironic > drivers. I'm just concerned that we've had these various extension > points exposed for a long time and we've not clearly articulated > that they are liable to be killed off (besides marking vif_driver > as deprecated)
Yep, I think we agree. I think that as a project we've identified exposing plug points that aren't stable (or intended to be replaceable) as a bad thing, and thus we should be iterating on removing them. Especially if we're generous with our deprecate-before-remove rules, then I think that we're not likely to bite anyone suddenly with something they're shipping while working it upstream in parallel. I *really* thought we had called this one out on the ReleaseNotes, but apparently that didn't happen (probably because we decide to throw in those helper classes to avoid breaking configs). Going forward, marking it deprecated in the code for a cycle, noting it on the release notes, and then removing it the next cycle seems like plenty of warning. --Dan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
