On 06/12/12 18:50, Edward Pilatowicz wrote:
On Fri, Jun 08, 2012 at 06:46:51PM -0700, Danek Duvall wrote:
Shawn Walker wrote:
On 06/08/12 15:14, Brock Pytlik wrote:
:) Yeah, I thought about -I, but we already have that option, though
undocumented and at the subcommand level, but since it has a meaning
that I thought was nearly opposite of what we wanted, I thought that
wasn't a good choice. Perhaps -i?
I think the issue is that with all of the zone utilities, -z refers to
the name of the zone, so that's going to be a hard thing to get out of
people's heads, and they're also likely going to keep typing '-z' instead
of '-Z' since that's how the zone utilities also work.
-C would have been nice here for 'child', but Ed has stolen that for
concurrency.
Ed hasn't put back yet, so the conversation is still open. -I could be
repurposed, too, if we really wanted it.
i'm totally willing to switch from -C to something else (the other
option i considered was -P, but imo "parallelism" doesn't quite roll of
the tongue as easily as concurrency.
Personally, I'd just punt on the more generic child images case and just
handle zones. If we do that though, that would suggest we use '-z' for
consistency with the zone utilities.
I'm curious to hear about plans for non-zone child images which we might
want to update in such a complex fashion. While I can dream up all sorts
of noxious, Lovecraftian scenarios ("The Imagewitch Horror", "The Image
from Beyond the Deep", etc), I think we're basically looking at zones and
at pretty simple child images, or at least ones which are sufficiently
detachable that trying to name them in any rational way defies my limited
abilities for comprehension.
Certainly nothing about Brock's proposal seemed to me to be useful for
images other than zones, but I'm willing to believe my imagination here is
a bit limited. (Thus my proposal of -Z, and, eventually, of -B, for
"operate in this non-live BE", which is also a rationally named image.)
when doing the original linked images project, the other scenario i had
in mind was diskless clients. the model i imagined was a "master" image
(that was never booted) and diskless clients were children of that
image. then updates could just be done on the master and automatically
propagated to all children. that said, i don't think we support
diskless boot in s11 and even if we did there's a ton of other deployment
utilities that could be used in this scenario.
The only "diskless" boot we support in Solaris 11 is booting from iSCSI
targets, which are of course usually just blobs of disk space from the
server point of view. Other scenarios might be of interest at some
point, but they're mostly in the realm of booting multiple machines from
a single (or small number of) read-only image.
Dave
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
