Instead of having a nice drink in a bar, I spent this Friday night splitting the RHEL6-based OpenVZ kernel branch/repository into two, so now we have 'rhel6' and 'rhel6-testing' branches/repos. Let me explain why.
When we made an initial port of OpenVZ to RHEL6 kernel and released the first kernel (in October 2010, named 042test001), I created a repository named openvz-kernel-rhel6 (or just rhel6), and this repository was marked as "development, unstable". When, after almost a year, we announced it as "testing" and then, finally, "stable" (in August 2011, named 042stab035.1).
After that, all the kernels in that repository were supposed to be stable, because they are incremental improvements of the kernel we call stable. In theory it is. In practice, of course, there can always be new bugs (both introduced by us and by Red Hat folks releasing their kernel updates which we rebase to). Thus a kernel update from a repo which is supposed to be stable can do bad things.
Better late than never, I have fixed the situation tonight by basically renaming "rhel6" repository into "rhel6-testing", and creating a new repository called just "rhel6". For now, I put 042stab037.1 (which is the latest kernel which has passed our internal QA) into rhel6 (aka stable), while all the other kernels, up to and including 042stab039.3, are in rhel6-testing repo.
Now, very similar to what we do with RHEL5 kernels, all the new fresh-from-the-build-farm kernels will appear in rhel6-testing repo, at about the same time they go to internal QA. Then, the kernels which will have QA approval will appear in rhel6 (aka -stable) repo. What it means for you as a user is you can now choose whether to stay at the bleeding edge and have the latest stuff, or to take a conservative approach and have less frequent and delayed updates, but be more confident about kernel quality and stability.
I'm not a big fan of proprietary software, and this is an official blog of OpenVZ, not Virtuozzo — so I haven't had any plans to tell you anything about the latter. But there is one subject I really want to share with you: why Virtuozzo is good for OpenVZ.
To begin with, Virtuozzo is a commercial product based on OpenVZ software. It adds some more value: features, GUIs, tools (and there is also Virtuozzo for Windblows). The first version of Virtuozzo was released about 6 years ago, so it is not something new. Virtuozzo costs money, and is used by big corporations for mission-critical applications. Virtuozzo customers expect it to be very stable, fast, bug-free, well documented, etc. And to sell the product successfully, those expectations must be met.
But how can all this be achieved? A lot of approaches are used: from having a top-notch development team to dedicating lots of resources to testing the software. Indeed, the Virtuozzo QA team is quite large (as well as their server farm), and there are quite a few talented people (and high-end servers) working there. Those people are doing all the bad things with the kernel, trying hard to bring it down to its knees. The majority of the tests are automated, and more and more cases are added to the extensive test suite. The general idea is to find each and every bug — and fix it before the software ships to the customer.
So, good for them, but how does that affect OpenVZ? Quite simple: OpenVZ is the core of Virtuozzo, and thus it is tested and exercised in the same manner. Not too many open source projects can boast of having such great testing and as a result such high quality.
I have to admit it: this is exactly where proprietary software helps open source software. Without Virtuozzo, OpenVZ quality would definitely be lower. A dedicated quality assurance team is always needed because it's just not appealing for developers to find a new bugs in their code — they'd rather write some more.
PS Certainly the scope of "why Virtuozzo is good for OpenVZ" is much broader than just quality: for example, OpenVZ is also feature-rich because of the same reasons.
I tried it and was able to migrate a CentOS 7 container... but the Fedora 22 one seems to be stuck in the "started" phase. It creates a /vz/private/{ctid} dir on the destination host (with the same…
The fall semester is just around the corner... so it is impossible for me to break away for a trip to Seattle. I hope one or more of you guys can blog so I can attend vicariously.
Comments
Do you still stand by your opinions above now in 2016?…