Open Stack

On Thu, 2013-04-04 at 15:19 +0100, Daniel P. Berrange wrote:
> On Wed, Apr 03, 2013 at 05:10:35PM -0500, Ian McLeod wrote:
> > We've put together a simple proof of concept of driving native operating
> > system installers using Nova:
> > 
> > https://github.com/redhat-openstack/image-building-poc
> > 
> > The python CLI tool in this repo, when combined with the example install
> > scripts, can build both glance-backed and cinder-backed JEOS images for
> > the following operating systems entirely inside of Nova:
> > 
> > Fedora 17, 18
> > Ubuntu 10.04, 12.04, 12.10
> > RHEL 5.9, 6.4
> > 
> > These builds can be done using network install sources and, in some
> > limited cases, DVD/ISO install sources.  Full details can be found in
> > the README.md file on github.
> > 
> > Some background discussion about this approach from earlier this year
> > can be found here:
> > 
> > https://wiki.openstack.org/wiki/NovaImageBuilding
> > 
> > The code is a bit rough around the edges but we believe the approach has
> > promise and can form the basis for a proper image building service
> > native to OpenStack.
> > 
> > I'd be grateful if anyone who's interested in the problem of image
> > building could have a look at this, give it a try and share
> > thoughts/feedback.
> > 
> > It's been developed against the packstack Folsom release but has had
> > some limited testing against devstack Grizzly installs.  Building glance
> > backed images may well be possible in earlier releases.
> > 
> > Some specific additional things I'd like to work on are:
> > 
> > * Expanding the collection of example kickstart/preseed files
> > * Adding the ability to pull kickstart/preseed files from libosinfo
> > * Adding support for installers beyond Ubuntu and Anaconda - I have
> > taken an early look at Yast but have yet to wrap my brain around the
> > bootstrap process.
> 
> IMHO the tool should not contain any kickstart files at all, nor
> explicit support for different installers. The main goal of libosinfo
> is to enable the creation of applications like this, without needing
> to have any OS specific code what-so-ever. All the OS specific info
> ought to be isolated in the libosinfo database, so that all code is
> purely metadata driven. In other words once the basic tool is created
> to use libosinfo, there should be now coding work required to support
> any other OS distros. Simply dropping in a suitable data file to the
> libosinfo data is all that should be requried for ongoing support.

> It may be that you find cases where libosinfo isn't providing enough
> metadata to avoid OS-specific python code, but that should be fairly
> rare, since the GNOME Boxes app developers have already done alot of
> work to ensure libosinfo is covering all bases.

Sourcing default install scripts (when they ar available) from libosinfo
is one of the next items on our TODO list.  As you've suggested, I
expect this will involve us wrapping libosinfo for now and applying some
OS-specific bits to the output as needed.  This will likely result in
some feature requests and/or patches flowing back to libosinfo.

Some things it currently appears to be lacking to achieve the goal of
zero OS specific code:

* Install scripts for OSes other than Fedora/RHEL and Windows:

http://git.fedorahosted.org/cgit/libosinfo.git/tree/data/install-scripts


* Substitutions within install scripts to control where the install
media is sourced from.  For example, with Anaconda:

http://fedoraproject.org/wiki/Anaconda/Kickstart#install


* Some way of expressing how to generate a boot environment that
initiates the unattended install.  This has some overlap with the
install media sourcing issue abovc.  Basically, representing the details
found here in some more abstract way:

https://github.com/redhat-openstack/image-building-poc/blob/master/image_utils.py#L398

I'll try to have a look at how the Gnome Box project is using it.

> 
> Regards,
> Daniel

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