You might have noticed that we have announced a new kernel branch
named rhel5-testing a while ago (back in July,
to be more specific). The idea is pretty simple: at the same time as giving the new
kernel to our internal QA we are releasing it to rhel5-testing.
Although this change imposes some more work on me (more kernels
to release, scripts to run, changelogs to prepare), I'm pleased
to say that this model works very well. First, vendors who use
our kernels as a base for theirs (for example, OWL) now enjoy
earlier access to the sources. Second, new kernels get more
testing coverage due to OpenVZ users who choose to use this
branch. Finally, it works as a “technology preview”.
Now, let me explain why we have so strange version numbers
in the recent rhel5-testing kernels — kernels 028stab07x
are intermixed with 028stab070.y. The thing is, we still keep
updating 028stab070.y with new fixes and upstream (RHEL) updates,
while 028stab07x is a newer “sub-branch” which adds a few new
features:
live migration of containers with NFS and AutoFS mounts
iotop working in containers and the host system
Because of these new features, these kernels haven't reached the
stability yet so we keep releasing those in rhel5-testing.
Hopefully soon it will end up being stable enough and we
will abandon 028stab070.y in favor of 028stab078 (or so).
Update: this post was mostly written yesterday. Today we have just released
028stab078.1 kernel.
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?…