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 [mailto:shadow...@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. 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. -- Prasanna., ------------------------ Powered by BigRock.com
