On Fri, May 28, 2010 at 05:04:07PM -0700, Danek Duvall wrote:
> "core-os" seems like it might end up being overly broad, given that, at
> least at the moment, it covers the entire WOS.
>
actually, that is kinda the point (ie, covering the entire WOS).
one of the features of sparse zones in s10 that system administrators
like is that they can basically manage all their "system software" (ie,
the WOS, or as they usually call it "all+oem") from the global zone, but
each zone can still have an independent application stacks that can be
managed from within the zones. so by providing {sync|mirror}:core-os,
we can basically allow for maintenance of all the "system software" from
the global zone while zones are still able to install and run whatever
additional application they want. (and in the case of "sync", the zone
can still be minimized.)
if administrators want to allow different WOS bits between the zone and
global zone then they should use minimal and not core-os.
> How is "minimal" defined? Is it hardcoded to a list of packages somewhere?
>
the minimal set of packages is all packages that are tagged with the
"cip" attribute. the "cip" attribute is a new packaging attribute that
we'll be introducing, and it will indicate that a package must be kept
in sync between a zone and the global zone. basically these will be
packages that define or consume kernel interfaces. it'd be impossible
to hard code this set of packages into a list because we don't know
about all the publishers that may publish packages with this attribute.
(more about this below.)
> It seems to me that you might as well make the leap to allowing package
> names (or patterns) for the group, and replace "minimal" with some
> well-known package name that defines the minimal set of packages, and
> "core-os" with the incorporations that carry those attributes. Or maybe
> not ... ?
>
the argument against this is that i can't represent the minimal set of
packages as another package without making that a dynamic package. for
example, the virtualbox package will have the "cip" attribute set since
it delivers a kernel module and an application that consumes those
kernel interfaces. so if we had a package that represented all cip
packages, the contents of that package would vary based on if an image
was configured with the "extra" repo or not. also, we don't know what
third parties might deliver packages that need to have the "cip"
attribute set.
> "sync" and "mirror" act very much like "incorporate" and "require" do for
> dependencies (though the versioning for the depend actions isn't exact). I
> wonder if there's some convergence, either in terminology or in mechanism,
> that could be done here. I'm not sure that sync and mirror really say what
> you want them to, but perhaps I've been drinking the pkg(5) terminology
> kool-aid for too long.
>
they are similar and in fact internally the implementation uses
"incorporate" and "require" dependencies to implement these policies.
i could adopt the same terminology if that seemed more intuitive to
folks, but at the same time i'll point out that the behavior of
sync/mirror vs incorporate/require is not exactly the same. (and i
don't really think it'd be appropriate, but i could always be
convinced.)
specifically, both the sync/mirror policies have the rule that you can't
install a package governed by the policy into a zone unless it's
already installed in the global zone. so for example, say you had a
policy of "require:core-os" (instead of "mirror:core-os"). given the
existing package terminology, to me this seems to imply that you should
have all core-os packages installed. but that's not actually the case.
the only core-os packages installed in a zone would be those that are
installed in the global zone, and a zone would also be unable to install
new core-os packages. (installing new core-os packages would have to be
done in the global zone, and the process of doing that would
automatically install those packages into the non-global zone as well.)
> Will administrators in the zone be able to modify these policies?
> Typically "image properties" are stored in the image, and not external to
> the image, which means that zone admins could violate policy set by gz
> admins.
>
no. so the storage of linked image properties varies by different
linked image type. this bleeds over into the larger linked image
design. in the case of zones linked images, the linked image content
policy will probably be set via zonecfg(1m) in the global zone.
subsequently the policy will be conveyed to the zone and the pkg(1m)
command within that zone will respect the policy that has been given to
it.
obviously a user in a zone could hack around this and violate the
policy, but then again they have write access to their filesystems and
in the end they can do whatever they want. (incidentally, this is why we
never trust a zone image once it's been booted.)
ed
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
