Dave Miner wrote: > 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 ;-)
Thanks for drawing the attention to this aspect - it would be missed otherwise :-) > >> 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. This is a good suggestion. > >> 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. ok. Thank you for the comments. Jan
