On 01/17/11 11:18 AM, William Schumann wrote:
Dave,
On 01/14/11 05:46 PM, Dave Miner wrote:
On 01/14/11 09:45 AM, William Schumann wrote:
Dave,
Responding to particular questions inline:
On 01/12/11 09:51 PM, Dave Miner wrote:
On 12/21/10 11:32 AM, William Schumann wrote:
Requesting code review for enhancements for service configuration
profiles in the Automated Installer.
http://cr.opensolaris.org/~wmsch/profile/
...
create_profile.py
214: Is continuing here the right thing to do when we're creating
multiple profiles? Does the user have a straightforward way to
clean up in the face of a partially completed "transaction"?
The user will be informed of profiles that fail to be added. There
will be no cleanup necessary. The user will be expected to take
note of profiles that were not created, correct the problem for those
in error, and resubmit them.
So what happens if I correct the ones that failed, and then re-submit
the same command line with the ones that were added? What I'm trying
to understand is whether the user ends up with a tedious experience or
one that is easily resolved.
The profiles that were already in the database would generate error
messages, and the profiles would be skipped.
So, if I had also modified one of the profiles that had been previously
added, then it wouldn't be re-added? The concern I have is that, in
some sense, the user may expecting the profiles that are expressed in a
single command to be treated as a single "transaction", and you've
created a "partial commit".
I'm wondering if it wouldn't be better to just handle profiles singly
(i.e. remove support for handling multiple in a single installadm
command invocation) unless we can provide a better transaction model.
Other failures in this loop (such as at 261, 266) will cause the
transaction to be aborted, so I'm concerned that inconsistent
semantics here will be challenging to support.
Will correct these to print an error message for the input profile in
question and processing will continue to the next input profile.
delete_profile.py
93: Assuming I understand this right, providing a name that doesn't
exist will abort the transaction at that point, but other
failures later on (111, 119) will continue. As with create, I think
consistent error semantics would be a good idea when handling
multiple objects.
This is like the errors just above. Will correct in the same manner.
locate_profile.py
285: I'm doubtful this validation is the right thing to do. It seems
to pre-suppose that the server will have the same DTD the
client would have in the boot service, but that seems to impose a
requirement on the server that it be updated to the latest
possible version of the DTD, which is generally undesirable to
require from an operational point of view. Or am I
misunderstanding how this would work? This presumably could impact
the validate_profile_string() function in common_profile.py, too.
This is a service_bundle DTD validation by the CGI, taking place
after XML validation. It's original purpose was to validate a
dynamic profile completely (files can be in the user's space), since
the user would be free to break it after submitting it with
'installadm create-profile'. The same DTD validation occurs for all
profiles in create-profile. If a DTD-level validation does not
occur on the server, it could be quite some time before the user
discovers the error - some time during or after the installation
(or upon rebooting if not careful). It assumes that the AI server has
a copy of the service_bundle DTD with the correct version for
the service in question. If the user does not update the package
delivering service_bundle, it will have to be obtained by other
means. It is assumed that versions of service_bundle will be
differentiated by the version indicator at the end the file name,
currently :1, so that it can be copied to /usr/lib. It is expected
that under normal circumstances, the AI server is upgraded to
the level of the OS being installed.
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.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
