On 12 October 2013 21:35, Christopher Yeoh <[email protected]> wrote: > On Fri, 11 Oct 2013 08:27:54 -0700 > Dan Smith <[email protected]> wrote: > > If the idea is to gate with nova-extra-drivers this could lead to a > rather painful process to change the virt driver API. When all the > drivers are in the same tree all of them can be updated at the same > time as the infrastructure. > > If they are in separate trees and Nova gates on nova-extra-drivers then > at least temporarily a backwards compatible API would have to remain so > the nova-extra-drivers tests still passed. The changes would then be > applied to nova-extra-drivers and finally a third changeset to remove > the backwards compatible code. > > We see this in tempest/nova or tempest/cinder occasionally (not often > as the APIs are stable) and its not very pretty. Ideally we'd be able to > link two changesets for different projects so they can be processed as > one. But without that ability I think splitting any drivers out and > continuing to gate on them would be bad.
A fairly fundamental thing in SOA architectures - which we have here - is to make all changes backwards compatibly, it's pretty easy if you're in the habit of it - there's only a handful of basic primitives around evolving APIs gracefully - and it results in a much smoother deployment story - and ultimately thats what we're aiming at. I recognise the potential for angst around longevity of APIs and so forth, but even in a single tree with multiple patches the discipline of being careful about API evolution can reduce gating issues with patches that would otherwise conflict semantically. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
