On 07/12/10 02:18 PM, Sarah Jelinek wrote:
On 07/12/10 01:57 PM, jean.mccormack wrote:
On 07/12/10 01:50 PM, Sarah Jelinek wrote:
On 07/12/10 01:33 PM, jean.mccormack wrote:
It would look something like this:
<software_spec>
<destination>
<image ips_search_index="true">
</destination>
<software>
...
</software>
<software_spec>
The idea is that the generation of the ips search index is an
attribute on the IPS image we are creating as part of the DC
process.
I believe that should work. Thanks
Sorry, after really looking at this I need the ips/cpio arguments
to fall under software, reason being that these
arguments can and often will change within a checkpoint but
different transfers within. Best served by an example....
In a checkpoint I really want to transfer via cpio files from:
/usr/bin with default cpio args
/usr/lib with cpio args "-pdm"
/usr/whatever with default cpio args.
Are these args something the user should have control over? Are
these set in the application?
Possibly? But ips_search_index also falls into the category of I
would like it under software. All the IPS ones do.
In fact, you have 3 types of IPS argument lists, one for creation of
the image, one for pkg installing and one for
pkg uninstalling. So if a checkpoint does a image
create/install/uninstall that is 1 software_spec node but 3
software nodes.
yes, you are correct. But, in the case of 'create' the 'install'
action will create the image, using the image attributes if one is not
created, right?
Well the reality is that the arguments to image_create, plan_install and
plan_uninstall are very different. So if I have a set of arguments
without specifying which one they go to how do I know which call to send
them to? If I send a argument specifications to plan_install that
include args not valid for plan_install (meant for create) the call will
barf.
And, in the case of uninstall, what are the ips attributes you would
want to specify that are not specified in the initial image settings?
recursive_removal.
It seems to me that if you said --no-index for the create then you
wouldn't want to update the index for the remove, would you?
But what about setting refresh_catalogs=True for plan_install?
plan_uninstall doesn't have that parameter and thus would die an ugly
death if you sent that as part of the args list.
Multiple actions can be applied to an ips image, and the initial
setting of the image attributes applies to all actions associated with
the image. The action tells the checkpoint what packages apply for
that action. So, the checkpoint would have to get all the software
with an action of say 'uninstall'.
How do I know which one to apply the arguments listed in image to?
The idea behind these arguments
is that I'm not supposed to have to be aware of what arguments there
are, just pass them through to IPS.
Yes, I agree. But, if you look at how I have encapsulated the elements
and attributes, a software_spec element applies to one image at a
time, and anything to do with other images must be enclosed in a new
software_spec element. The attributes you are referring to are image
attributes not software attributes.
But that's not true with IPS. Here's the layout:
image_create(pkg_client_name, version_id, root, imgtype, is_zone,
cancel_state_callable=None, facets=misc.EmptyDict, force=False,
mirrors=misc.EmptyI, origins=misc.EmptyI, prefix=None,
refresh_allowed=True,
repo_uri=None, socket_path=None, ssl_cert=None, ssl_key=None,
sys_repo=None, user_provided_dir=False, progtrack=None,
variants=misc.EmptyDict):
plan_install(self, pkg_list, refresh_catalogs=True,
noexecute=False, verbose=False, update_index=True):
plan_uninstall(self, pkg_list, recursive_removal, noexecute=False,
verbose=False, update_index=True):
So, in terms of the cpio args, who has the ability to change these?
Does the user? Or is this an application specific thing?
I would hate to make a decision here such that the user couldn't change
these. By placing it in software_spec that is what happens. If you place
it in software then we have more flexibility.
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
