On 02/17/11 07:22, Dave Miner wrote:
On 02/16/11 11:58 PM, Ethan Quach wrote:
Dave,
Thanks for the review ...
On 02/15/11 12:09, Dave Miner wrote:
On 02/14/11 04:39 PM, Ethan Quach wrote:
All,
I have uploaded the design document for AI Zones support into the
caiman-docs gate.
http://src.opensolaris.org/source/xref/caiman/caiman-docs/AI/AI_Zones_Design.odt
Ethan, comments below.
5.1.2: Several questions here:
- The configuration source must contain exactly these files and no
others?
Other files would be ignored. In the current implementation plan the
exact file names, as defined, under<source> will be what gets pulled
over. The 'profiles' directory needs to be pullled over recursively so
that the file names underneath it can stay arbitrary.
It seems inadvisable to make it this strict, as it makes future
evolution harder. What benefit do we get by restricting?
just precision in the what's getting transferred. We could recursively
get the entire <source> dir itself, but that opens us to potential
unknown sets of files that would appear on the client while doing the
install, as well as on the installed system, and I just wanted to avoid
that.
Is it permissible to tar/zip/<other archive format> them together for
convenience of the user managing them?
We could enable that, but at this point, it's not defined to be
supported.
- Shouldn't we suggest/configure an area in the AI Apache instance to
hold these by default?
That's probably a good idea. If I'm understanding you correctly, this
is so that they don't have to launch their own webserver, correct?
Ease of use, improvements in supportability due to higher levels of
uniformity across the customer base.
OK.
- 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.
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.
-ethan
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
