Sarah,
On 06/ 8/10 04:26 PM, Sarah Jelinek wrote:
...
So, why would it be so bad that we have a modification to an SC
manifest affect all the services that refer to it? ...
It's only bad if the user doesn't remember this when making changes.
...
I would propose that we separate these out even further... that is
separate AI manifests but the ability to reference SC manifests that
are in another location from the AI manifest file.
Good idea - will add this to the proposal. An HTTP URL could also be
used to specify an SC manifest.
Advantages:
- documents are valid and can be parsed and validated individually
without manipulation
- useless tags ai_criteria_manifest, ai_embedded_manifest,
sc_embedded_manifest and their closing tags disappear
Disadvantages:
- AI web server must dynamically merge the documents for the default
case (mitigated by the small size of the documents)
Why does it have to merge these? We apply the SC manifest in it's
entirety to the client for use by SMF, right? So, merging them for
transmission and then separating them on the client seems like work we
don't need to do.
Well, presently the SC manifest is embedded into the AI manifest.
Although they both contain system configuration information, they are of
two different incompatible formats. It makes some sense to send them
with one HTTP GET to reduce the number of network transactions - I just
think it's simpler to merge them in a standard format like MIME, then
separate them on the client.
I also agree with Dave that the SMF services doing the configuration
should prompt for the correct data if it is missing.
Yes, this is what the Enhanced SMF Profiles project will give us.
- user has 2 default documents to maintain (mitigate this by
supplying commands to help the user edit them)
Propose that the AI and SC manifests be encoded in MIME multipart.
It allows us to change encoding on the server side without having to
change the client - the client would just decode it according to the
header info. Also, if more information were added to the download,
it could more easily be bundled and parsed using MIME standard
routines. MIME parts can be separated using a normal text editor.
It isn't clear to me why we need to encode these in MIME. I believe
that the SC manifest should and can be managed separately, since we
have to apply these separately to the client system. We shouldn't be
in the business of merging and separating when the use case doesn't
require it.
Can you think of such a use case?
Section Ie: Miscellaneous suggestions for enhancements:
1. SMF is expected to support multiple SC manifest files. The
proposed design does not leverage this capability for AI, since a use
case was not found and managing multiple SC manifest files is more
complicated.
So, it seems to me that if we don't do the merging of the SC manifests
with the AI manifests to transfer to the client, we then remove the
difficulty of allowing multiple SC manifests.
MIME is an old standard, and separating parts of a multi-part MIME
message can be handled by library routines in multiple languages. For
example, the parts can be named: "AI_manifest", and multiple parts named
"SC_manifest". The individual SC manifests will *still* have to be
separated for SMF, since DTD documents cannot be simply concatenated -
there would still have to be some additional processing required -
either on the AI client or server, or by SMF.
I also think that allowing multiple SC manifests to be defined and
used by an AI service improves scalability for the sysadmin. In
particular if we allow a reference to the SC manifests as opposed to
naming them and requiring an association to the image.
Yes, multiple SC manifest files increases scalability, and it is true
that the naming is not necessary for increasing scalability.
Now, consider some of the complexities that would accompany multiple
manifests:
- Can the user edit the previously submitted files individually? The UI
would have to support it.
- Are the individually submitted files subsumed into the AI server
database (which would protect them), or are they just pathnames to files
that are included dynamically at install time?
- How would duplicate properties be handled? Is the order of the files
now an issue? Are UI commands to change the order of the files necessary?
- If the user wants to remove a file from the list, a option to specify
the file to remove must be added to the UI.
- Would a GUI be easier in the end?
- As mentioned above, SC manifests are DTD files, which cannot be simply
concatenated without violating the syntax.
Allowing XInclude and multiple manifest files are not mutually
exclusive, but XInclude supports inclusion from multiple files, plus it
can be table-driven with pointers that can include content by indexing
it within another file. The files it includes can be simple XML fragments.
Another advantage of XInclude is that a single document can be used for
all SC manifests, and an SC manifest for a given AI service can just
index what is pertinent to at service.
XInclude is already supported by xmllint(1), which can do the inclusions
and the DTD validation.
I've added sample code in the forthcoming proposal revision.
Section If: Caveats in proposed changes:
1) In naming manifests, if user is not attentive of other
services/clients using the named manifest, changes could result in
unexpected results. An option to copy the info from the named
manifest, saving it as a private unnamed manifest for the
service/client in question could break the link while supporting
reuse of a single named manifest.
I am a little confused by this statement. It seems to me that with the
proposed changes you suggest to the installadm commands ..., and the
comments about not allowing different services or criteria manifests
to reference the same SC manifest persistently
I meant in the existing code - not in what I am proposing. I am
proposing that an SC named manifest can be shared, BUT if the user
forgets this, there could be trouble.
means that changes to a named SC manifest wouldn't result in a change
to the SC manifest stored with the service. Am I misunderstanding what
you intend?
All I am trying to say here is that the user could be given an option to
copy a public, named manifest and associate the copy privately with
another service to avoid conflicts. It would in effect export the named
manifest and use the copy privately for another service.
At the moment, though, I think that private manifests are too much
trouble, so I'm not proposing them.
I'm fixing the confusing text. Thank you for your patience.
Also, you note early on that it is expected that the Criteria
manifests will disappear, but you refer to the criteria manifests in a
few places later in this proposal. It would be good to use the correct
nomenclature, perhaps changing references to "criteria manifest" to
simply "criteria".
Indeed.
Thanks your help and effort,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
