9 thoughts on - Virt-preview Repo 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

• It’s a separate repo entirely. I suspect it includes the versions that would be in N+1.

  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.

  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

• 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!

  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,

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

• 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 development in general, not just virt – these people run rawhide “

  Regards, Dario

• would be great to have something similar for CentOS as well, right ?

  Maybe we just need a better word than ‘.next’

  – KB

• 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

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