Peter Tribble wrote: > On Tue, 2006-06-27 at 20:42, Sarah Jelinek wrote: > >> In the document: >> >> http://www.opensolaris.org/os/community/install/files/initial_roadmap.txt >> >> There is a section with the following: >> >> <begin Engine> >> Investigate purple haze, pfinstall, >> engine options - highest priority >> Target discovery ** >> Repository discovery >> Bit mover >> Verification >> Observability >> Metadata generation >> Extensibility >> Target instantiation >> Customization of bits >> </end Engine> >> > ... > >> So, how can you get involved? Several ways: >> >> -Review the basic breakdown we provided above. Send comments, questions, >> feedback to this alias. All input is appreciated. >> > > 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. > - 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). 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. > 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. > - 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. > Software selection > - source > Repository discovery. We want to have 'repository of stuff' to choose for installation. > - profile > Not sure what you mean here. Profile of current system? Profile of software available? > - conflict resolution > Verification. Software verification is what this means in terms of the engine. > Software installation > - slurp bits to disk > > Bit mover. > 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... -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. -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. -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.
Does this help? thanks, sarah
