Jan Damborsky wrote: > 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. >
That's kind of what I had inferred from the proposals ;-) > 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 ? > raidz's as well. And probably file systems to create in a pool, which is something that's currently hard-coded for the root pool. > 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. > Yes, I think there's significant need there. Dave
