On 23/02/2011 00:08, Ethan Quach wrote: > On 02/18/11 04:55, Darren Kenny wrote: >> On 17/02/2011 19:31, Ethan Quach wrote: >>> On 02/16/11 04:24, Darren Kenny wrote: ... >> But given that it's unlikely that manifest/locator will actually be run in >> the >> case of a zones install - especially on a live system, I'm not sure we have >> any other choice. > > Note, this part of the design isn't run on the live system. This is the > part that supports zone configurations specified in the AI manifest of > the global system install. So in theory, manifest-locator could be > used, but I don't see an issue with the AI client itself processing this.
Ah, ok, I wasn't really sure when this was being used - but for the same reason, if it was to be used post-install, it does make sense to do it as a checkpoint. ... >>> I'll add TargetSelection to the zone checkpoint list. It doesn't sound >>> like its going differ from global zone usage. >> Oh, it will probably behave slightly differently since it's a zone install - >> e.g. we won't be telling TI to create a new rpool, but I think it can switch >> the behaviour based on the fact that a zone_rpool_dataset was provided. >> >> Actually, maybe it will need to be a separate "TargetSelectionZone" >> checkpoint >> on that basis - don't want to risk TI actually damaging and existing rpool, >> disks, etc. > > I'll see how this shakes out during implementation... Fair enough. ... >>>> 5.2.4 Transfer Logs Zone >>>> >>>> I think this requirement could be mitigated by the standard CUD checkpoint >>>> just doing the same thing and using /var/run/auto_install.<pid>/* for it's >>>> logs during an install. >>>> I would be interesting to know if people think this would be wrong >>>> for a >>>> standard install to use... >>> Yes, my intention was to make this change as part of the standard >>> Transfer Logs checkpoint, not just for zone root install. This actually >>> needs to apply to *any* temporary work files that the AI client, and any >>> of its checkpoints, need to use. So the change actually spans beyond >>> just the Transfer Logs checkpoint. >>> >>> Perhaps the main AI program code needs to set some WORKDIR variable in >>> the DOC, and all checkpoints need to base off that in creating temp files. >> Hmm, that's certainly a possibility, I'll take a look at doing this. >> >> So just to be clear, you would expect something to be in the DOC like: >> >> ApplicationParameters(DataObject): >> application_name = "auto-install" >> work_dir = "/var/run/install.PID" >> >> This is possibly something generic that we could create in install_common, >> and >> then anyone that wants to know this type of information could use it by using >> class methods like: >> >> work_dir = ApplicationParameters.get_work_dir(doc) >> >> How does that sound? > > This sounds promising. Do you think you can include this as part of > AI->CUD? If not, this is something I could probably include. Yes, I think we could do something like this if it's useful, what other information would be useful to store? Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
