On 25.5.2016 11:11, Radek Vykydal wrote:
On 24.5.2016 20:37, Brian C. Lane wrote:
On Tue, May 24, 2016 at 02:28:49PM +0200, Radek Vykydal wrote:
3) New network kickstart command option --donotactivate with lower
priority
than --activate. Which means it would effectively apply only to the
first
network command, for other commands it is the default.
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
--donotactivate
... does not seem very elegant
In my opinion, for RHEL 7 (and maybe even for master) we should go
with 3)
What do you think?
Maybe add an argument to --activate instead? --activate defaults to
--activate=yes and then they can use --activate=no
AFAIK for optparse which is used in rhel7 pykickstart there is no way
to define “optional option arguments” (unlike with argparse with
nargs='?') - either the option requires an argument or not, so nothing
like
--activate
--activate=no
at the same time.
I'll look if using some callback action for --activate could be a
reasonable way to achieve this.
Turned out that even with action=callback the nargs parameter of option
is honored (default is 1) and strictly checked when using
"--option=value" syntax [1]. So using the callback, it is possible to
handle variable number of option arguments, but not optional option
argument.
Now to me it seems we need to use "--donotactivate". Perhaps Chris could
have some idea, but I am out of them.
On the positive note, having the --donotactivate option may make the
fact that default behaviour is not the same for all network commands a
bit more discoverable (in the sense: "WTF? why two such options? When am
I supposed to use this or that?!?". Maybe.
[1] For "--option value" syntax we could go with nargs=0 and handle
remaining arguments (pop the value) in the callback. But it is
insufficient.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
