cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <>
Subject Re: KVM development, libvirt
Date Thu, 06 Jun 2013 05:10:21 GMT
On Wed, Jun 05, 2013 at 05:39:16PM +0000, Edison Su wrote:
> 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).

+1 - need more people focussed on cloudstack-infra in general.

> > -----Original Message-----
> > From: Marcus Sorensen []
> > Sent: Wednesday, June 05, 2013 9:03 AM
> > To:
> > 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.

At the very least - we should test for the versions of OS we decide to
support. I use a base CentOS and install all packages from bare OS to
cloudstack management / agent start. But I haven't been able to
automate the kickstarts for Ubuntu. If *anyone* has got that working,
please enlighten the list, then I can include ubuntu tests for
packaging on the test infrastructure so we don't have to constantly
test these things manually.

> > 
> > 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.
> > 

I think we need to have that included for hypervisors too. I often
find that XCP becomes the bastard child in these situations. It would
be nice to have people include their version of hypervisor/OS but
since most are testing devcloud as recommended in our test procedure I
daresay we'll catch much. All this needs to be automated.

(Any cloudstack clouds out there want to provide some tenant accounts
where I can run some packaging tests for different OSes?)

> > 
> > 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.

Please bring them forward.


Powered by

View raw message