[Engine-devel] [vdsm] upstream/downstream compat

[Dan Kenigsberg]

On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
> I've submitted some changes to start some of the work of removing the
> RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
> there's a good discussion on compatibility with downstream[1]
> And I wanted to continue that on the mailing list so we could have more
> eyes; it's not clear to me if everyone is able to see/participate in an
> inline thread to just one of my patches.
> 
> To the point; as we look at moving toward an upstream vdsm which may be
> used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
> driving actions.  I'm interested in hearing details what our
> requirements for compatibility are and which parts of the tree might be
> affected.
> 
> I'd like to posit that downstream compat is the responsibility of the
> distro versus the upstream community; though that's not a license to
> make things difficult.  IMHO, this means we can do things that help
> clean up the code or move the project in a particular direction without
> having to always worry about what the package looks like in a particular
> distro.  

Blissful upstream development is great for upstream maintainer (me), but
it leads to serious headaches for downstream maintainer with
considerable installed base (me). We have a lot of Fedoraisms and
RHELisms and RHEVisms in our code. Removing them is noble, probably
legally required, and I truly thank whomever cleans up the code. But
since there are so many of them, blind removal can add significant
burden on yours truly and his colleagues.

I would like to ask upstream to think twice before breaking downstream
compatibility. Downstream can always revert your patch, but let's make
it easier on them^Wus - have a configurable value, so that downstream
patch is a oneliner, for example. If an API must be broken, let's file a
bug on the adjacent component, so as not to surprise it.

So please, worry about how the package would look in particular distros
with considerable installed base. Discuss upgrade paths. Help make Vdsm
easily downstreamable.

> 
> The other aspect to compatibility I'd like to hear details/discussion on
> the interfaces (explicit or implicit) between vdsm and ovirt-engine.
> I rekindled a discussion[2] on at least one known issue around engine
> including the qemu machine type in the database;  Any pointers to other
> places would be helpful as I'm wrapping my head around the back and
> forth between vdsm and engine.
> 
> 
> 
> 1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
> 2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
> 
> -- 
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh at us.ibm.com