Open Stack

On 5 April 2013 03:13, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Thu, Apr 04, 2013 at 12:27:29PM +1300, Robert Collins wrote:
>>
>> Perhaps we can collaborate on having a common API for creating images,
>> with multiple backends - one oz for super generality, and one
>> diskimage-builder for fast creation?
>
> There is much more than just speed to consider here - there are a great
> many downsides to the chroot based approach IMHO, to the extent that I
> don't think it is worthwhile going down that route.
>
> First of all a chroot based approach is not taking advantage of the
> OS distro's installer, so you have to writen a load of custom install

s/taking advantage of/having to deal with/.

We don't run installers in the chroot based approach. We *start* with
cloud images published by the distro vendor (or we separate that to a
separate concern). This removes a huge source of latency, and ensures
that any cloud specific features the vendor includes in their cloud
installs are already present.

> code for each OS to be supported. The many existing/previous chroot
> based installers show this OS specific code is very fragile and will
> frequently break when a new release comes out & is alot of work to
> maintain.

Exactly why we don't run the installer.

> You're limited by the types of OS that can bootstrapped via chroot,
> to mostly just Linux distros. No Windows, BSD, Solaris etc. Even with
> Linux OS, you can run into compatibility issues if the kernel running
> the chroot is not the same as the kernel that the OS usually uses.
> For example, at certain times glibc in Fedora is set to require a new
> minimum kernel version. So if your OpenStack is say RHEL-6 you may
> find it impossible to do a chroot install of, say, Fedora 22.

Huh? If you run it in a VM, that VM kernel can be any version. So you
can run the build in a Fedora-21 image, to get a Fedora-22 image. And
if Fedora-22 can't run in anything but its own, you could use an Oz
based image as your host image.

> Unless you boot up a guest in which run the chroot install, you are
> exposing yourself to serious security risks. If you are booting up a
> guest to run the chroot install, then you might as well just run the
> real OS installer in a guest and forget about chroot installs.

Totally agree, when running third party code.

> Installation time is going to be dominated by the time to install the
> packages actual packages, regardless of what technique is used to do
> the installation. Running the native guest installer requires booting
> a VM which has a little overhead, but as mentioned above and chroot
> tool should be run inside a throw-away guest too, otherwise you have
> unacceptable security risks to your infrastructure. So I don't really
> think there is going to be much of a compelling speed advantage to
> chroot based installs - a few % difference at best.

One of our reference images - ubuntu mysql - builds in under 5
minutes. Last time I installed Fedora it took considerably longer than
that (and the 5 minutes is dominated by qemu-img -c compression to
make the image as small as possible for internet download.
http://jenkins.tripleo.org:8080/job/autobuilt-images/elements=ubuntu%20mysql/lastBuild/
- I'd be delighted to know that you have an equally fast but much more
general solution.

> Finally there are already many chroot based installers for OS that
> exist. Given that the amount of custom code required for each OS
> to be supported, I'm not convinced it is a good use of time to be
> re-inventing this in OpenStack. For the few places which really do
> want todo chroot based installs, just use an existing tool.

Right, which is why - and let me really stress this -
*diskimage-builder is NOT an installer*. Getting an OS to install
isn't an interesting part of the problem space we're tackling, which
is building golden images for Heat.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services