Hi Dave,
Interesting idea! I think we could automate this potentially. For
example, if we extend the criteria which the client sends the server to
contain all elements necessary to reconstruct the client then the
administrator could specify the client which to test the manifest against.
However, this would require once booting the client to get that
information before ever evening doing an install and a fair amount of
supporting UI I would think.
It could be very useful for admins to have a complete view of
their domain, however. And would be a nice way to allow for a very
comprehensive dry-run environment.
Thank you,
Clay
On Mon, 18 May 2009, Dave Miner wrote:
> 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
>>>
>
>
