On 07/12/10 06:17 PM, Alok Aggarwal wrote:
Hi Sarah,
On Mon, 12 Jul 2010, Sarah Jelinek wrote:
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?
That should work.
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?
The post install publisher data will be represented in the DOC
as a DCSpec Object. In order for Transfer to use this data, DC
will have to translate the publisher information from DCSpec into
a Transfer object. *Then* Transfer can use this data.
It would be simpler to not have to do this translation in the
first place.
Ok, I can see how this would be easier.
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?
See the following for why this makes sense -
http://mail.opensolaris.org/pipermail/caiman-discuss/2010-July/018928.html
Ok. I can see why this would be useful. Let me take a look at this with
regard to the DC spec definition.
thanks,
sarah
(response to section 3.5.3)
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
