----- Original Message ----- > From: "Chris Friesen" <chris.frie...@windriver.com> > To: openstack-dev@lists.openstack.org >
> Haven't seen any responses to this. > > As I see it, nova is really pushing for interoperability, but what is a > vendor > supposed to do when they have customers asking for extensions to the existing > behaviour, and they want it in a month rather than the 6-9 months it might > take > to push upstream? (Assuming its something that upstream is even interested > in.) > > I think it would be better to have an explicit method of declaring/versioning > vendor-specific extensions (even if it's not used at all by the core Nova > API) > than to have each vendor winging it on their own. In this scenario each vendor is still really winging it, as it removes the impetus for them to bring the relevent use cases and resulting requirements to the community and ultimately design/deliver an interoperable resolution - instead encouraging the continued adding of proprietary extensions. Arguably the delays seen on some features are in fact exacerbated by this kind of behaviour as if certain vendors or their users are not participating in advocating the use case then it's not clear to the rest of the community why it should be a priority. Now, all of that said, where I agree there is a pitfall here that will potentially negatively impact vendors and some operators [1] is that it seems this will on face value make it more challenging to take a feature that has landed on master and backport it to an earlier release. These feature backports of course aren't in scope for the stable branches [2], but this is one reason frequently cited as to why some operators prefer to roll their own packaging and is also something the distros do from time to time (or at least in the interests of full disclosure I can think of some instances where we have). I would note that I am not advocating a change in the policy here but just outlining something I have been thinking about lately. -Steve [1] https://etherpad.openstack.org/p/PHL-ops-packaging [2] https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes __________________________________________________________________________ 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
