- Devel - oVirt List Archives

[FYI] Blog entry about oVirt on the mainframe
by Viktor VM Mihajlovski 18 May '18

18 May '18

Hi, as some of you know the support for s390x KVM hosts has been in oVirt for a while now - without raising too much attention. The following article highlights the availability and describes how to add a mainframe to an oVirt cluster: https://kvmonz.blogspot.co.uk/2018/05/knowledge-series-managing-kvm-on-ibm-… -- Regards, Viktor Mihajlovski

2 1

Rerun-Hooks Functionality is Restored in Gerrit
by Anton Marchukov 17 May '18

17 May '18

Hello All. We have fixed the Rerun-Hooks comment functionality on gerrit.ovirt.org and you should be able to start using it now. The most common use case for this is to rerun all patchset-created hooks on a patch. Just leave a comment with: Rerun-Hooks: all and shortly you will get the hooks to be re-executed and output delivered as a gerrit comment (same as you would just submitted the patch). This also supports rerunning individual hooks. But it is a bit less straightforward as you need to know the hook file name. E.g. the following is possible: Rerun-Hooks: patchset-created.bz.1.check_bug_url, patchset-created.bz.2.check_product you can see the default hooks list at [1]. I think most of the time "Rerun-Hooks: all" will do the job and it is all you need to remember. Note that currently it is possible to rerun online patchset-created hooks. Anton. [1] https://gerrit.ovirt.org/gitweb?p=gerrit-admin.git;a=tree;f=hooks/default-h… -- Anton Marchukov Team Lead - Release Management - RHV DevOps - Red Hat

2 2

Fwd: [CentOS-devel] [Storage] Mountpoint.io: Software Defined Storage event in Vancouver in August
by Sandro Bonazzola 17 May '18

17 May '18

FYI ---------- Forwarded message ---------- From: Rich Bowen <rbowen(a)redhat.com> Date: 2018-05-16 21:47 GMT+02:00 Subject: [CentOS-devel] [Storage] Mountpoint.io: Software Defined Storage event in Vancouver in August To: "The CentOS developers mailing list." <centos-devel(a)centos.org> Forwarding on an announcement from a colleague, for those of you interested in Software-defined Storage: Our first mountpoint is coming! Software-defined Storage (SDS) is changing the traditional way we think of storage. Decoupling software from hardware allows you to choose your hardware vendors and provides enterprises with more flexibility. Attend mountpoint on August 27 - 28, 2018 in Vancouver, BC, before Open Source Summit North America for this first time event. We are joining forces with the Ceph and Gluster communities, SDS experts, and partners to bring to you an exciting 2 day event. Help lead the conversation on open source software defined storage and share your knowledge! Our CFP is open on May 3rd through June 15th, 2018. More details available, including sponsorship: https://mountpoint.io/ -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166 _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

Re: Mailing-Lists upgrade
by Marc Dequènes (Duck) 17 May '18

17 May '18

I forgot to cross-post to other lists. Please read announcement below. On 05/08/2018 12:45 PM, Marc Dequènes (Duck) wrote: > Quack, > > On 04/28/2018 09:34 AM, Marc Dequènes (Duck) wrote: > >> A few months ago we had to rollback the migration because of a nasty >> bug. This is fixed in recent versions of Mailman 3 so we're rescheduling >> it on Tuesday 8th during the slot 11:00-12:00 JST. > > Just a word to say the migration happened and no problem was detected. > > The archive posts reindexation is not finished yet, and greylisting is > slowing down things a bit, but it should soon be over. Some information > like post count and little graphs in the web UI are handled via regular > cron jobs and should also soon be accurate. > > Old links to the archives, for pre-migration posts, are still working. > Posts URLS were not stable in Mailman 2 but been synced in > https://lists.ovirt.org/pipermail/ > > You can contact me directly by mail or IRC, or open a JIRA ticket if you > hit any problem. > > \_o< >

9 20

ovirt-engine travis CI
by Sandro Bonazzola 16 May '18

16 May '18

Hi, today I pushed a fix for Travis CI on oVirt Engine. While discussing the fix it has been asked why we need Travis CI in first place, isn't our Jenkins testing enough? Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

4 6

[ANN] introducing ovirt-openshift-extensions
by Roy Golan 15 May '18

15 May '18

