Jack,
Thanks for the comments ...
On 02/15/11 13:49, Jack Schwartz wrote:
Hi Ethan.
Here are my comments.
Section 2.0:
first bullet: ... do an automated installation OF a global system...
thanks.
Section 5.1.2: Is it possible to set up a sysidcfg file for an S11
zone by mistake? If not, then no problem, but if yes, what happens?
No, the sysidcfg would only be processed for S10 branded zones. But I
am going to remove this from the spec for now (see my response to Dave's
mail) since we're not going to be introducing support for that via this
project work.
5.1.3: Noted: there is no mention of a Derived Manifests checkpoint
here, but being that's a special case, it should be OK.
Thanks for reminding me of this checkpoint. I actually think we should
not support derived manifests for zone root installs. The underlying
use case for it isn't applicable when installing zone roots. I'll
update the document to note this checkpoint.
5.1.3.1.1:
- top of page 7: s/success of failure/success or failure/g
- Last PP: I don't understand how this could be a future enhancement.
How come the zonecfg zfs_report-ed data sets are not needed to carry
out the install of NGZs when the GZ is installed by AI?
See the paragraph before this. If this occurs, its considered an
invalid zone config. This was OK'ed by the zones team.
5.1.4:
- Nit: 1st PP: get rid of comma before svc:/system/zones/install:default.
- 1st PP: by "mimic" do you mean "be a copy of"? If yes, saying so
would be clearer.
I'll change the sentence to say: " The files underneath that directory
are defined exactly as they are defined for the source zone
configuration files for the <configuration> tag in section 5.1.2."
5.2: Nit: last sentence, 1st PP: s/expect/expected/g
Just checking: NGZs use the same boot_archive as their GZ? That's why
no boot_archive ICT checkpoint is there?
non-global zones don't have boot archives.
5.2.1: s/<add_driver>/<add_drivers>/g
5.2.2.1:
Nit: first bullet: s/the give base/the given base/g
thanks.
Just curious: maybe this is normally how it's done, but it seems that
having separate properties for the lengths of BE_ATTR_FS_NAMES and
BE_ATTR_SHARED_FS_NAMES is redundant. Instead, can't the list be null
terminated or something?
These attributes were copied from the existing be_init() function. I
don't recall if there was a particular reason why we needed the lengths
to be passed in separately. In looking at the way we get the string
array back out from the nvlist, the number of elements of the array is
already given as a separate variable from that call so it does seem
redundant. I'll figure this out during implementation. If it turns out
to be unneeded, I'll leave it out and update this design spec.
5.2.4: Does it make sense to have a single TransferLogs checkpoint
class, which would read a list of files instead? Then if the list of
files changes, you're not changing code, but a list it reads instead.
This seems easier to maintain.
In creating the subclass from the existing TransferLogs checkpoint
class, I was attempting to do just that. i.e. the execute() method is
defined in the TransferLogs checkpoint class, and "reused" by the
subclass. The only thing the subclass would initialize differently
would be a different file list. I've gotten a similar comment from
Darren. Let me think about this some. (I obviously haven't started the
implementation of any these classes yet.)
Nit: sentence between the second and third bullet:
s/transfer this files/transfer these files/g
Same sentence: it may be clearer to say "the same pathname as for the
global zone" instead of "the same location as in the global zone".
This differentiates the same pathname in two zones going to different
places, vs a shared physical location for all zones.
thanks.
-ethan
Thanks,
Jack
On 02/14/11 01: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
General review appreciated, and if so, please try to get me comments
by the end of the week; but I have also pinged individuals to review
particular parts of the document.
thanks,
-ethan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
