On 07/ 8/10 07:24 PM, Alok Aggarwal wrote:
Hi Sarah,
A few things that still need to be changed -
a) GRUB menu customization section from dc_spec.
I do realize that GRUB2 is going to change
some things in this area but still we need a
way to specify custom grub menu entries.
I actually deliberately didn't include these in the schema. I thought
that perhaps this was better done as an argument or set of arguments to
the appropriate checkpoint. Does this seem like it would work for DC?
b) iso sort file specification from the dc_spec
ok, will add.
c) dc_instance should have an additional attribute
along the lines of "incremental_media(true|false)"
to support fixing defect 6794
I have this in the latest dc.dtd. I haven't pushed it yet, but it is there.
d) Are primary_source/secondary_source in the dc_spec
the equivalent of the current post_install_repo_default_authority
and addl_authority?
yes...these are post install definitions. I have renamed this though in
response to Dave's comments on these. But, the use of them in DC remains
as a post install repo setting.
If so, I think it would be better to abstract
these out as a software_spec section. The reason
for this is - DC is going to leverage the transfer
module to set the ips attributes. So, even if it
is specified in the dc_spec section, DC internally
will have to instantiate the appropriate Transfer
class, retrieve the ips attributes from the dc_spec
section and set them in the Transfer object.
Seems like it woul be just be simpler to abstract them
out as a software_spec action.
It is a software_spec element. I am not sure what you mean by making it
a software_spec attribute. Can you clarify?
e) Where do IPS attributes such as, say, generate_ips_search_index,
get specified in the DC manifest?
Good question.. I would think that they would be in the software_spec,
image element as an attribute on that. Would this work?
f) I don't believe the VM creation needs stuff like compression,
boot_archive and max_size attributes in the vm_img section.
The entire vmc manifest is a fairly stripped down version of
the current DC manifest - just has a target section and a
finalizer/execution section.
Right, it doesn't need these, I can make these optional for now.
thanks!
sarah
Thanks,
Alok
On Fri, 2 Jul 2010, Sarah Jelinek wrote:
Hi All,
I updated the AI/DC schemas and the design document to reflect the
comments received in the initial design review. If you want to see
the specific changes, please use the .odt file and set the show
changes and you will see the edits.
The areas I modified were:
-Target dtd. This is based on feedback plus discussions about the use
cases for AI. You will see a high level disk object now, that
encapsulates the partitions, slices or other parts. The new AI schema
supports mutliple disks and pools. And, the associated components.
-Execution dtd. We are no longer embedded software in the checkpoint
elements. The software spec now has a name which much match the
checkpoint name to differentiate different software data for multiple
transfer checkpoints.
-Software spec dtd. This now has elements and attributes for facets,
and better publisher/origin definition.
-I removed the extraneous definitions that were in text for each of
the schemas. The schemas themselves should be sufficient.
-I added the dtd's as well as example instance documents to the gate
for reference.
Please review and send comments. I would like to close this out by
COB 7/9/10.
Thank you,
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
