On 06/ 1/11 02:33 AM, Edward Pilatowicz wrote:
On Tue, May 31, 2011 at 10:55:03PM -0600, Susan Kamm-Worrell wrote:
Ed,
Thanks for the review.
Responses below.
Susan
On 05/31/11 07:08 PM, Edward Pilatowicz wrote:
[ 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.
For the rest of the commands the brand-specific-options come after all the
common command arguments. I arc'd the extension of clone with that
can you provide some examples? i thought that brand options can be
intermixed with zoneadm options, and zoneadm will just pass unknown
options onto the brand callback.
thought in mind:
(ipkg)
clone [-m copy] [-s zfs_snapshot] source_zone [-c sc_profile.xml | dir]
(s10)
clone [-m copy] [-s zfs_snapshot] source_zone [-c sysidcfg]
well, cli processing in general looks like:
<command> <options> <arguments>
i really really really don't like the idea of supporting:
<command> <options> <arguments> <brand options>
aside from being a bad idea in general, doing this will prevent us from
ever being able to add another argument to the clone subcommand.
wrt arc, i'm sorry i missed this. but we can fix this with a quick
email to the case alias. also, if you think that fixing this will put
you at risk of missing this build then i'd say we just drop the clone
changes from this wad, update the arc case, and deliver the clone
changes next build. (i doubt AI depends on these clone changes.)
I guess this was just my interpretation from the zoneadm manapage:
zoneadm -z zonename [-u uuid-match] subcommand [subcommand_options]
where I understood the subcommand of clone to be 'clone clone_source'.
It's no problem to make this change to clone, but I was under the impression
that all changes associated with an ARC case for a consolidation had to
be pushed together.
The s10 changes already went back with this change. Would it be possible
to push this change, then fix it with a bug fix and updated fasttrack next
build?
Then I could fix both s10 and ipkg consolidations in the same build.
- 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?
Change was pushed into ON build 167 last week.
See file:///net/coupe/builds/sw83825/on-AIinstall-cr2/webrev.ON.3
please add a comment saying we're not creating the ROOT/export datasets.
added
- why do we care if the svc:/milestone/unconfig:default service is
running in the gz? is that service modifying zone images?
No. That service will be enabled when the new SC framework goes live.
Parts of the SC framework have already been pushed to the install gate, but
the final push to enable the framework is enabling that unconfig milestone.
All the checks for this unconfig milestone will be removed once the new SC
framework is integrated and is working.
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.
Going away as soon as the new SC works :)
Having both ways has given the zones code a lot of soak time with the
new SC framework.
cool. so this is more transitory stuff. that makes me feel better.
- 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.
This is an odd situation that will be fixed when the new SC framework goes live.
I need the code in place to use enable_sci.xml for the new SC framework so that
the SC team can test everything in a zone.
For the rest of us still running with the old SC framework, copying that
enable_sci.xml
file into /etc/sysidcfg really confuses the old sysidcfg parser and it prints a
lot of
alarming messages out. There's no failure, but the messages caused concern.
So, I'm checking for the common case of the zones-install service passing in the
enable_sci.xml file and to ignore that file if still using the old SC framework.
All of this mess will be removed soon.
but i thought the -c option allows the user to specify a new sysconfig
profile. i didn't think we were going to support installing old style
sysidconfig profiles with this same option. do we really need to do
that? why not just generate an error if -c or -m are specified and the
new sysconfig mechanism aren't active? (it seems like we're delivering
new features for the old framework that we're about to rip out anyway.)
The plan is for the zones test suites to start using the -c option and to
mimic this code passing in the needed sysidcfg file if the old sysconfig
framework
was in use and to use a profile for the new sysconfig framework. This would
allow
the test suites to be used by both the old and new frameworks.
Once the new SC framework is in place and is working, the tests can also be
modified
to remove the old sysidcfg code.
Susan
ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
