Introducing oVirt virtual machine management via Vagrant.
It's a new year with new opportunities for oVirt to show up its virtualization features! We're getting ready for DevConf.CZ in Brno next week, and FOSDEM in Brussels the week after that! We look forward to meeting European developers and sysadmins to share your experiences!
Here's what happened in December of 2016.
The oVirt Project is pleased to announce the availability of all-new principal documentation for the oVirt 4.0 branch.
There are many people out there who are content to use software without documentation, preferring to muddle through the software based on past experience with similar software or just the desire to put the software through its paces.
We all do this; I could not tell you the last time I looked at documentation for Firefox or Chrome, because I've been using browsers for over 20 years and seriously, what else is there to learn? Until I learn about a cool new feature from a friend or a web site.
Today, when an oVirt developer pushes a patch to review on oVirt Gerrit, various validations are triggered in CI via the 'check-patch' job, as defined by the project maintainers. Usually these jobs includes 'unit-tests', 'db tests', static analysis checks, and even an occasional 'functional test'. While it might seem that it covers alot and gives a good indication that the patch is good to be merged, unfortunately it is not always the case.
The reason it's not enough lies in oVirt's complexity and the fact it's a Virtualization project, which means the only real way to know if your patch didn't break things is to install oVirt and try running a few basic commands, like 'adding host', 'adding vm', 'creating snapshots', and other tasks you can only do if you have a full oVirt system up and running. Here is where OST comes in!
All projects in oVirt CI are built today post merge, using the 'build-artifacts' stage from oVirt's CI standards. This ensures that all oVirt projects are built and deployed to oVirt repositories and can be consumed by CI jobs, developers or oVirt users.
However, on some occasions a developer might need to build his project from an open patch. Developers need this capability in order to to examine the effects of their changes on a full oVirt installation before merging those changes. On some cases developers may even want to hand over packages based on un-merged patches to the QE team to verify that a given change will fix some complex issue or to preview a new feature on its early stages of development.
oVirt's CI standards have been in use for a while in most oVirt projects and have largely been a success.
These standards have put the control of what the CI system does in the hands of the developers without them
having to learn about Jenkins and the tooling around it. The way the standards were implemented, with the
mock_runner.sh script, also enabled developers to easily emulate the CI system on their own machines to debug and diagnose issues.
In one of my last articles I described the example of installing HP System Management Tools to the physical server HP ProLiant DL360 G5 with CentOS Linux 7.2. After a while, the same exact server was used as a virtualization host and the oVirt Hosted Engine components were deployed on it. The host was put into maintenance mode recently, all packages were upgraded from the online repository, including the HP tool pack installed on it.
After the installation, I decided to check the workability of the upgraded tools. I also tried to open the web page of HP System Management homepage, but I didn’t succeed, because the host was simply blocking TCP port 2381.
As oVirt continues to grow, the many projects within the broader oVirt community are thriving as well. Today, the oVirt community is pleased to announce the addition of a new incubator subproject, Vagrant Provider, as well as the graduation of another subproject, moVirt, from incubator to full project status!
According to maintainer Marc Young, Vagrant Provider is a provider plugin for the Vagrant suite that enables command-line ease of virtual machine provisioning and lifecycle management.
oVirt's development is continuing on pace, as the calendar year draws to a close and we get ready for a new year of development, evangelism, and making virtual machine management a simple process for everyone.
Here's what happened in November of 2016.
The ovirt-engine component of oVirt is the brain of oVirt and is responsible for managing attached systems; providing the webadmin UI and REST interfaces; and other core tasks. The process of setting up a real cluster on which to deploy the project is a time-consuming task that greatly increases patch turnaround time and can provide a significant barrier of entry to those wanting to contribute to the project.