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.
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
(response to section 3.5.3)
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
