On 06/13/10 10:13 AM, William Schumann wrote:
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.
That's true for any change a user makes. I still think the scalability
offered with allowing this outweighs the downsides. I don't think an SC
definition should be tied to the service. I think it should be available
from local or remote locations. Remote means we get it via http. Not NFS.
...
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.
We may presently do this, but I think that even if we allow for
specifying the location of the SC manifest remotely we can validate it
on the client. Or, if the user provides a validation method we can use
that as well at manifest parse time. A user can also validate it
independently using xmllint. I realize that the user could change it in
between validation and the use of it, rendering it invalid, but we error
out on the client if that happens.
With the new schema definition I don't propose merging it. It will be
using a DTD as will the AI manifest so it isn't different any more.
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.
How will this give it to us, and not derived manifests?
- 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?
Sure, I can think of a use case. I think allowing the users to
separately define and manage the SC manifest from the AI manifests,
which are tied to a service, seems reasonable. As I have noted before it
provides more scalability with regard to reuse of the SC manifests. I
think it also easier to manage from a sysadmin perspective.
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.
We could certainly use MIME to coalesce the manifests. With DTD in the
AI schema the schema differences won't be an issue. Using MIME doesn't
negate the ability to keep the SC manifest separate from the AI manifest
and allow them to be stored and managed separately.
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.
Why do we want the installadm UI(which I assume you are referring to
here) to manage the SC manifests. If they are referenced in the AI
manifest, but are not embedded in the manifest I don't think we need to
associate it with a service, but rather let the manifest definition that
is associated with the service define this.
- 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?
I think they are just path names, not put in the AI server db.
- 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?
No, I don't think UI does anything. If the properties are duplicated it
is my assumption they will be processed by SMF as defined and the SMF
services will apply properties as they get them. In order.
- 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.
No, again I think if the SC manifest is referenced in the AI manifest
and not embedded it will not require UI changes. If the user wants to
reference a different SC manifest they have to update the AI manifest
and and change it within the service as usual.
- 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.
But the new AI schema is DTD, so this is no longer going to be an issue.
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.
If the user forgets yes, there could be trouble. But, I still think the
scalability is important.
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.
Ok, I understand now. I don't think an SC manifest should be associated
with the service in the same manner an AI manifest is today.
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,
sarah
****
Thanks your help and effort,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
