Greetings all,
After lots of hallway conversations about how best to handle this,
here's a proposal for how the cli might look:
A new option, -Z is added as an option to pkg (a peer to -R). The -Z
option allows the user to specify which child images (practically zones)
to execute the operation on. -Z and -R may be used together. If they
are, the images specified in -Z are relative to the image root specified
by -R.
We need a scheme for what arguments that the -Z option takes. The
simplest would involve just naming exactly all images to be operated on.
Given that we can have multiple layers of linked images (in theory at
least), I thought that might involve a bit more typing than was ideal.
Based on the conversations with Danek and Bart, I put together two
examples of what the scheme might look like.
The underlying principle behind both is that explicitly specifying a
particular image carries implications about what should be done to the
ancestors, cousins, and siblings, of that image. Specifically, if a
particular image is named explicitly for inclusion(or exclusion), then
its ancestors, siblings and cousins are implied to be excluded(or
included) unless otherwise specified. The difference between the two
schemes is really whether naming an image explicitly for inclusion(or
exclusion) implies its children should be included (the first scheme
below) or excluded (the second scheme). An image that is not explicitly
noted cannot have conflicting implications produced by the same
generation. When implications conflict, the implications produced by the
youngest generation wins.
Here's the first scheme that seemed reasonable to me, and that involves
little extra typing and typically captures what I think the intent would be:
-Z '*': operate recursively on the root image
-Z test1: operate recursively on the image named test1
-Z test1,!test1/*: operate on only the image named test1
-Z !test2: operate recursively on all child images of the root image
except test2 (and its descendants)
-Z !test2/*: operate on all child images of the root image, including
test2, but don't operate on test2's descendants
-Z test1,test2,test4: operate recursively only on the child images named
test1, test2 and test4
-Z test1,!test2 : Error since !test2 and test1 have conflicting
implications for test3. If test3 doesn't exist, this could be allowed to
succeed in theory, but would suggest that it fail.
-Z *,!test2,test2/test2-2 : Operates recursively on root and all
children of root except for test2. It also operates recursively on the
image test2/test2-2, but not on test2/test2-1
-Z test1/a* : operate recursively on all child images of test1 whose
name begin with a
To operate only on the root image, don't specify -Z.
Problems:
It's impossible to express "operate on the root and these child images"
following the conventions above without using ! to specify each child
image that shouldn't be operated on. We could treat "root" specially so
that using it explicitly doesn't imply operating on its descendants.
Here's another possible scheme where there's more typing because
"operate recursively on children" is now explicitly indicated:
(In this example, I'm using '^' prepended to image names, but it could
be appended instead, and a different character could be used)
-Z '*': operate on all images including the root image
-Z test1: operate only on the image named test1
-Z ^test1: operate recursively on the image named test1
-Z ^test1,!test1/*: Probably an error, or it's equivalent to -Z test1
-Z !test2: operate recursively on all child images of the root image
except test2 but does operate on test2's children
-Z !^test2: operate recursively on all child images of the root image
except test2 and its decendants
-Z !test2/*: operate on all child images of the root image, including
test2, but don't operate on test2's children, but do operate on their
descendants
-Z !test2/^*: operate on all child images of the root image, including
test2, but don't operate on test2's decscendants
-Z test1,test2,test4: operate only on the child images named test1,
test2 and test4
-Z ^test1,^test2,^test4: operate recursively only on the child images
named test1, test2 and test4
-Z test1,!test2 : Error since !test2 implies test1
-Z *,!^test2,test2/test2-2 : Operates recursively on root and all
children of root except for test2. It also operates recursively on the
image test2/test2-2, but not on test2/test2-1
-Z test1/^a* : operate recursively on all child images of test1 whose
name begin with a
-Z root: operative only on the root image (also what happens if -Z isn't
specified)
-Z root, ^test1, test2: operate on root and test2, operate recursively
on test1
Problems:
The syntax doesn't strike me as being especially intuitive and is more
verbose than the first proposal.
There's another issue I think we need to address as we start to think
about how to handle the cli for recursive operations: how operations in
a parent image are allowed to affect the child images. From my
understanding, here's how things are today:
1) 'pkg update' (with no arguments) takes the parent and all child
images as far forward as possible.
2) All other operations which affect packages are allowed only to sync
child images. A sync is allowed to move existing packages forward, but
is not allowed to install, uninstall, or downgrade packages (i think).
3) All other operations have no effect on child images at all (setting
properties, freezing packages, etc...)
The current situation has some issues we know about:
Can't uninstall a synced package without manually uninstalling it in
each child image first
Completely impossible to downgrade a synced package without detaching
all zones
Updates can fail because of differing image properties (whether
signatures are required or not as an example)
Updates and installs can fail because of differences in which packages
are frozen.
While I suspect the final answer lies somewhere in the middle, let me
lay out what I see as the two extremes a person could take to deal with
these issues.
Recursion everywhere:
The solution here is based on the new ability to recursively do
operations. If you want to uninstall a synced package, use the -Z (ie,
do the operation recursively) option. The same solution underlies
downgrading a synced package. When you freeze a package, just freeze it
everywhere. When you set an image property, set it at all levels. Taken
to its extreme, we could mostly remove the sysrem-repository since the
user would've set the publishers recursively (we'd need to propagate the
keys and certs for https operations and ensure that child images
couldn't harm the publisher configuration). The downside of this extreme
is that I suspect users will just add -Z '*' to every command they enter
reflexively (and may wonder why this isn't the default).
User knows best:
The solution here is to do what we were told to the best of our ability.
If the user says to uninstall a synced pacakge, we'll go to the child
images and uninstall that package. An extreme version of this is that if
that means that other packages in the child image also need to be
removed, they're uninstalled as well. Similarly, if a synced package is
downgraded in the parent image it's downgraded in the child images (and
again, at the extreme of this position, other packages which must get
downgraded to allow the operation to succeed are downgraded). When a
child image is attached, whatever operations needed to bring the child
image into sync with the parent are done (install, uninstall, upgrade,
downgrade). This approach would also propagate information about package
freezes, relevant image properties (like signature policy) and probably
other things I haven't thought of at the moment to try to ensure that
whatever operation is entered by the parent image admin succeeds. It
would also unfreeze packages in the child images if necessary. With this
approach, the -Z option would only get used to install a package in all
child images, uninstall a (unsynced) package from all child images, and
perhaps update all images to the latest bits (after changing what 'pkg
update' does). The downside of this extreme is that child images'
functionality could be unintentionally broken without the parent image
admin making explicit the desire to operate on child images. (The other
extreme can break child images' functionality equally throughly, it just
requires the parent image admin to use the -Z option explicitly.)
I'm not sure where to draw the line here, but I hope that by
illustrating what I see as two extremes, we can start the conversation
about how we'd like this to work.
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
