Clay Baenziger wrote: > Hi Dave, > To save Jack a bit of response time, I think I can comment on why > we felt full semantic verification on the server was not possible: > We can check that all material fits appropriate formats (i.e. > disks are cNtMdO or leadville names) but we can't see that the disk > exists on the client. This boarders on semantic validation versus > install-time checks done by the engine, however, too. > The biggest question w.r.t. server side validation which was still > semantic validation and verifiable were things such as checking the IPS > server and that all packages existed there (though some reservations were > brought up about things being able to change between manifest publication > and install times). Otherwise, we couldn't come up with many checks the > server could perform, where as the client. with its more comprehensive > view of what's actually available, could check more (nearly a dry-run > before install). > Perhaps we were uninspired this late into our rather long meeting > though?
It would seem so. Wouldn't it be desirable to be able to construct a virtual validation "environment" on the server based on user input? Let them specify the disk configuration, the memory, etc. and validate against it. Such functionality would seem to be necessary in order to effectively test this, wouldn't it? Dave > > Thank you, > Clay > > On Mon, 18 May 2009, Dave Miner wrote: > >> Jack Schwartz wrote: >>> HI everyone. >>> >>> Minutes of this meeting are posted at: >>> http://www.opensolaris.org/os/project/caiman/auto_install/AI_mtg/Minutes/XML_parser_rework_minutes_090515.txt >>> >> A couple of comments on sections I've pasted in: >> >>> Provide capability via enhanced SMF profiles to specify custom info not >>> used by >>> installer? >>> >>> ------------------------------------------------------------------------------- >>> >>> Would we ever want to provide a user capability to specify custom info via >>> an >>> enhanced profile, where the installer isn't using that info? This way, one >>> can >>> customize the install (e.g. enable ssh). >>> >>> --> Conclusion: If this capability is implemented, we would want to take >>> the >>> custom info via a separate file. >> I think some elaboration here is required, as it appears to me that you're >> proposing to support only a limited subset of enhanced profile >> functionality. >> Why would we not, by default, allow customization of any SMF setting via the >> profiles supplied here? >> >> >>> Since there could be conditions where the manifest could still work even >>> though >>> there is a version mismatch, the conclusion is to print a warning on >>> version >>> mismatch but try to continue. Then if validation fails or other errors >>> occur, >>> the user has been alerted to a version mismatch as a possible cause. >> What specific, useful scenarios do we think this loose versioning supports? >> The notes don't mention any, but I'd expect some elaboration on why a strict >> check is not appropriate. >> >>> Problem statement 4: Semantic validation is needed for AI. >>> ========================================================== >>> - Lack of it means failures further down the installation process >>> instead of up front, or misconfiguration. >>> >> ... >>> --> Conclusion: >>> If not too much extra work involved, do it for server and client. >>> Else, do it for the client only. >>> >> I'd view it as an important requirement that we be able to perform full >> semantic verification on the server. Why is this regarded as optional? >> >>> Problem statement 1: AI's multiple parsers present unneeded >>> complexity and unmaintainability. >>> =========================================================== >>> - Things to consider for a single parser: >>> - functionality for data retrieval and search, schema compatibility, >>> how supported / maintainable is the parser >> ... >>> The main argument for using lxml would be that it is supported from the >>> outside. However, that ManifestServ is supported by us means we can more >>> easily tweek it to add any needed functionality which remains. If lxml >>> were >>> used, we would have to fix our code which interfaced with it if it changed, >>> but >>> we would have to do the same for ManifestServ if libxml2 changed. >>> >> It wasn't entirely clear from the discussion in the notes that we've >> actually >> identified requirements that lxml doesn't meet. Do we have that? >> >> Dave >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
