Libguestfs - Jan 2014 - Re: [Bug 1046905] New: RFE: add argument to virt-sysprep to disable individual default operations

On Friday 27 December 2013 10:58:15 you wrote:
> virt-sysprep either runs with all default operations or a selected
> list of operations with the --enable argument.  A few times I've
> found I'd like to use the default list, but minus one or two
> operations in particular, however there's no easy way to specify
> this.
> 
> A --disable argument that took the default operation list and skipped
> selected operations would be useful.
A rough idea I had about this is adding a new --operations parameter, 
which would take a a comma-separated list of operations (just like the 
current --enable), but with the following differences:
- a leading minus would disable the specified operation
- it would recognize the meta-keywords "all" (for all the available
  operations) and "defaults" (for the ones enabled by default)
Processing the list of operations would add/remove them from the current 
set of operations, bailing out whether the resulting set is empty (just 
like right now --enable rejects an empty string).

This way, you could write e.g.:
- --operations defaults,-hostname,user-account
  runs the default ones but not "hostname", and the non-default
  "user-account"
- --operations all
  easy shortcut to run all the available operations
and so on.

--enable could just be an alias for --operations, or this new syntax 
could be added directly to --enable directly.

Maybe I'm over-engineering, but IMHO seems a better way than potentially 
adding a --disable argument and deal with the order of
--enable & --disable and their interactions.

-- 
Pino Toscano

On Tue, Jan 07, 2014 at 11:16:08AM +0100, Pino Toscano
wrote:
> On Friday 27 December 2013 10:58:15 you wrote:
> > virt-sysprep either runs with all default operations or a selected
> > list of operations with the --enable argument.  A few times I've
> > found I'd like to use the default list, but minus one or two
> > operations in particular, however there's no easy way to specify
> > this.
> > 
> > A --disable argument that took the default operation list and skipped
> > selected operations would be useful.
> 
> A rough idea I had about this is adding a new --operations parameter, 
> which would take a a comma-separated list of operations (just like the 
> current --enable), but with the following differences:
> - a leading minus would disable the specified operation
> - it would recognize the meta-keywords "all" (for all the
available
>   operations) and "defaults" (for the ones enabled by default)
> Processing the list of operations would add/remove them from the current 
> set of operations, bailing out whether the resulting set is empty (just 
> like right now --enable rejects an empty string).
> 
> This way, you could write e.g.:
> - --operations defaults,-hostname,user-account
>   runs the default ones but not "hostname", and the non-default
>   "user-account"
> - --operations all
>   easy shortcut to run all the available operations
> and so on.
> 
> --enable could just be an alias for --operations, or this new syntax 
> could be added directly to --enable directly.
> 
> Maybe I'm over-engineering, but IMHO seems a better way than
potentially
> adding a --disable argument and deal with the order of
> --enable & --disable and their interactions.
Seems reasonable.

I guess only one --operations opt is allowed?

Or would we allow multiple and concatenate them together?  So that

  --operations foo,bar --operations -baz

would be equivalent to

  --operations foo,bar,-baz

?

Multiple --operations could be useful for scripting, ie. it would let
shell users write:

  opts="--operations all -a disk.img"
  if [ $disable_foo ]; then opts="$opts --operations -foo"; fi

Another thing to test is whether the OCaml argument parser[1] can
handle '--operations -foo' without thinking that -foo is a separate
arg.

Rich.

[1] It is not as sophisticated as GNU getopt, and a very long way from
Perl & Python's amazing command line handling.  See:

http://caml.inria.fr/mantis/view.php?id=5197

as an example of one of its shortcomings.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

On Tuesday 07 January 2014 12:12:43 Richard W.M. Jones
wrote:
> On Tue, Jan 07, 2014 at 11:16:08AM +0100, Pino Toscano wrote:
> > On Friday 27 December 2013 10:58:15 you wrote:
> > > virt-sysprep either runs with all default operations or a
selected
> > > list of operations with the --enable argument.  A few times
I've
> > > found I'd like to use the default list, but minus one or two
> > > operations in particular, however there's no easy way to
specify
> > > this.
> > > 
> > > A --disable argument that took the default operation list and
> > > skipped
> > > selected operations would be useful.
> > 
> > A rough idea I had about this is adding a new --operations
> > parameter,
> > which would take a a comma-separated list of operations (just like
> > the current --enable), but with the following differences:
> > - a leading minus would disable the specified operation
> > - it would recognize the meta-keywords "all" (for all the
available
> > 
> >   operations) and "defaults" (for the ones enabled by
default)
> > 
> > Processing the list of operations would add/remove them from the
> > current set of operations, bailing out whether the resulting set is
> > empty (just like right now --enable rejects an empty string).
> > 
> > This way, you could write e.g.:
> > - --operations defaults,-hostname,user-account
> > 
> >   runs the default ones but not "hostname", and the
non-default
> >   "user-account"
> > 
> > - --operations all
> > 
> >   easy shortcut to run all the available operations
> > 
> > and so on.
> > 
> > --enable could just be an alias for --operations, or this new syntax
> > could be added directly to --enable directly.
> > 
> > Maybe I'm over-engineering, but IMHO seems a better way than
> > potentially adding a --disable argument and deal with the order of
> > --enable & --disable and their interactions.
> 
> Seems reasonable.
> 
> I guess only one --operations opt is allowed?
> 
> Or would we allow multiple and concatenate them together?  So that
> 
>   --operations foo,bar --operations -baz
> 
> would be equivalent to
> 
>   --operations foo,bar,-baz
> 
> ?
> 
> Multiple --operations could be useful for scripting, ie. it would let
> shell users write:
> 
>   opts="--operations all -a disk.img"
>   if [ $disable_foo ]; then opts="$opts --operations -foo"; fi
I agree, allowing multiple --operations is a good thing. After all, 
given the proposed behaviour, every --operation would alter the existing 
set of operations (empty at the first --operation invocation, as with
--enable), instead of starting from scratch every time.
> Another thing to test is whether the OCaml argument parser[1] can
> handle '--operations -foo' without thinking that -foo is a separate
> arg.
Ah yes, I read about the unsupported --foo=arg syntax.
OTOH, it seems that "--foo --foo", with --foo taking an Arg.String, 
gives "--foo" as value for it, so should be safe for us.

-- 
Pino Toscano