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. > 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.) [ 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. ] > 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. > 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. 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. ed _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
