On Wed, 2006-06-28 at 22:50, Sarah Jelinek wrote: > Does this help? Indeed it does. Thanks!
> > Ack. Buzzwords. Seriously, what do the bits in the breakdown mean? > > > Fair comments and questions. I will try to map your thoughts to our > breakdown: > > I have my own mental model of how installation works: > > > > Hardware Inventory > > - install destination > > > Target discovery for hardware inventory. Target instantiation depending > on what type of install and what the user chooses. Targets can be things > like disks, zones, diskless systems, VM partitions(Xen, LDoms). A target > is anything we expect to have to lay bits down on. Ah right. I hadn't quite expanded my mental model to include Xen, LDOMs, VMware etc. > > - KVM configuration > > > This is currently part of the sysid stuff in current Solaris install. > This was kdmconfig. Not sure this is needed any more for x86 with the > new Xorg server. Never needed this for sparc(as far as I know). Depends. My experience is that this is erratic. I have a sparc and x86 system that generate a working X server configuration, but both make suboptimal resolution choices. And I'm seeing keyboard misidentification reasonably often too. > The > sysid config stuff isn't consider a part of the core engine capability > with Caiman. We consider the sysconfig stuff to be separate from the > core engine. system configuration is something that should be available > to users at all times, and the install system configuration is really a > special case of the general stuff. I consider this to be a mistake. Configuration is a core component of the installation process, so should be treated as such. Making it available at other times is fine. > > System Configuration > > - disk partitioning, raid > > > This is something we consider separate from the core engine. If you look > at the arch diagram that was sent out you see it listed as the > 'Partition Manager'. This is considered something we will keep separable > from the core engine and is a tool that will be available for general > use as well. The Engine will have to invoke and reap data from it, but > not do the work itself. There are two steps here. I see the first level (fdisk, if you like) as your partition manager earlier on. I see the second level (format, newfs [zpool, zfs]) as being integrated into the installer. > > - network etc configuration > > > We consider the sysconfig stuff to be separate from the core engine. > system configuration is something that should be available to users at > all times, and the install system configuration is really a special case > of the general stuff. I don't think we have a specific idea of what > might be different for install time configuration as opposed to general > system configuration but the separation of configuration from install is > our intended direction. I think this is a mistake. I would prefer to see it done as an integral part of the installer, and then that re-used later. I don't see the installer as just for installation, either. Certain parts of it you're unlikely to run later (target selection), but I would expect further software and configuration management to use the installation engine. > > Software selection > > - source > > > Repository discovery. We want to have 'repository of stuff' to choose > for installation. So - disk, nfs, ftp, http, download the lot from opensolaris.org? Even nicer: iso image on a local disk. > > - profile > > > Not sure what you mean here. Profile of current system? Profile of > software available? Install profile, like jumpstart. Certainly the way I think about it is that the interactive prompts up to this point generate what is essentially a jumpstart profile and sysidcfg file, and then the instllation runs from those. Even better if it saves them somewhere so that you can simply use them for jumpstart later. (Or even the ability to generate a valid sysidcfg file and jumpstart porofile from an installed system.) But generally this is the step where you choose what bits you want installed. Generally needs a lot of improvement. (Who wants to pick packages - why not supply a desktop profile, or a web server profile, or even download a list of profiles from the repository server to pick from?) One point here is that I would like the interactive installer and jumpstart to converge. > > - conflict resolution > > > Verification. Software verification is what this means in terms of the > engine. Actually, I would hope this step goes away. If there are conflicts to resolve, the previous step hasn't done its job. > > Software installation > > - slurp bits to disk > > > Bit mover. Some software/package management system or other? > > and I'm having trouble mapping this to the breakdown given. > > > > What does target mean? What are we observing? What are we > > generating metadata about? What is being extended? > > > -Target: is just the thing we are going to lay bits down on. Disks, > zones, VM partition, raid 5, diskless... I think there needs to be slightly more care taken to distinguish between the various possibilities. There are still a few possible layers. (A zone, a disk, a partition, a mirror, a slice - all are slightly different layers, and some include other layers.) Ultimately you get down to a filesystem to which bits are written, but I get the feeling that you're using target at a slightly higher level. > -Observability: is a general term meant to allow observability in to the > installation process itself. Debugging install problems is difficult > today, we want to make this easier. For you, or the user? Ideally the user wouldn't have to. Do we have ideas as to what sort of install problems are typically encountered? > -Metadata generation: is intended to convey the ability to produce a > snapshot of the current installed image for use in installing other > systems if a user should want to do this. Generate a jumpstart profile? From either the installation, or a system you want to replicate at a later time. Actually, there's another possibility, which is to run the installer interactively without doing an installation and generate the profile from that. You could play around with this quite a lot to get just the system you want. (You could even go from this to generating a custom CD image that could be used to install such a system.) I've played with several idea in this area myself. > -Extensibility: We want an engine that is extensible to allow us to add > new capabilities without too much pain. Today adding new stuff causes us > a lot of pain. Oh, absolutely. However, I think that some ideas of the sorts of capabilities that might come along later would be good, or you end up with a horrible framework that compromises the design, and simplicity has to be a key attribute. Thanks again, -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
