Hi William,
On 06/18/10 07:57 AM, William Schumann wrote:
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?
So, after chatting on the phone it became clear to me I was
misunderstanding the term "merge" in this context. Using the MIME
multipart document to transport the AI manifest and multiple SC
manifests will work. The AI client just has to parse out the SC
manifests and apply them to the alt root as required.
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.
No, I think the only validation requirement is if the user specifies a
validation method that is associated with the referenced SC manifest,
then we run that, otherwise, validation happens as it would with SMF at
boot 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?
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.
Sure, basically the order a user specifies multiple SC manifests, if
they contain multiple definitions for the same service, the ordering in
AI means we put them on the system in that order. SMF would process them
in order I would assume.
- 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.
ok.
thanks,
sarah
*****
Thank you,
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
