OpenSolaris

Minutes from 11/8/2007 Distribution Constructor Brainstorming Meeting

Attendees:

Karen, Jack, Jean, Sarah, Dave, Sanjay, Frank, Barbara (full day)

Eric, Erik, Channing, Alok, Ginnie, Stefan Teleman (morning)

Summary of Overall Distribution Constructor design

It's been observed that many of tasks performed by the Distribution constructor is very similar to the tasks that need to be performed by the Installer. So, we want to have a way to share common components.

In order to have sharable components between Distribution Constructor and other install technologies, some parts of the Distro Constructor will be implemented as modules and some other parts will be available as utilities. The Distro Constructor will call different modules as appropriate. The diagram below illustrates the overall architecture:







Note:

Quick Notes about each component, and how it fits into the flow of Distribution Construction.

Component Selection Module

Target Instantiation Module

Transfer Module

Image Specific Processing

Distribution Constructor Utilities

Outputs

Summary of features to be supported in March 2008 release

The March 2008 release will provide very similar feature compared to the October 2007 Preview release. The major difference is the fact that these features will be implemented using the new Distro Constructor architecture as outlined above. Because of the new architecture, most of the code for the Oct 2007 preview most likely can't be reused.

What will be supported:

What MIGHT be supported:

Other topics discussed

Notes on some topics brought up during the meeting as well as topics posted on the Distro Constructor SketchPad wiki, but not covered in the other discussions above.

Fedora Revisor provides some pre-configured contents for images. That seemed to be very helpful. Are we going to do that with the Distro Constructor?

We will provide some pre-defined manifest for people to start with when constructing their own distro. We will also investigate how we can setup a space somewhere on the web for people to share their useful manifest so other users can also benefit.

Ubuntu Reconstructor seemed to have a lot of focus on making it easy for people to do custom branding. Are we going to support that in the Distro Constructor at some point.

The problem with supporting custom branding in the Distro constructor is the fact that many things that needs to be branded does not have public interfaces. If all the brandable components can be pulled out into one or more packages, this will be as simple as including the particular package(s) that have the branding information in the Distro Constructor. So, we don't think this is a problem the Distro Constructor should solve at this time.

Item 1 from Bart's notes about ensuring that the file system laid down during initial image construction is the one that gets installed on the target drive.

The suggestion Bart has in steps 1-6 is great. However, that greatly relies on using ZFS. ZFS works great on hard disks and most likely USB sticks. However, there has not been any experiment with using ZFS on CDs. Further investigation needs to be made to determine how well ZFS behaves on CD, which are read only and not random-access.

The topic of support multiple packaging systems.

We are only planning to support IPS.

Programming languages for the Distro Constructor

There's no decision as to what programming language(s) will be used for the Distro Constructor implementation. We will investigate different languages and pick one that suites Distro Constructor's purpose. Investigation will start with: Python, ksh93, C, Java.

Better approach to handling pre-configuration tasks such as Gnome's postrun. Using chroot seems too fragile.

One approach is to setup the proto area in a zone or a xVM. Then, boot up the zone, and have all the pre-configuration tasks can be executed in the isolated env.

Will Distro Constructor support different locales?

It makes sense to have this support in the Distro Constructor. If a user picks a set of locales, and indicates a default locale. The Distro Constructor can setup the default locale for the image.

How to make debugging LiveCD generated by Distro Constructor easier?

One idea is to create the image in a ZFS file system. That way, we can boot up the ZFS file system, and debug. This is quick and we have a “writable” disk in case there's any core dumps or debugging data that needs to be saved. To do this, we might need to modify some of the LiveCD SMF scripts that currently only works with LiveCD.

Topics that needs to be researched

Based on discussions in the meeting, the following items needs further research. Members of the Distro Constructor team should sign up to research one or more of the following. Inputs and help from others are of course welcomed. The following table lists topics, and what I think could be things to start the research with. In the Distribution Constructor meeting next Thurs, 11/15/2007, we will discuss some of the findings.

Topics

Suggested starting points

Who

Extended SMF

The project's status, it's manifest format, how to define/how to parse...how it
can fit all the info that we want to store in there...etc..

Karen

Target Instantiation

What does it do now? What DC needs it to do? Create ZFS filesystem,
regular directory....etc...

Jean

Transfer Module

What does it do now? What DC needs it to do? Is there any new features we need from IPS to do what we need?


GUI

Take a look at info on the IPS GUI in development. How would ours be similar
and different. How to make it into a module that can be shared by other Install components, outline any dependencies between doing the GUI and IPS features needed to do the GUI...etc...


Programming Languages

Take a look and write down the pros and cons of different programming languages...ksh93, Python, C, Java....etc... to see which one would suite us best.

Jack