Hi Dave,
Thank you for the review. My answers/comments inline...
Sarah,
Partial review covering just Software and Execution schema. More later.
One structural suggestion on the doc: you might combine the text in
5.3 with the actual proposed schemata from 6.1 on. The
element/attribute tables in 5.3 didn't really add anything from my
point of view. This would also eliminate potential inconsistencies
between the two (I didn't note any yet, fortunately).
I will combine these sections. The idea behind having both the schema
and the element and attribute text is that when reading the schemas it
may not be obvious to the reader what the form, defaults, and
multiplicity is of these. And, if the schema language was to be changed
we could develop the new schemas with this textual data.
6.1 Software spec
- What is an "unknown" action?
I am removing this. It was intended as a placeholder for a invalid
value, but it makes no sense to do this, as the valid list of actions
will suffice. If the user specifies something that isn't in the
enumerated list it will flag an error.
- What's the purpose of the "unknown" type?
- What purpose does the "compression" attribute serve?
Compression attribute for software spec provides the DC required
attribute when creating the boot archive. The software spec schema is
intended to be use by both AI and DC, and for DC also with the creation
of the boot archive. I can't see why we need a different schema for
specifying the files to be included in the boot archive. I could
certainly make this data part of the DC specific schema, but it seems as
if it is just another view of the software spec.
- I'm not quite sure how I'd map the primary_source and
secondary_source attributes to the multiple publisher, multiple origin
and multiple mirror configurations that are possible (indeed, likely)
in pkg. Maybe we just need more examples.
The design is missing the the pieces to account for mirrors. The other,
multiple origins is not something I accounted for either. Wasn't aware
this was something I should consider. I need to rework this piece of the
software spec schema to account for this, as well as facets. A
question.. is it desirable to have users be able to specify the multiple
publishers, mirrors, etc.. per software install action? I ask because
today, AFAIK, we only allow the users to specify a global set of these
not apply them per action.
- The example in B.3 shows a "noinstall" action, but that's not legal
according to this schema.
Schema isn't correct. I added noinstall to allow for the DDU capability.
I will fix this in the doc.
- How would we handle pkg publishers such as extra or support that
require key/cert specification?
good question :-). I don't have this accounted for. At this point this
design is based on existing AI and DC schema elements and attributes. If
this is something we need then I will add.
6.2 Execution
- I'm not sure why we should have software_spec embeddable within a
checkpoint, but target data (for example) not?
We could certainly embed target data, or any other data within the
checkpoint element. The reason it is only specified to allow
software_spec is based on the fact that we can have multiple checkpoints
of the type transfer. And, we need a way to associate the software with
the specification of the transfer checkpoint.
In the example I have for dc.xml, we have the im-pop phase, which is the
main transfer phase. We specify the software that is associate with this
phase within the checkpoint definition. Later we need to do the boot
archive transfer phase, and the software for this is associated with
this transfer checkpoint.
Today in DC we specify the populate transfer phase differently than the
boot archive installation phase. And we specify the software for these
phases differently. They are different elements in the DC schema. To
allow DC to use the software_spec schema for both purposes we need to be
able to associate the software with the transfer checkpoint. However, in
looking at the software_spec schema I do have a boot_archive type, so
even if there were multiple transfer phases in a process, it would be
pretty clear which software_spec data in the DOC that a transfer
checkpoint would need to utilize.
I could see that for the boot archive transfer phase we could have that
checkpoint look for the software specified of type boot_archive. Let me
rework the checkpoint schema and see if it works based on software_spec
type for the transfer checkpoint.
- I'm unclear on the semantics of the mod_name attribute.
At this point in time, based on input from Dermot and Karen on
checkpoint definitions, the mod_name is a path that points to a Python
module. The exec_method is the name of the function or class constructor
found within the module that instantiates the checkpoint object.
- What is the type attribute of log_handler used for? I couldn't map
it to the Logging v1.5 spec functions.
Nothing now. Initially there was talk of providing a handler type value
but in looking at Ginnie's latest spec, when the application adds a
handler it adds a specific type, such as an instance of a FileHandler.
It it wants to create a different type of handler it can do so, then add
it. Type isn't necessary any longer. I will remove this.
thanks,
sarah
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
