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
