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