Dave,
On 01/20/11 04:31 PM, Dave Miner wrote:
On 01/20/11 08:14 AM, William Schumann wrote:
Ethan,
On 01/19/11 11:04 PM, Ethan Quach wrote:
To summarize the last paragraph:
- the correct service_bundle DTD would be required for 'installadm
create-profile', too
- it is better to validate against the service_bundle DTD and require
operational adjustments in the odd case, which should mean
only copying the DTD of the needed version.
I don't believe this is workable, it requires a great deal of manual
fiddling by the user to achieve correct results (seemingly including
installing packages that are mis-aligned with the server release) in
cases where the server and clients are skewed, which are *very*
common. Unless we can come up with a better answer where the, this
can't remain.
As I stated, it could be resolved simply by copying the appropriate
version of /usr/share/lib/xml/dtd/service_bundle.dtd.NNN
Assuming that doing so might be more difficult than I think it would, I
would propose reducing a missing service_bundle DTD in create-profile to
a warning only, since we don't know that the profile in question if
invalid if we don't have the DTD. So if the profile were valid XML, it
would be accepted into the database with only a warning.
The service bundle DTD is a packaged portion of the system. We do not want to
ever be recommending that the user copy random
versions of files from the later versions of the system/packages to earlier ones as a standard procedure, as it breaks our
general
support model for the OS. So, yes, I think this will be more difficult than you
think; to do this properly involves back-porting
the DTD to earlier versions of the OS that would need to be able to consume
that DTD, and that takes real time for someone, and
doesn't work well for releases that have gone out of support but might
otherwise work OK as an AI server.
I can perhaps go along with reducing it to a warning, though I'm concerned that
this will also generate support calls and their
accompanying costs.
Yes, this will result in some calls. However, I keep in mind difficulties in
hand-coding XML, which keeps me pushing for as much
validation help as possible, since these problems are far more common for users.
I understand why you want to provide it, but we need to ensure that it doesn't
create more problems than it solves.
Other potential problems:
- the service_bundle DTD is broken (unlikely)
- the validation code (proposed to use Python module lxml.etree) is broken
(unlikely)
These could both be worked around by omitting the DOCTYPE line from the profile.
Can't we get the service_bundle dtd from the boot image of the install service
that the profile is being validated for? Or am I
missing something?
It would have to be unpackaged from the boot archive for x86, but that doesn't
seem prohibitive if it is done only once per service.
The profile will reference the DTD by the /usr/share.... path on the server, so I don't see how its presence in the install
service is helpful. As I said previously, copying it into that path on the server as unpackaged content, either by hand or
automatically is not desirable.
The DTD could be extracted to a location private to the AI service - it doesn't have to be in /usr/share/.... According to the
documentation, once parsed by lxml.etree, the DTD filename can be identified as /usr/lib/whatever/service_profile.dtd:N There is
an lxml.etree method, DTD, that can validate against an explicit DTD file. http://codespeak.net/lxml/api/lxml.etree.DTD-class.html
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
