Hi Dave, On 04/05/2011 16:05, Dave Miner wrote: > On 05/ 4/11 06:49 AM, Darren Kenny wrote: ... >>> >>> ai_manifest.xml: >>> >>> 22: start date on copyright should have stayed at 2008 >> >> Fixed. >> >>> >>> 114: The old manifest was showing the combination of these two >>> properties applied together. The change doesn't seem the same. >> >> Does this read better? >> ... >> > > I think you got the wrong stanza here; I was commenting on the disk_prop > example of vendor and size that is at 112 in the old manifest, 112-116 > in your new one.
Ah, ok - I've added the combined version back in too... >>> auto_install.py >>> >>> 150 and others [esp. determine_profile_type()]: Ethan's zones spec says >>> that -m is used for manifests, -p for SCI profiles. The usage here is >>> -p for manifests (the prior, and confusing usage/terminology). Perhaps >>> you can fix this now so that the QE tests converge sooner than later and >>> the terminology doesn't cause developers to create bugs based on a >>> misunderstanding of what profile means? >> >> We can change to using -m easy enough. >> >> Do you want us to add the -p option here? Right now SCI profiles are picked >> up >> from the location that manifest-locator downloads to. > > The latest, hopefully final agreement with zones is to use -c for > profiles, -m for manifests. You and Ethan decide whether putting -c > (formerly -p) in before him is right or not. > I've changed to -m, I'll leave it to Ethan to do the -c option. ... >>> 315: If we're always going to send debug-level to the service log as >>> implied at 297, is there really a reason to have -v? >> >> If you're happy for us to always send debug information to the log, then >> we're >> happy to remove the -v option. >> >> If not, then we could easily toggle the level for the file based on the -v >> option between INFO and DEBUG. >> > > Kind of on the fence here. To some extent it would be nice to have a > very detailed log always so we wouldn't be dependent on having to > reproduce a run to get details when needed. But I'm not sure that's so > great to always have an enormous log kicking around, either. My feeling on this is that given we've got "console" output, there is less of a requirement for people to have to look at the contents of the install_log just to monitor progress. But I it's already well document what people need to do to provide debug logs, so I think we should probably stick to the existing mechanism for consistency. >>> >>> 480: It would be nice if we could set the dataset for the engine to take >>> snapshots of during the install process. This would seemingly be >>> helpful in debugging issues with all of the post-TI checkpoints. >> >> Do you mean to enable resuming of checkpoints? >> > > Not really. That's certainly not a requirement here. > >> Or do you mean just to be able to access the snapshotted DOC at the time >> things broke? >> > > Snapshotted DOC as well as the install dataset. OK, we'll look into what's possible. > >> The engine does tend to snapshot to temporary files if there is no ZFS >> dataset, but it also tends to clean up after itself... >> > > We definitely would need to clean up at the end of a successful install > (could provide a way to disable this for debugging, perhaps). I've asked Karen what's possible to do. > >>> >>> 567: what's the use case for -d? Do we really need to bother? >> >> I'd prefer to fail if there was no manifest specified, similarly I think the >> -d option really isn't all that useful on it's own for a normal install. >> >> I would certainly prefer to remove it. >> > > If QE isn't depending on it, then I think we should. > OK, I'll check with QE first. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