Hi all, Running Openshift on oVirt seems more and more attractive and is starting to get attention. It is very easy to do so today without needing any special configuration, however, to tighten the integration and to take advantage of the underlying infra provider(ovirt) we can do better. For example, oVirt can connect various storage providers, and serve disk space to containers[1][2]. Also, Openshift can ask oVirt for VMs and deploy them as master or application nodes for its usage, without making the administrator doing all that manually. This project[1] is the home for the ovirt-flexvolume-driver and ovirt-provisioner[3] and merging ovirt-cloudprovider[4] is a work in progress. The code under this repository is work-in-progress and moving quickly, however, it has automation (stdci v2 :)) and is working and does at least what you observe in the demo videos. Yet I highly appreciate if any of you that will try will provide feedback be that #ovirt channel/ mailing list or to report bugs directly in the Github project page <https://github.com/oVirt/ovirt-openshift-extensions> [1] https://github.com/oVirt/ovirt-openshift-extensions [2] https://ovirt.org/blog/2018/02/your-container-volumes-served-by-ovirt/ [3] https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/ [4] https://github.com/rgolangh/ovirt-k8s-cloudprovider Thanks, Roy

1 0

Terraform provider for oVirt
by Sandro Bonazzola 15 May '18

15 May '18

Hi, just following up from twitter[1], if any developer within oVirt knows about Terraform, there's interest on their side for collaboration developing a provider. For more info, see the github issue: https://github.com/hashicorp/terraform/issues/16150 [1] https://twitter.com/jepeltw/status/955647436931858432 -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 7

Uploaded ISO images
by Sandro Bonazzola 14 May '18

14 May '18

Hi, Just noticed that when I upload an ISO into a data domain from the browser, the content is detected as ISO but once upload finishes it's listed as Type:Image. Shouldn't it be Type:ISO? Software Version:4.2.3.5-1.el7.centos Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

4 7

Propose Dominik Holler as a Network-Backend Maintainer
by Alona Kaplan 14 May '18

14 May '18

Hi all, Dominik Holler has been working on the oVirt project for more than 1.5 years. To share some of Dominik's great stats - ~ 120 patches related to the network backend/ui ~ 95 patches for ovirt-provider-ovn ~ 44 vdsm patches ~ 80 bug fixes He was the feature owner of 'auto sync network provider', 'lldp-reporting' and 'network-filter-parameters'. For the last few months Dominik is helping review network-backend related patches and is doing a great and thorough work. Dominik showed a deep understanding of all the parts of code that he touched or reviewed. He learns fast, thorough and uncompromising. I've reviewed most of Dominik's engine related work (code and reviews). I trust his opinion and think he will be a good addition to the maintainers team. I would like to propose Dominik as a Network backend maintainer. Thanks, Alona.

10 12

[ANNOUNCE] Introducing STDCI V2
by Barak Korren 13 May '18

13 May '18

