Hi William,
My review comments inline....I tried not to repeat Dave's comments.
On 06/ 2/10 01:02 PM, William Schumann wrote:
This proposal addresses specific deficiencies in customizing SC
manifests, and proposes enhancements to increase usability and security.
3. (related) It is not possible to have different services or criteria
manifests reference the same SC manifest persistently, such that
changes in the SC manifest would affect all services that use it.
Adding named SC manifests that are referred to by name in AI services,
clients, and criteria manifests can reduce replication of SC manifests
and management time.
So, why would it be so bad that we have a modification to an SC manifest
affect all the services that refer to it? Seems to me that this might be
something sysadmin's want. There is no reason they couldn't create a set
of system configuration manifests which they want to have reused and
when changes need to be made they only have to update one file. Having a
reference to an SC manifest in this way reduces the need for sysadmins
to update all the services.
The burden of having the SC manifests as an external reference is that
they would need to be served by a webserver. So, the sysadmin would have
to ensure that these were accessible in this way. However, I don't think
this is a huge burden.
Section Ib: use named SC manifests:
installadm create-service ... [-s <SC manifest name>] - associate
named manifest
installadm create-client ""
installadm modify-service (new) ""
installadm modify-client (new) ""
installadm modify-service/-client ... -S dissociate any named
manifest (restore to default SC manifest)
(assumed deprecated: installadm add)
Implementation detail: if a custom client is created without an
associated named manifest, the image default will be applied, creating
a manifest named after the custom client, and the user will receive a
notice to that effect.
Section Ic: separate AI and SC manifests
An unresolved issue in the current design is the combined manifest
having two different formats for AI and SC manifests. The workaround
taken was to encapsulate the SC manifest in comments, which makes it
syntactically impossible for it to have its own comments.
Advantages of a single default.xml:
- AI webserver needs only to serve a single static document for the
default case, so http efficiency is maximized
- user only has to edit a single document for AI and SC manifest defaults
Disadvantages:
- Validation of default.xml would require a tool to split and validate
the AI and SC manifest documents separately
Advantages of SC manifest in comments:
- default.xml is a valid XML document
- default.xml can be validated by an RNG schema
Disadvantages:
- SC manifest can't have its own internal comments
- SC manifest can't be validated without special tool to first extract it
I propose that default.xml be separated into AI and SC manifest
default documents per image.
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.
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.
I also agree with Dave that the SMF services doing the configuration
should prompt for the correct data if it is missing.
- 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.
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. 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.
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(which Dave has
commented on, so I will not recomment on your proposal for these), and
the comments about not allowing different services or criteria manifests
to reference the same SC manifest persistently 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?
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".
thanks,
sarah
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
