Clay Baenziger wrote: > Hi Sarah and Dave, > Perhaps, as I'd love to see create-client go the way of the dodo, > this would be integrated into a dry run feature?
I think this is a good idea. > The client data could be provided and then the server would specify > why a particular manifest was chosen doing manifest selection and > derived profile generation; then the feature would run the semantic > validation against that chosen manifest - again providing reasons for > any failures. > That seems to be a logical way to support such a thorough check. I > agree that is seems manifest publication time wouldn't be when to do > such a specific check as the manifest may be intended for any number > of clients. Perhaps I'm just being unimaginative though? No, I think that you are right in how this could be used. I didn't think of this when I responded to Dave and misunderstood what use cases he was referring to. This is a good set of ideas. thanks! sarah **** > Thank you, > Clay > > On Wed, 20 May 2009, Sarah Jelinek wrote: > >> Hi Dave and Jack, >> >>>>>> >>>>> >>>>> 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? >>>> It's not that it's optional on the server, it's that the server >>>> cannot provide the full client context to do full validation. Of >>>> course we want to do as much validation as we can on both the >>>> server and the client. >>>> >>> >>> I would expect that a user could supply whatever context we desire >>> to use, either synthetically or via importation of some client >>> context that was generated from a real client. From the point of >>> view of the validator, the client is just a bunch of parameters, >>> which can also be supplied via other avenues. Requiring real, live >>> clients in order to validate thus seems unnecessary. >> >> I don't think in all validation scenarios we require real, live >> clients. But, we have to know that some validation is not possible if >> we don't have the context for which we are doing the validation. The >> issue with some of the semantic validation, specific to the client, >> is that beyond simple 'syntax' checking or format checking of >> something like a target device specification, without a live client >> or a set of client data that provides this information, it is hard to >> validate the schema. So, are you proposing we provide for 'importing' >> the client data if the user so desires so we can do more contextual >> validation when setting up a service? I am not sure why we would want >> to do that actually. >> >> Seems to me a service is independent of the client. Clients discover >> services, and one service will be used to produce an installed >> system, but the manifests that are provided in that service may apply >> to many clients. Providing this contextual semantic validation as a >> user is setting up a service seems to break what our model is. As you >> note, we would have to have some data regarding the client to do this >> type of validation, which implies that the user setting up the >> service would have to know which clients the service applied to, if >> they wanted to make use of it. >> >> During specific client setup, that is installadm create-client, we >> could do this. >> >> sarah >> **** >> >> >> >> >>> >>>> In response to your reply to Clay: >>>> > 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? >>>> >>>> Please elaborate, because as I understand, I'm not sure this is >>>> feasible so I may just not get what you're saying. >>>> >>>> For example, as Clay said in his first response, in the case of a >>>> disk configuration, how would the user know that such a disk by >>>> that name really exists on the client? We can't assume the client >>>> is up and available, or even if it is up, that the disk would have >>>> that name in its currently-booted OS instance. >>> >>> See my note above about synthetic environments. If our only answer >>> to testing out sets of criteria is to "boot and hope", then I think >>> we've fallen far short of what's possible. >>> >>>>> >>>>>> 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? >>>> lxml meets most of the requirements we would need, but it would >>>> require some work writing new wrapper code to use it, and >>>> ManifestServ has this already done. For example, lxml does have >>>> something we can use for semantic validation but would require >>>> event handlers and other code to make it work. ManifestServ >>>> already presents a complete system for this using libxml2. lxml >>>> won't buy us anything more than what ManifestServ already delivers, >>>> and will require an effort to make it useful which isn't required >>>> with ManifestServ. >>>> >>>> One shortcoming of lxml vs ManifestServ is that it doesn't have as >>>> good of a capability for narrowing of matches based on values of >>>> multiple child nodes. >>>> >>> >>> I don't have any particular bias one way or another, but there's >>> up-front vs. on-going effort involved in any choice made, and I'd >>> expect to see some evaluation of those trade-offs in the design >>> proposal. >>> >>> Dave >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
