Sarah,
On 06/17/10 04:41 PM, Sarah Jelinek wrote:
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.
OK, that addresses any desired validation.
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.
How do you deliver more an AI manifest with multiple SC manifests? How
would the protocol work, RE: HTTP GET requests?
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?
Upon first boot, SMF services will prompt for missing required sysconfig
properties.
- 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.
This approach would reduce scalability is when a single AI manifest is
desired, but different SC manifests; e.g., same hardware configurations,
but different root passwords. However, this case could be accommodated
through some type of derivation or substitution based on criteria, which
could include service, IP network, MAC address, etc. as in the proposal.
For example, if the sysadmin had a scheme in which SC manifest file
names were based on service name, a replacement tag for service name
could be embedded in the SC manifest name specification in the AI manifest:
<sc_manifest url="/export/SC_manifests/${service_name}.xml" />
Since SC manifests remain under services, security considerations would
remain the same as proposed.
...
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.
Yes, that would work.
- 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.
OK. The difference between this and what is in the proposal is that if
the SC manifests are forced through a UI, they are verified at that
time, which is not a requirement, anyhow.
- 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.
Correct, the AI manifest would dictate the 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.
Agreed - the sysadmin just removes a line from the AI manifest.
The main difference with what you are proposing is that the SC manifest
information is not in a database for central management and reference,
but now within AI manifests. Central management and reference are still
possible, though through the AI manifests. Central management of SC
manifests is not a requirement.
So, I think that specifying the inclusions from the AI manifest would be
fine.
Thank you,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
