On Wed, Jun 01, 2011 at 08:20:18AM -0600, Susan Kamm-Worrell wrote: > 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'. >
np. really, the format for zoneadm is: zoneadm -z <zonename> [ <options> ] subcommand [<subcommand_options>] [<subcommand_args>] and putting <brand_subcommand_options> after <subcommand_args> just doesn't seem right to me. afaik, no subcommands distinguish between <subcommand_options> and <brand_subcommand_options>. > 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. > this is generally true, so if this wasn't done it would clearly be a bug that would need to be fixed asap. :) > 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. > grumble, grumble, grumble, i guess so... please get bugs filed on the issue. > >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. > sigh. supporting two frameworks is kinda confusing so i was hoping to keep the code for the old one to a minimum. but i understand what you're saying, so ok. could we get a bug filed on ripping out the support for the old framework? ed _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
