[ https://ovirt-jira.atlassian.net/browse/OVIRT-612?page=com.atlassian.jira... ] Barak Korren commented on OVIRT-612: ------------------------------------ {quote} Barak Korren If oVirt support to qcow2 images to create new VMs, so it's possible to use them on top of oVirt. However, I guess the best options is host them on 'resources.ovirt.org' to make available anyone (using oVirt or not) to download them. About the 'libguestfs.org' style index file we can for sure use the same to support virt-builder or Lago. {quote} oVirt can useQCOW2 images, but its not trivial to make them available for it to use, at least not until [BZ1343077|https://bugzilla.redhat.com/show_bug.cgi?id=1343077] makes it out the door. {quote} About an automated build, we also can provide this, even with only 4 releases by year. We are using the infrastructure of GitHub (where our source control is hosted) to provide the RPMs and DEBs we build, so since a new version is available there, a new task to create an image with them can be set up. For that, I guess we also need access to oVirt Jenkins to create and configure the tasks, if possible. {quote} It it fairly easy to get stuff running on the oVirt Jenkins, all you need is a repo in oVirt Gerrit (if you don't have one, I can make one for you), and have scripts inside that repo that comply with the [oVirt CI standards|http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards.html]. Once you have those running and creating images, we can cover the extra mile of getting the images on resources.ovirt.org. We need to consider how to structure the repos though, would we have one repo for all the images, or one per-image, or perhaps one repo with a branch per-image. With one repo, the build time can be longer, although you could try to parallelise from inside the build script (may be hard to debug). With multiple repos, you use more Gerrit resources and have more manual maintenance, but you can get Jenkins to parallelise for you. With branches, you can have Jenkins parallelise and 'git diff' can make maintenance easier, but you violate the principle of least surprise by making 'master' not mean what people are used to having it mean. -- This message was sent by Atlassian JIRA (v1000.98.4#100004)