Hello! I'm looking at options for configuring an OpenStack CI job that tests OpenStack components with the latest versions of libvirt and qemu.
Fedora's virt-preview [1] repository is pretty much what we need. However, we would really rather run this job using CentOS. The job's configuration needs to work for longer than Fedora's release schedule would allow.
Is anyone looking at doing something like this for CentOS?
Thanks,
[1] http://fedoraproject.org/wiki/Virtualization_Preview_Repository
On Mon, Aug 11, 2014 at 10:30 AM, Russell Bryant rbryant@redhat.com wrote:
Hello! I'm looking at options for configuring an OpenStack CI job that tests OpenStack components with the latest versions of libvirt and qemu.
Fedora's virt-preview [1] repository is pretty much what we need. However, we would really rather run this job using CentOS. The job's configuration needs to work for longer than Fedora's release schedule would allow.
Is anyone looking at doing something like this for CentOS?
Is Fedora's virt-preview for Fedora updates, or for testing Fedora N+1?
In general, CentOS will be pulling changes directly from upstream RHEL, and so won't be able (I don't think) to provide something like that for core packages.
We can of course do that for the Virt-SIG repos; at the moment that's limited to Xen4CentOS (although we may do an updated qemu at some point). Notably, it would not include KVM. For those, having a preview for updates -- particularly updating major version (like Xen 4.2 -> 4.4) would make a lot of sense.
What exactly is it that you're hoping to test? It sounds almost like you're not hoping to test the distro, but new versions of the upstream software.
-George
On 08/11/2014 11:36 AM, George Dunlap wrote:
On Mon, Aug 11, 2014 at 10:30 AM, Russell Bryant rbryant@redhat.com wrote:
Hello! I'm looking at options for configuring an OpenStack CI job that tests OpenStack components with the latest versions of libvirt and qemu.
Fedora's virt-preview [1] repository is pretty much what we need. However, we would really rather run this job using CentOS. The job's configuration needs to work for longer than Fedora's release schedule would allow.
Is anyone looking at doing something like this for CentOS?
Is Fedora's virt-preview for Fedora updates, or for testing Fedora N+1?
It's a separate repo entirely. I suspect it includes the versions that would be in N+1.
In general, CentOS will be pulling changes directly from upstream RHEL, and so won't be able (I don't think) to provide something like that for core packages.
We can of course do that for the Virt-SIG repos; at the moment that's limited to Xen4CentOS (although we may do an updated qemu at some point). Notably, it would not include KVM. For those, having a preview for updates -- particularly updating major version (like Xen 4.2 -> 4.4) would make a lot of sense.
Yeah, I was thinking of this as a separate testing repo from the virt SIG, not updates to core repos.
For my particular use case, not having updated KVM isn't a big deal. We just need the latest qemu. All testing happens inside of a cloud VM, without any hardware virt support exposed.
What exactly is it that you're hoping to test? It sounds almost like you're not hoping to test the distro, but new versions of the upstream software.
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
On Mon, Aug 11, 2014 at 12:01 PM, Russell Bryant rbryant@redhat.com wrote:
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
But on the whole, it sounds like your goals and the goals of the Virt SIG are at odds. The Virt SIG wants to provide a stable base; the "(1)" group of people mentioned in the Fedora virt-preview wiki page. As it happens, we plan on updating our libvirt package fairly frequently at first; but that's just to get some important Xen functionality in as soon as possible. Once the Xen functionality for libvirt has stabilized, we'll probably stop. Our plan for qemu was to re-build the exact RHEL package, but with snapshotting enabled.
What you're describing would essentially be a completely separate project: designed for people (like yourselves) who want bleeding-edge versions.
Is there a reason you can't just download and build upstream qemu and libvirt yourselves, and build them on top of CentOS? That's more or less what the Xen Project automated testing infrastructure does for testing (although it uses Debian as a base rather than CentOS).
Or, if you were willing to do the maintenance on such a repo, we might consider adding such a thing into the Virt SIG. But it would be you (or other like-minded people) doing the builds either way.
-George
On 08/11/2014 01:58 PM, George Dunlap wrote:
On Mon, Aug 11, 2014 at 12:01 PM, Russell Bryant rbryant@redhat.com wrote:
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
But on the whole, it sounds like your goals and the goals of the Virt SIG are at odds. The Virt SIG wants to provide a stable base; the "(1)" group of people mentioned in the Fedora virt-preview wiki page. As it happens, we plan on updating our libvirt package fairly frequently at first; but that's just to get some important Xen functionality in as soon as possible. Once the Xen functionality for libvirt has stabilized, we'll probably stop. Our plan for qemu was to re-build the exact RHEL package, but with snapshotting enabled.
What you're describing would essentially be a completely separate project: designed for people (like yourselves) who want bleeding-edge versions.
Is there a reason you can't just download and build upstream qemu and libvirt yourselves, and build them on top of CentOS? That's more or less what the Xen Project automated testing infrastructure does for testing (although it uses Debian as a base rather than CentOS).
We could. Using existing packages would just be a bit easier. I was mainly interested if such a repo existed. I got the answer I was looking for, so thanks!
Or, if you were willing to do the maintenance on such a repo, we might consider adding such a thing into the Virt SIG. But it would be you (or other like-minded people) doing the builds either way.
OK, understood. Like you said, for my particular case, I can just build from source. I just wanted to see if what I was looking for happened to already exist.
Thanks,
On 08/11/2014 06:58 PM, George Dunlap wrote:
On Mon, Aug 11, 2014 at 12:01 PM, Russell Bryant rbryant@redhat.com wrote:
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
But on the whole, it sounds like your goals and the goals of the Virt SIG are at odds. The Virt SIG wants to provide a stable base; the "(1)" group of people mentioned in the Fedora virt-preview wiki page. As it happens, we plan on updating our libvirt package fairly frequently at first; but that's just to get some important Xen functionality in as soon as possible. Once the Xen functionality for libvirt has stabilized, we'll probably stop. Our plan for qemu was to re-build the exact RHEL package, but with snapshotting enabled.
What you're describing would essentially be a completely separate project: designed for people (like yourselves) who want bleeding-edge versions.
could we do this as a part of a -testing or -next repo, but still be a part of the VirtSIG ? I think it would be great to see some of the upstream devel stuff being built and tested, specially if it can be automated. Needing to do this manually, and curate it locally would be quite hard.
We would also need to make sure that stuff from that repo never hits a release repo on centos.org, but we can likely enforce that.
On mer, 2014-08-20 at 12:07 +0100, Karanbir Singh wrote:
On 08/11/2014 06:58 PM, George Dunlap wrote:
On Mon, Aug 11, 2014 at 12:01 PM, Russell Bryant rbryant@redhat.com wrote:
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
But on the whole, it sounds like your goals and the goals of the Virt SIG are at odds. The Virt SIG wants to provide a stable base; the "(1)" group of people mentioned in the Fedora virt-preview wiki page. As it happens, we plan on updating our libvirt package fairly frequently at first; but that's just to get some important Xen functionality in as soon as possible. Once the Xen functionality for libvirt has stabilized, we'll probably stop. Our plan for qemu was to re-build the exact RHEL package, but with snapshotting enabled.
What you're describing would essentially be a completely separate project: designed for people (like yourselves) who want bleeding-edge versions.
could we do this as a part of a -testing or -next repo, but still be a part of the VirtSIG ? I think it would be great to see some of the upstream devel stuff being built and tested, specially if it can be automated. Needing to do this manually, and curate it locally would be quite hard.
FWIW, and AFAIUI, in Fedora, the vit-preview repository contains the packages that will be part of the next to be released Fedora version (codename 'rawhide'), built for the latest released Fedora version.
This means, right now, it contains the versions of the virt software that will go in Fedora 21, build on and for Fedora 20. This is particularly useful, for example, to catch possible regressions, as the repo docs say themselves:
http://fedoraproject.org/wiki/Virtualization_Preview_Repository
"Who might be interested in virt preview? It turns out there are four kinds of people in the world.
1) Users who want things to stay stable and who aren't necessarily expecting new features until they update to the next release of Fedora - these are people with just the updates repo enabled
2) Same as (1) but who are willing to help out testing updates for the whole distro in order to catch things before they hit the people in category (1) - these people have the updates and updates-testing repos enabled
3) Mostly the same as (1) or (2), but have a specific interest in testing new virt features and are willing to deal with virt regressions - these people enable the updates, updates-testing and preview repos
4) People who are interested in helping with Fedora <next> development in general, not just virt - these people run rawhide "
Regards, Dario
On 08/20/2014 02:42 PM, Dario Faggioli wrote:
http://fedoraproject.org/wiki/Virtualization_Preview_Repository
"Who might be interested in virt preview? It turns out there are four kinds of people in the world.
would be great to have something similar for CentOS as well, right ?
Maybe we just need a better word than '.next'
- KB
On Wed, Aug 20, 2014 at 12:07 PM, Karanbir Singh mail-lists@karan.org wrote:
On 08/11/2014 06:58 PM, George Dunlap wrote:
On Mon, Aug 11, 2014 at 12:01 PM, Russell Bryant rbryant@redhat.com wrote:
That's right. We want to test OpenStack with bleeding edge versions of libvirt and qemu, but want the underlying OS to be something supported for a longer period of time than a given Fedora release. CentOS + a testing repo with that software included would be perfect.
But on the whole, it sounds like your goals and the goals of the Virt SIG are at odds. The Virt SIG wants to provide a stable base; the "(1)" group of people mentioned in the Fedora virt-preview wiki page. As it happens, we plan on updating our libvirt package fairly frequently at first; but that's just to get some important Xen functionality in as soon as possible. Once the Xen functionality for libvirt has stabilized, we'll probably stop. Our plan for qemu was to re-build the exact RHEL package, but with snapshotting enabled.
What you're describing would essentially be a completely separate project: designed for people (like yourselves) who want bleeding-edge versions.
could we do this as a part of a -testing or -next repo, but still be a part of the VirtSIG ? I think it would be great to see some of the upstream devel stuff being built and tested, specially if it can be automated. Needing to do this manually, and curate it locally would be quite hard.
Yeah, I can see the usefulness of that -- particularly with me "upstream" hat on. It's just a matter of effort and priorities. :-)
And it would be different from Fedora's virt-next, because it would be focusing on virtualization stuff coming down the pipeline from individual projects upstream, rather than virtualization stuff likely to end up in the next CentOS.
-George
On 09/01/2014 05:46 PM, George Dunlap wrote:
And it would be different from Fedora's virt-next, because it would be focusing on virtualization stuff coming down the pipeline from individual projects upstream, rather than virtualization stuff likely to end up in the next CentOS.
I think we should actually call the repo ( or the concept ) CentOS-Upstreams; and make it available across the platform. Since this conversation started, there have been a fair few requests for something of this nature.
-
Dario Faggioli -
George Dunlap -
Karanbir Singh -
Russell Bryant