Hi Alok,
Comments inline...
On 07/ 9/10 12:11 PM, Alok Aggarwal wrote:
Jean: See below for a transfer related comment.
On Fri, 9 Jul 2010, Sarah Jelinek wrote:
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?
We could do it as arguments but I think readability would
take a hit in doing that.
Considering that multiple GRUB menu entries can be specified
and each of them span multiple lines, it could get somewhat
complicated.
One other way I can think of to do this is via the configuration schema.
That is a user would provide a reference to an external file that
contained the definitions for the multiple grub entries. What I am
trying to avoid is schema and manifest overload. This is really a
configuration item so maybe it makes sense to have it specified similar
to how we are going to specify the SMF profile configuration?
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?
Just one point about this statement:
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.
This sequence of events doesn't make sense to me. I just want to be
clear on why you are proposing what is listed below.. the DC application
registers Transfer checkpoints and they are executed. The DC app would
put the post install publishers in the DOC for use by one of these
Transfer checkpoints. When we set the ips attributes is this not done by
one of the Transfer checkpoints?
What I'm proposing is - let's take the post_install_rep
and addl_authority out of the dc_spec section for the
above reasons.
Instead, encapsulate it as -
<software_spec name="set_ips_attributes">
<primary_source>
<publisher name="xxx">
<origin name="yyy"></origin>
<pub_mirror name="zzz"></pub_mirror>
</publisher>
</primary_source>
<secondary_source>
<publisher name="aaa">
<origin name="bbb"></origin>
</publisher>
</secondary_source>
<software action="noinstall" type="ips">
</software>
</software_spec>
Could something like this be done?
Sure.. but what you are proposing is to have a separate checkpoint,
"set_ips_attributes" to do this? What benefit would having this
checkpoint give us?
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?
That should work. Jean, do you agree?
Another thing I forgot to mention is that - for sparc
images, we need a section that indicates which files
shouldn't be fiocompress'd. I didn't notice such an entity
in the schema. Could it be added?
I could add this as an attribute on the software element. Let me look at
this and I will figure out the best place to add this.
thanks,
sarah
****
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
