Posted Aug 6, 2008 14:26 UTC (Wed) by michaelkjohnson
In reply to: Also absent...
Parent article: Building custom appliance distributions with rBuilder
Because I am not an OpenVZ expert, I'm responding only because you ask me specifically... I have not worked with OpenVZ, I have merely read some docs, so I reserve the right to be completely and utterly wrong! In particular, it is not obvious to me from the OpenVZ documentation whether there needs to be OpenVZ-specific program content within an OpenVZ guest container. I am operating on the assumption that the guest container does not require additional code. That caution aside:
Conary "groups" effectively play a similar role to OpenVZ "templates", and one image type rBuilder builds is a compressed tar archive. Because rPath Linux uses network and initscripts configuration in the RH style, the instructions for modifying the contents of any RH-based OS, including CentOS, should be relevant for modifying the contents of that tarball to make a valid cached template.
rBuilder itself is not directly related to two other ways that rPath's technology could potentially interface/interact with OpenVZ:
- Packaging with Conary the necessary tools (which I presume to be vzpkg, vzctl, vzquota and any necessary dependencies, as well as an OpenVZ kernel) to use an rPath Linux-based operating system an OpenVZ host.
- Changes to OpenVZ tools to work with Conary: The vzpkgcache utility itself knowing how to use Conary to populate a template -- something like conary update group-myappliance=myproduct.rpath.org@me:1 --root /path/to/vz/chroot which -- vzpkgcache could then deploy as it normally does. Additionally, vzpkg having Conary-specific functionality, such as passing through conary commands as it does for rpm and dpkg, and maybe recognizing system image tarballs and/or URLs to tarballs as a template source, similar to package lists.
As far as I know, the contents of an OpenVZ guest do not need to be related to the contents of the host except inasmuch as they are running under the same kernel image. So a Novell-based or Fedora-based or anything-else-based host with the OpenVZ tools installed should be able to deploy rPath-based images in an OpenVZ container.
If OpenVZ containers require specific code customization for OpenVZ, we certainly have a way to deal with it (we call it "flavors", and we have xen and vmware flavors among others). It does seem, though, that some of the customization is site-specific, which makes me think that since there is site-specific customization anyway, there's not a lot of value to match the cost of maintaining extra flavors in the base OS.
I certainly welcome responses and corrections.
to post comments)