[ resend after dropping lots of quoted command output ]
- in clone, it seems weird that we're adding arguments after the
zonename, it seems like all arguments should come before the zonename.
- it's really weird that unconfigure_zone() can reconfigure a zone.
can we rename it to reconfigure_zone() (and then if no argument is
supplied it doesn an unconfigure.
- in unconfigure_zone(), for the old sys-unconfig case, you are no
longer checking the error code being returned. (instead your check
the error code from the safe_copy())
- in pkgcreatezone, shouldn't we be checking the return codes from mktemp and
aimanifest?
- in pkgcreatezone, you do:
create_active_ds -r zone
what's the -r option mean. looking at the implementation of
create_active_ds in /usr/lib/brand/shared/common.ksh i don't see
support for a -r option. what am i missing?
- in pkgcreatezone, could you add some comments about how aimanifest is
used? it seems weird that you load a manifest, add entries, but never
save it. but i guess saving is implicit (because otherwise none of
this would be persistent)? so "load" is really copy? and the target
of the copy is AIM_MANIFEST?
- in pkgcreatezone, previously you updated this script to be aware of
both the old (sysidconfig) and new (sysconfig) mechanisms. (i don't
know if those names are right.) is this putback supposed to remove
support for the old mechanisms? or are we still supporting both? if
we're still supporting both when do we anticipate removing support for
the old one?
- why do we care if the svc:/milestone/unconfig:default service is
running in the gz? is that service modifying zone images?
it seems poor to me that we're supporting two different ways of
handling sysconfig for zones. i'd much rather just have one way of
doing this. either just require the unconfig service always be online
and always use it to apply a config, or always ignore that service and
copy over the sysconfig so the zone can configure itself.
- in pkgcreatezone, if the specified sysconfig file is
/usr/share/auto_install/sc_profiles/enable_sci.xml you don't copy it
in. so we silently ignore an option that the user passed us? this
seems bad. why don't we detect this situation and generate an error?
that'd be better than accepting the users option, ignoring them, and
then returning success.
ed
On Tue, May 31, 2011 at 01:14:28PM -0600, Susan Kamm-Worrell wrote:
> Quick update - testing is going well. Dave is running ZTS against
> these latest changes.
> I made some minor changes to the code and have updated the webrev at:
> http://coupe/sw83825/ips-ipkgAIinstall/webrev.ipkg.1
>
> Here's the output from the install. I've also attached the detailed
> Install Log listed
> in the install output.
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
