Dave,
A couple of follow up points ...
On 02/21/11 13:55, Ethan Quach wrote:
- I would think that the definition of the default AI manifest for
zones would be part of this document?
It should be, but I just don't have it defined yet. The first issue
that was unresolved was current changes in the target.dtd, but I think
that has solidified enough such that I should be able to draft
something
for that part. The second outstanding issue is the publisher
specification. By default, a zone should be installed from the same
publisher(s) as set on the global zone. I'm not sure yet how to
trickle
that into the default manifest for the the non-global zone.
So far, a couple of high level ideas for this are:
a) Since the<source> element is already specified to be optional, it
could be left out of the default non-global zone manifest. Then
auto_install could recognize that (and the fact that we're installing a
zone root) and grab publisher specs from the running boot image.
b) Make 'zoneadm install' use the aimanifest(1m) interface to update a
copy of the default non-global zone manifest before passing it to
auto_install. This moves the responsibility of grabbing the publisher
spec to zoneadm.
The issue that makes (a) a little difficult is the propagation of exact
publisher spec (including security key and cert) settings set on the
global zone. (The current zone install script does this manually using
the pkg interface) Ideally, what would be nice is a way to
image-create
an image based on specs some existing image, or some concise usage of
the IPS API to do so. So this part is an outstanding issue that this
project needs to figure out with the IPS and zone teams.
(b) seems preferable, as (a) seems to create more zone-awareness
requirements in auto_install, and would also seem to complicate a
hypothetical eventual need to have an S11 brand on something post-S11.
One other thing that may help us here is the linked-image work. In
its current design, there is mention that the linked image
relationship can't be created a image creation time (at least not
through pkg(1)). But if there's an API for this, I think we'd just
use that.
In talking to Ed, what we probably want to use here is the system
repository. See
defect 16149 need system repository to facilitate linked image support
https://defect.opensolaris.org/bz/show_bug.cgi?id=16149
The system repository will provide zones proxied access to the
publishers configured in the global zone. So at a high-level, we'll
probably want to do (a). The steps would hash out to be:
1. Instantiate a zone image at the given root (image-create)
2. Establish it as a linked image to the global image.
3. Enable it to use the system repo.
For the hypothetical case you noted, perhaps we just require explicit
publisher specification in the manifest in that case since it is a
branded zone.
6.2: Why is -Z Private (which isn't specific enough, anyway; it would
have to be qualified, proably as Oracle Private were we to go this
route).
The intent of the option is to be used by the zones team only. Should
this be Oracle Private then?
It's clearly only useful for installing zones, but I still don't
understand why making it private is advantageous?
I don't have any advantageous reason for marking it private.
I will go with Contracted Oracle Private here.
thanks,
-ethan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
