cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: KVM development, libvirt
Date Wed, 05 Jun 2013 17:39:16 GMT
I think we miss  a VOTE from Jenkins, the vote from Jenkins should be taken as highest priority
in each release. This kind of regression should be easily identified in Jenkins(If we have
a regression test for each environment).

> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Wednesday, June 05, 2013 9:03 AM
> To: dev@cloudstack.apache.org
> Subject: KVM development, libvirt
> 
>    It looks like a bug was probably introduced into 4.1, where stock Ubuntu
> 12.04 doesn't support part of the libvirt xml format for system vms. I feel bad
> that it got in there, but I think it highlights an issue that needs to be
> addressed within our development.  Libvirt versioning is somewhat of a
> moving target. Features are introduced rapidly, and versions vary quite a bit
> between distributions and releases of those distributions. Despite this,
> we've largely ignored what libvirt we are targeting, assuming "whatever is on
> the distribution". There is the occasional discussion about this or that being
> available in libvirt x.x.x during the development cycle, but when it comes to
> qualifying the release we don't pay attention to it.
> We should. Looking at the vote for 4.1.0, several people call out which
> OS/distribution they use, but I'd like to see the libvirt version as well.
> 
> Here are some initial thoughts, please add to these if you can:
> 
> 1) When voting for a release, should we require a minimum number of votes
> FOR EACH supported OS? Meaning that we require positive test results from
> every OS listed as supported? In retrospect this seems like a no-brainer,
> however it may change the bylaws.
> 
> 
> 2) Do we want to pull libvirt out as a standalone dependency? Meaning that
> we code to a specific version and make that more visible. This could be a
> "least common denominator" type thing where we pick the lowest version
> from all supported OSes, or it could be independent of distribution,
> whatever we decide, but we would make an effort to call out the version and
> treat it independently of OS.
> 
> 3) I can think of a few things we could do in packaging to help catch
> versioning, but I'm not sure they would entirely address the issues.

Mime
View raw message