Open Stack

On 12 October 2013 21:35, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Fri, 11 Oct 2013 08:27:54 -0700
> Dan Smith <dms at danplanet.com> 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud