Dave Miner wrote: > Jan Damborsky wrote: >> Dave Miner wrote: >>> Frank Ludolph wrote: >>>> Dave Miner wrote: >>>>> Susan Sohn wrote: >>>>>> The notes from today's meeting are at: >>>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_client_redesign_mtg_0520.txt >>>>>> >>>>>> >>>>> >>>>> The concern I have is that the focus here seems to be too much on >>>>> the single-disk case, whereas the target systems for AI are highly >>>>> likely to be servers of some sort that will mostly have multiple >>>>> disks. >>>>> >>>>> Given that, do you feel that the proposed design is really the >>>>> right one? >>>>> >>>> The discussion of the "single disk" case is actually what happens >>>> after a disk is selected. Given a system with multiple disks, one >>>> is (tentatively) selected and then the "single disk" considerations >>>> are applied. >>>> >>> >>> I expect that there are requirements to do partitioning, slicing, >>> pool creation, etc., on more than one disk target. Between that and >>> the unresolved issues in the notes about selecting a disk when there >>> is more than one, I'm concerned that it isn't quite covering the >>> right set. >> >> I agree multiple disk configuration should be on the table. >> Given the complexity it might be introduced, I think we would >> need to come with list of use cases to be supported. >> >> In general, I assume that multiple disk configuration will be >> used to create the single ZFS root pool which will be used >> as target for the installation - might it be this assumption >> correct or might it be other purposes for specifying and >> configuring more than one disk ? >> > > If you consider AI as being used for more than just installing the OS, > then yes, I think there are other use cases which involve configuring > additional pools for applications or data to use. > > The issue I sense is that we may be applying the slim install > sensibility, in which our focus is to get the OS installed and then > get out of the way, when the desired capabilities in automated > installation are much more in the realm of having a system > fully-configured and operational at the conclusion of the automated > installation process.
I see - I think we have been assuming so far that AI manifest will focus only on customization of disks which are used for OS install and Target Instantiation to prepare those disks. Then the question would be what mechanism would be provided to user to customize the rest of disks - it seems we implicitly assumed it would be done as part of post installation customization. If we decide to specify all that configuration in AI manifest, I think that we probably would like to provide the same set of customization as for target disk: * partition configuration * slice configuration * creating ZFS data pools - mirrored configurations ? Since AI manifest is static and thus might not be flexible enough to fulfill user requirements, we might need involve Derived Profiles project here, so that it is possible to generate disk configuration dynamically based on the target system configuration. Jan
