On 07/12/10 08:08 AM, Sarah Jelinek wrote:
Hi Jean,
Thanks for the review. My comments/questions inline...
On 07/ 9/10 01:55 PM, [email protected] wrote:
More comments about software_spec....
Currently transfer supports the ability to modify the default cpio
args from -pdum to whatever. Most of the time it's -pdum but there
are some exceptions (liveCD has one of those) where you want
something else. Should a non-default cpio argument be shown in the
manifest? Or are we relying upon the application to know and write
that into the DOC?
Is the name for software_spec really optional? If it doesn't have a
name, I really don't have a way of figuring out the checkpoint/DOC
relationship.
Yes, it's optional. If we have multiple specifications of a checkpoint
type, then it needs to be named. But, if we have one TI, one TD, one
Transfer, etc.. then the software_spec applies to the Transfer
checkpoint.
Now on to software spec and how it relates to the ips functionality.
Like Alok, I'm concerned about the primary and secondary source
definitions.
You only allow 0-1 primary source and 0-1 secondary source. I would
say 0+ for secondary.
Actually, Dave had a comment about this and I am moving this
definition to just be 'source', where multiples can be defined.
Ordering of these definitions is what determines primary from
secondary. First one is primary, all the rest are secondary.
For me it would be nice to have the primary/secondary sources you
specify in the dc area to be in the software_spec area. If I can't
get them from parsing the manifest, then Alok will need to put them
into the DOC for me which just adds more work for him and more risk.
Not sure why there is more risk. The ManifestParser will put them in
the DOC via the from_xml() call on the source object and the
appropriate checkpoint consumes them.
How about getting rid of the concept of primary and secondary and
doing something like this?
/<source type="primary"> # other types could be secondary,
post_primary, post_secondary/
/ <publisher name="opensolaris.org"> /
/ <origin name="http://ipkg.sfbay/dev";></origin> /
/ </publisher> /
/ <source> /
That's what I am planning. Dave's suggestion as well.
Alok had also asked about where the IPS arguments get specified. Is
this something we want in the manifest? Or is it something the
application will supply on it's own? There are several other
attributes that IPS transfer has that fall into this same category
(is_zone flag, image_type, and a purge history boolean) that have a
default value that will usually be used but in the non-default case
where does this info come from, manifest or app?
He mentioned the ips_search_index as one attribute. image_type is now
accounted for based on Dave's comments. The way I look at this is if
the user can set them, meaning the application will honor these
settings then we expose them in the schema. Otherwise if it is the
application that sets these we don't. So.. do you have a list of these
you think users should be able to set?
I guess I fall into the category of "what if the user wants to in the
future". I'm fine with leaving them as the application sets the value
for now until proven we need otherwise.
Jean
thanks,
sarah
_______________________________________________
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
