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.  

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
ry...@us.ibm.com

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to