Hi Kyle, > I know I'd like to be able to have it create a blank BE, and then > install it with the AI profile of my choice - and using what ever means > it normally uses during a net-boot-install (rules? lookups? etc) to find > the right profile for this host if I don't give it one. Basically a > net-install but without taking the machine down. > Ok, understood. Mike essentially said the same thing. I call this a "live" automated install. > >>> There needs to be a way to specify which disk(s) to install onto. >>> There are two parts to this: >>> - It should be possible to programatically mirror the boot environment >>> >>> >>> >> The thought here is that ZFS makes it easy to setup mirroring after the >> fact. So you can create a single disk boot pool and then attach a device >> creating a mirror later. The thing I think that needs to be considered >> is how AI users would want to get mirrors setup. Asking them to go to >> the client afterwards to setup the mirror might be the wrong thing to do. >> >> > Yes. I wouldn't really consider it an 'Automated Install' if I need to > login and attach the second mirror manually - or even automated outside > of AI.. > Ok, I will keep this in mind. Right now, we are doing as little as possible for what we consider install time requirements. So, if it is doable later, then we usually defer it until later. We want to have 'installation' only things done with the installer. In this case though, I can see that allowing for creation of the mirror root pool would make sense for the enterprise customers.
>>> - If I'm performing an automated install, I should be able to ensure >>> that the installation goes to my intended boot drive(s), not the >>> drives on the SAN (which may be enumerated in such a way that the >>> controller number is lower than the boot disks) that contain a >>> database that I'd prefer not to have to restore. >>> >>> >>> >>> >> Agree.. I didn't explicitly call this out, but we do intend to allow >> users to specify which disk to to the install on. >> >> >> > This is one area I'd like to see some innovation in. I agree with Mike > that I'd like to be able to tell AI to ignore my SAN disks, but at the > same time I'd like to not have to tweak the profile for each machine > tiype where the local disk might be c1t0, vs c0t0, etc. > > I don't know if this means some sort of 'local-only' or > 'direct-attach-only' quailfier, or a 'ignore-san', or what. But > basically I'd like something like the jumpstart 'rootdisk' only smarter > and possibly willing to take advice. For mirroring it'd be nice to have > an equivalent 'roormirror' that also hhad some brains on picking a good > second disk to mirror to. > > These are good suggestions. This is more like policy stuff, which I doubt will be part of the 1st release planned for November. But, I can see how this would be useful. thanks, sarah **** > I'm really trying to stay up at a high level of 'requirements' but I > just can't help thinking in terms of 'implementation.' Sorry. > > -Kyle > > >>> What file systems does it allow upgrade from? UFS? >>> >>> >>> >>> >> ZFS. It is a pkg image-update essentially. We don't support UFS at all. >> >> Regards, >> sarah >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > >
