Hi Jean,
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.
So, I am not clear what the arguments to create, plan_install and
plan_uninstall have to do with setting the image attributes. If you look
at the set of pkg command for the three, create, install, uninstall the
args are:
image-create:
[--force]
[--full|--partial|--user] [--zone] [-k ssl_key] [-c ssl_cert]
[--no-refresh] [--variant <variant_spec>=<instance> ...]
[-g uri|--origin=uri ...] [-m uri|--mirror=uri ...]
[--facet <facet_spec>=[True|False] ...]
(-p|--publisher) [<name>=]<repo_uri> dir
install:
[--accept] [--licenses] [--no-index]
[--no-refresh] pkg_fmri_pattern ...
uninstall:
[--no-index] pkg_fmri_pattern
So, based on this the schema contains the following definitions to allow
for all three, in the image element:
facets, image_type(full|partial), or zone. No user image allowed during
install.
ssl_key, ssl_cert
image_root(if not default)
index (for --no-index)
property(for setting image properties such as send-uuid
source(which is a publisher)
There are some attributes offered by the pkg commands that we are not
including in the things a user can set:
--accept/--licenses for 'pkg install'
The use of the allowable attributes defined under image would be:
image-create: use all of the values listed above
install: use --no-index
uninstall: use --no-index
The thing is all of these will be available to you during all the the
operations. It should be assumed that within an image the values for
these as set by the user in the manifest will remain the same for all
operations on that image. We are not going to allow the user to set the
--no-index differently for install and uninstall. The option
--no-refresh should be set to whatever is reasonable for the application
creating the image.
At some point the args that the user can set on these operations have to
translate to the interface options, right? And, if we don't allow the
user to set these per action, which I think is way too many knobs to
turn, the all the args you need are there.
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.
This should happen by default. This is an application specific decision
not a user settable attribute.
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.
Don't include it in the plan_uninstall parameter list. The image options
a user provides in the schema don't apply to every operation that can be
performed on an image, so only provide the ones that are relevant to an
operation. However, the image attributes provided by the user should be
consistent across the image operations.
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):
No, the fact that the api's are different for operations on an image
doesn't mean that they don't apply to the image. All of them modify the
image in some way, each software pkg does not do that. You have to have
some knowledge of the api's for ips, and you have to have some knowledge
about which options apply to which api's. That kind of knowledge is
expected. You have to know which options are valid for which api's so
getting that data from an image element as opposed to a software element
doesn't matter, except that these are ips image options, not a software
operation option.
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.
I think we can make decisions about how we want to use cpio within our
applications. This isn't a user thing it is an application thing. This
isn't a general purpose unpacking of any cpio archive, it is a specific
cpio archive with specific args.
thanks,
sarah
****
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
