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?
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
>
