On Tue, Jun 12, 2012 at 06:51:14PM -0700, Brock Pytlik wrote:
> 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.
>
yes. but i'm just saying that from a UI perspective, we could provide a
recursion control command that only allows the user to specify zones
(which are a specific type of linked image and can only be nested one
level deep), not any arbitrary linked image (which could be nested
multiple levels deep). so if there were user linked images we would
just always recurse into them.
also, i want to back up a second just to try and clarify a very
confusing point when talking about recursion (and make sure we're all on
the same page).
say i have a system with two zones, z1 and z2.
if we have a -z option that selects zones for recursive operations, then
imo the following two commands are equivalent:
pkg -z global uninstall foo
pkg uninstall foo
both these commands will do an uninstall in the global zone, and they
also recurse into z1, and z2. but when they recurse they will only do a
linked image sync, not an uninstall. if i did:
pkg -z global,z1 uninstall foo
then we'd do an uninstall in the global zone, and then we'd recurse into
z1 to do an uninstall, and recurse into z2 to do a sync.
we always need to recurse into all zones to make sure they stay in sync
because if a zone gets out of sync it becomes broken and unbootable.
so the confusing bit is that "recursion" flag we're talking about here
doesn't actually control which images we recurse into, it controls what
operation is done when we recurse. i haven't come up with good
terminology to differentiate between these two types of recursion. ie:
1 a package operations that recurses into children to perform the same
operation that was done in the parent.
2 a package operation recurses into children to perform a sync.
i'm open to suggestions for better ways to name these different
behaviors.
> >>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.
>
i *really* don't think we want recursive operations to be by default.
i also don't think that doing this allows us to remove the sysrepo,
since it's still possible for folks to run commands inside a zone and
change publisher configuration.
if you want to have that kind of functionality, then as i mentioned
before, we should create a policy control that says the packages
installed in a zone should match those installed in the global zone.
i think that the default behaviors i chose for the linked image project
are correct. by default we want recursive syncs. also, i think that if
we changed the way update works (from being a recursive operation to
being a recursive sync), i don't think that most folks would notice a
difference.
> >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"
like i said, this is really a policy choice, and if we feel that it's
too confusing we can choose not to implement it.
we can't dictate "all images must be kept in sync" to users, there are
zones deployments where that just won't work.
also, recursive operations by default don't actually implement this
policy since i can always operation on zones images directly (from the
gz or from within the zone) to bring the image out of sync with the
stated policy.
ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
