On 06/22/10 09:55 AM, Dave Miner wrote:
Just a few follow-ups (BTW, can we get page numbers in the next update?):
Sure.
On 06/22/10 10:25 AM, Sarah Jelinek wrote:
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?
So the above answer also applies to the unknown type?
Yes.
- 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.
This seems inconsistent with the DC instance document in 6.5, which
has compression in a boot_archive section for the img_params, so
something needs to be resolved.
Ok, I will take a look and resolve this.
- 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.
Interesting question. You're right that they are global presently;
that sort of works on the basis that we're acting on only one pkg
image in general, but specifying it per-image would be the right
answer. However, we don't seem to be exposing an image as a concept
here; maybe we should, though...
yeah.. I can see if we expose the image concept them having them apply
per image would be useful. Let me work on this.
- 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.
I think we'll need it.
Ok.
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.
Maybe my above thought about lack of exposed pkg image object is
something to consider here. Another thought that occurred to me was
using naming of instances of the software spec to associate with
particular checkpoints.
both are interesting ideas. The naming of the instances of the software
spec might work well. I will look at this and see what seems better.
- 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.
I presume the path is relative to PYTHONPATH or something? Anyway,
just adding some notes here such as the above would be helpful.
Yes. I will add notes.
thanks,
sarah
****
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