The CI team is thrilled to announce the general availability of the second version of the oVirt CI standard. Work on this version included almost a complete rewrite of the CI backend. The major user-visible features are: - Project maintainers no longer need to maintain YAML in the ‘jenkins’ repository. Details that were specified there, including targeted distributions, architectures and oVirt versions should now be specified in a YAML file under the project’s own repository (In a different syntax). - We now support “sub stages” which provide the ability to run multiple different scripts in parallel within the same STDCI stage. There is also a conditional syntax which allows controlling which scripts get executed according to which files were changed in the patch being tested. - The STDCI script file names and locations can now be customized via the above mentioned YAML file. This means that for e.g. using the same script for different stages can now be done by assigning it to the stages in the YAML file instead of by using symlinks. Inspecting job results in STDCI V2 ---------------------------------- As already mentioned, the work on STDCI V2 consisted of a major rewrite of the CI backend, one of the changes made is switching from using multiple “FreeStyle” type jobs per project to just two (pre-merge and post-merge) pipeline jobs. This has implications for the way job results are to be inspected. Since all the different parallel tasks now happen within the same job, looking at the job output can be rather confusing as it includes the merged output of all the tasks. Instead, the “Blue Ocean” view should be used. The “Blue Ocean” view displays a graphical layout of the job execution allowing one to quickly learn which parts of the job failed. It also allows drilling down and viewing the logs of individual parts of the job. Apart from using the “Blue Ocean” view, job logs are also stored as artifact files. The ‘exported-artifacts’ directory seen in the job results will now include different subdirectories for the different parts of the job. Assuming we have a ‘check-patch’ stage script running on ‘el7/x86_64’, we can find its output under ‘exported-artifacts’ in: check-patch.el7.x86_64/mock_logs/script/stdout_stderr.log Any additional artifacts generated by the script would be present in the ‘check-patch.el7.x86-64’ directory as well. I have a CI YAML file in my project already, is this really new? ---------------------------------------------------------------- We’ve been working on this for a while, and occasionally introduced V2 features into individual projects as needed. In particular, our GitHub support was always based on STDCI V2 code, so all GitHub projects (except Lago, which is ‘special’…) are already using STDCI V2. A few Gerrit-based projects have already been converted to V2 as well as part of our efforts to test and debug the V2 code. Most notably, the “OST” and “Jenkins” projects have been switched, although they are running the STDCI V1 jobs as well for the time being. What is the process for switching my project to STDCI V2? --------------------------------------------------------- The CI team is going to proactively work with project maintainers to switch them to V2. The process for switching is as follows: - Send a one-line patch to the ‘jenkins’ repo to enable the V2 jobs for the project - at this point the V2 jobs will run side-by-side with the V1 jobs, and will execute the STDCI scripts on el7/x86_64. - Create an STDCI YAML file to define the target distributions, architectures and oVirt versions for the project. (See below for a sample file that would be equivalent to what many projects have defined in V1 currently). As soon as a patch with the new YAML file is submitted to the project, the V2 job will parse it and follow the instructions in it. This allows for an easy verification of the file functionality in CI. - Remove the STDCI V1 job configuration from the ‘jenkins’ repo. This should be the last patch project maintainers have to send to the ‘jenkins’ repo. What does the new YAML file look like? -------------------------------------- We defined multiple optional names for the file, so that each project owner can choose which name seems most adequate. The following names can be used: - stdci.yaml - automation.yaml - ovirtci.yaml A dot (.) can also optionally be added at the beginning of the file name to make the file hidden, the file extension could also be “yml”. If multiple matching files exist in the project repo, the first matching file according to the order listed above will be used. The file conforms to the YAML syntax. The key names in the file are case-agnostic, and hyphens (-) underscores (_) and spaces ( ) in key names are ignored. Additionally we support multiple forms of the same word so you don’t need to remember if the key should be ‘distro’, ‘distros’, ‘distributions’, ‘operating-systems’ or ‘OperatingSystems’ as all these forms (and others) will work and mean the same thing. To create complex test/build matrices, ‘stage’, ‘distribution’, ‘architecture’ and ‘sub-stage’ definitions can be nested within one another. We find this to be more intuitive than having to maintain tedious ‘exclude’ lists as was needed in V1. Here is an example of an STDCI V2 YAML file that is compatible with the current master branch V1 configuration of many oVirt projects: --- Architectures: - x86_64: Distributions: [ "el7", "fc27" ] - ppc64le: Distribution: el7 - s390x: Distribution: fc27 Release Branches: master: ovirt-master Note: since the file is committed into the project’s own repo, having different configuration for different branches can be done by simply having different files in the different branches, so there is no need for a big convoluted file to configure all branches. Since the above file does not mention stages, any STDCI scripts that exists in the project repo and belong to a particular stage will be run on all specified distribution and architecture combinations. Since it is sometimes desired to run ‘check-patch.sh’ on less platforms then build-artifacts for example, a slightly different file would be needed: --- Architectures: - x86_64: Distributions: [ “el7”, “fc27” ] - ppc64le: Distribution: el7 - s390x: Distribution: fc27 Stages: - check-patch: Architecture: x86_64 Distribution: el7 - build-artifacts Release Branches: master: ovirt-master The above file makes ‘check-patch’ run only on el7/x86_64, while build-artifacts runs on all platforms specified and check-merged would not run at all because it is not listed in the file. Great efforts have been made to make the file format very flexible but intuitive to use. Additionally there are many defaults in place to allow specifying complex behaviours with very brief YAML code. For further details about the file format, please see the documentation linked below. About the relation between STDCI V2 and the change-queue -------------------------------------------------------- In STDCI V1 the change queue that would run the OST tests and release a given patch was determined by looking at the “version” part of the name of the project’s build-artifacts jobs that got invoked for the patch. This was confusing for people as most people understood “version” to mean the internal version for their own project rather then the oVirt version. In V2 we decided to be more explicit and simply include a map from branches to change queues in the YAML configuration under the “release-branches” option, as can be seen in the examples above. We also chose to no longer allow specifying the oVirt version as a shorthand for the equivalent queue name (E.g specifying ‘4.2’ instead of ‘ovirt-4.2’), this should reduce the chance for confusing between project versions and queue names, and also allows us to create and use change queues for projects that are not oVirt. A project can choose not to include a “release-branches” option, in which case its patches will not get submitted to any queues. Further information ------------------- The documentation for STDCI can be found at [1]. The documentation update for V2 are still in progress and expected to be merged soon. In the meatine, the GitHub-specific documentation [2] already provides a great deal of information which is relevant for V2. [1]: http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards [2]: http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHub --- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

3 4