On 06/07/12 22:13, Brock Pytlik wrote:
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.
In all of the above, it seems as though you aren't using image names, rather you
are using zone names. -Z evokes "zone". Thus, it shouldn't be "root", it
should be "global". This avoids the problems associated with a zone named "root".
That does bring up another issue. Is there intent to allow user images to be
linked to a system image? If so we probably need a way to distinguish between
user images and system images because user images are unlikely to be participate
in this scheme that is clearly aimed at zones.
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).
"Synced package" brings up something that wasn't mentioned before - it wasn't
clear that you intended this to cause some sort of ongoing dependency between
the packages in the two images. Does "pkg -Z '*' install application/foo" tag
application/foo to be kept in sync? Assuming the answer is yes, consider the
following operations:
# zoneadm list -i
global
z1
z2
# pkg -Z '*,!z2' install application/foo
# zoneadm -z z3 install
# zoneadm -z z4 clone z2
Is application/foo synced in z3 and/or z4? Is there a way to change whether a
package is synced or not? Also, what happens if the above example is continued
with:
# zoneadm -z z1 detach
# zoneadm -z z1 attach
# zoneadm -z z2 detach
# zoneadm -z z2 attach
Is that any different than this, where the zones migrate to otherhost and back?
# zoneadm -z z1 detach
otherhost# zoneadm -z z1 attach
otherhost# zoneadm -z z1 detach
# zoneadm -z z2 detach
otherhost# zoneadm -z z2 attach
otherhost# zoneadm -z z2 detach
# zoneadm -z z2 attach
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
--
Mike Gerdts
Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
