On 06/12/12 16:22, Edward Pilatowicz wrote:
On Thu, Jun 07, 2012 at 08:13:51PM -0700, 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.
[ snip ]
i kinda like scheme 1. yes it's not as expressive as 2, but i think
it's less complex.
also, if we limit our name matching to zones names then that simplifies
things.
I'm confused. I thought in your other email, you agreed that push linked
images, which may include User images, would get affected by recursive
operations. If that's the case, then you'd need to match on more than
just zone names here.
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.
once we have recursive operations, this could be changed to do a sync.
(for consistency, i kinda this it should be changed.)
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).
fyi, during a sync, installing of new packages is allowed. (in general
this will only happen when updated packages have new dependencies.)
Thanks, I wasn't sure if that was allowed or not.
[ snip ]
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
these situations should be addressable via support for basic recursive
operations.
[ on a side note, for things like recursive uninstall, we'll want a new
uninstall options that allows fmri patterns passed to uninstall to not
match any packages, since we probably want to support doing a recursive
uninstall of a package in the parent that isn't present in all child
images. ]
If that's the case. Then I'd suggest that "recursively do this on all
zones/images" become the default for how pkg works. Otherwise, users are
going to be specifying -Z '*' (or whatever) very often, especially if
'pkg update' is changed as suggested above. I'd also suggest that if
this is really how we want the CLI to work, we rethink whether having
the sysrepo makes much sense. Perhaps we'd still need it because it
provides connectivity, but we could VASTLY simplify things if we removed
the publisher synchronization and just make sure that users set their
publishers recursively. In short, I see little to no reason why
publisher configuration should be the single situation where we try to
force the NGZ to not cause problems for the GZ.
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.
i think that solving these problems lies outside the scope of basic
recursive operation support.
Well, if every operation I do by default is recursive, then this isn't
likely to be an issue since a user would have to go out of their way to
introduce differences between the parent and children. If it's not, then
be aware that these problems are likely to crop up if recursive
operations are our general solution.
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).
this wouldn't allow us to remove the system-repository since there is
still the accessibility issue. ie, there are no guarantees that a zone
will have access to all the repositories configured in the global zone.
No, I agree the accessibility the system-repository is probably still
needed. Though, there's no reason we couldn't insist that all file repos
get handled via file system mounting and as a bonus get the ability to
lofs mount NFS file systems from the GZ into the NGZ, a nice RFE in
itself, and remove that from the system repository. Then the only issue
would be child images with different network access.
also, the only benefit i could see to this would be that it would keep
all images in sync. some customers would like that (it harks back to
the implicit package namespace sync required by sparse zones in s10).
but if we want to support that i'd want to control that via some kind of
image (or linked image) policy knob.
I'm not in favor of a knob here. We don't need another way to confuse users.
I happen to think that the benefit of "keeping all images in sync" and
"doing what I told it to do" are significant benefits for
administrators, especially since we have backup BE's and the -n option.
As I described above, I think making users remember to explicitly
specify to recurse into child images for (nearly) every command they
type is not a good UI and will introduce quite a bit of frustration with
our users, especially if the behavior of pkg update is changed. If we do
make it the default for every command, then at least for most users,
most commands will work. I'd suggest though that at least install and
set-publisher wouldn't recurse by default since that would rarely be
what you wanted, which would mean now we'd have two classes of commands,
those that recurse by default, and those which don't, which seems very
user unfriendly.
ed
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
