On 07/13/10 09:40 AM, jean.mccormack wrote:
On 07/13/10 07:04 AM, Sarah Jelinek wrote:
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:
I see now why we're at odds, you're talking much higher level than I am.
So who will be responsible for taking those image attributes and
giving me the ips api args that correspond to them so I do the right
thing? I assume the app?
No... the checkpoint will manage this. The manifest parser will put
these in the DOC via a software object and as part of the software
object that matches the checkpoint(via naming) you ask for this data and
translate it as required for the api calls.
Does this make sense?
thanks,
sarah
Jean
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
