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?
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.
- 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.
- I'm confused as to why we provide sysidcfg support for S10 branded
zones. How would a branded zone possibly appear in a situation where
AI's transport of the configuration would be useful?
This was in anticipation for when AI can be used to support
archive-based install, which obviously won't be implemented by this
project so I will remove sysidcfg from this spec. I'll also update the
document to make clear what capabilities auto_install can provide to
'zoneadm install' via this project.
Thanks.
5.1.3.1.1: The examples provided here could stand to be more complete;
i.e. tying an input file to a corresponding output file so the reader
can grok what AI can expect a bit better.
I'll add what the two 'config' files look like, which is what's really
needed to understand why the output file looks the way it does.
5.2: Does this mean that the system/install/auto-install package will
become a dependency of system/zones?
Yes, it will. So this will probably mean we'll have to refactor the
system/install/auto-install package such that the AI client is delivered
separately from the AI boot image SMF services, and system/zones should
only depend on the former.
5.2.1: I would think the relaxed form would be more useful in allowing
reuse of AI manifests across global and non-global zones. What's the
advantage of making this tight initially?
The reuse of AI manifest across global and non-global is the 'need' I
was thinking could be fulfilled later. But I was trying to keep it
simple in this initial implementation in case we run into unforeseen
issues. I can target the more relaxed case initially if you'd prefer.
5.2.2.1: re: com.oracle.libbe:nbe_handle - I thought I had asked that
the BE properties remain in the org.opensolaris namespace rather than
have this mixed set.
I grabbed this from what is being introduced from the fix for 7007781.
5.2.4: s.var/run.system/volatile.
Will do.
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?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
