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