Open Stack

On Fri, 2013-04-05 at 07:36 +1300, Robert Collins wrote:
> 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.

I think I understand.  Like Vagrant, you take a known working minimal
image as your input and then build from there.  Correct?

We take install media and install scripts as input and generate a
minimal image (or, potentially, some other image flavors).  Doing this,
and doing it entirely within Nova containers, is the point of the demo
code I pointed to.

I'd be interested to know if you can use a base build generated by our
demo code as your input.  For example, the Ubuntu 12.04 image generated
by running this on a checked out copy of the code:

./create_image.py --username admin --tenant admin --password password \
  --auth-url http://10.10.10.10:5000/v2.0 \
  --glance-url http://10.10.10.10:9292/ \
  --root-password myrootpw \
  install_scripts/ubuntu-12.04-jeos.preseed

(And, I suppose, likewise with an Ubuntu image generated by Oz.)

> > code for each OS to be sppported. 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.

I believe Dan's point here is that bootstraping an image _from scratch_
using chroots is fragile, sometimes complicated and often impossible.  I
strongly agree.  Even the hypothetical example you've given of building
F22 in an F21 environment isn't always guaranteed to work without some
arm twisting.  

> 
> > 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.

If you are starting the clock at the point you launch an already
completed image, and comparing this with the time it takes for a
from-scratch Fedora install, I'd submit that you are comparing apples to
oranges :-).

But seriously, when running our Nova demo code using a CDROM in Cinder
as the install source, I've seen an F18 JEOS install finish in the 4-5
minute range.

> > 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.

Understood.  We, on the other hand, are interested in precisely the
problem of getting an OS to install, with the further restriction of
doing that install using the resources already available within an
OpenStack deployment.

I think, as you point out, these goals are complimentary.

> 
> -Rob
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Ian McLeod - Red Hat
office: 312.660.3539
mobile: 312.899.6736
rh internal: (81) 33539