Hi Mike, > On Fri, Jun 13, 2008 at 12:04 PM, Sarah Jelinek <Sarah.Jelinek at sun.com> > wrote: > >> Hi Mike, >> >> Mike Gerdts wrote: >> >>> I would find quite helpful to be able to perform an installation into >>> an alternate boot environment. That is, while I am running a >>> production workload I should be able to perform a fresh installation >>> using the same profiles, rules, and pre/post automation as I would use >>> if I were performing a network-based installation. >>> >> Are you talking a 'live' installation utilizing the AI profile? That is >> using the profile used to generate the initial BE on the system with AI, to >> install the alternate BE? >> > > Yes. > > Got it, noted. I think it makes sense for us to enable doing a live AI. I can't see a reason we couldn't do this. It isn't really a requirement, but we need to make sure we don't design this thing such that we cannot run it live.
>>> There should be a way to set zfs properties prior to populating the >>> boot environment. For example, if I need to set copies, enable >>> encryption (when available), enable compression, etc. it is important >>> to do that before you write a bunch of data to the boot environment. >>> >> Parts of these attributes might be useful at install/setup time. Some of >> these can be managed with ZFS after installation. I would have to look at >> the properties provided for by ZFS to try to scope what might be appropriate >> to set at install time. >> > > Whether a mirror is added prior to laying down the image or after does > not matter much. It should not be a manual post-install task. > > Setting copies, compression, and encryption must be done before the > image is populated. Else the property is set but has no impact until > the data is re-written. Presumably there will be a feature of zfs at > some time in the future that will allow you to rewrite the data > (essential for re-keying encryption) but (1) that doesn't exist today > and (2) we can prevent a re-write of the data so we should. > > Ok, understood. I think I need to look at the properties to understand which ones are dynamically set, and those that must have a re-write to enable. > I'm not sure that it does (or does not) make sense to limit the > options that can be set in a technical manner. Documenting which ones > are supported is important but limiting which ones can be set may be > unnecessarily limiting as new zfs features come out and the installer > hasn't caught up yet. If there are any limits imposed, I would argue > that such limits should be able to be bypassed by setting the "I know > this isn't supported flag". But this is design, not requirements so I > will leave this alone for now. > > This is a hard call. Allowing more of the options means that we get more complex in our language description. And, again, we are trying to limit the things we allow to things required for 'installation'. Some of this can be set later. Let me take a look at the zfs stuff and get back to you on this. thanks, sarah **** >>> 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. >> > > Today I use JASS for fixing up the installation after the Solaris > installation is done. I have 815 lines of new or changed code > (relative to JASS 4.2) in the Finish directory alone, plus another 857 > lines in . Please don't make me add another finish script to mirror > zfs file systems - I retired the SVM mirroring finish script when > Solaris 9 came out. > > >>> - 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. >> >> >>> What file systems does it allow upgrade from? UFS? >>> >> ZFS. It is a pkg image-update essentially. We don't support UFS at all. >> > > This part is offtopic for OpenSolaris, but not for SXDE or Solaris... > > Will there be no automated upgrade path from UFS to ZFS? I tend not > to do OS upgrades anyway (technical reasons + its a great time to > clean up), but I feel the need to ask for some reason. > >
