How to support disabling of activation of first kickstart network command?

[Radek Vykydal]

Hi,

For compatibility with RHEL 6, and kickstarts out there, we always
activate the device of the first network command in installer
environment (we are assuming --activate option). The problem is that
there is no way to turn this default off.

There are BZs appearing that hit this limitation [2]. The use case is:
- configure a device for installation in dracut stage (to fetch
kickstart, or perhaps even the payload) - via boot options
- use another configuration of the device for target system - via kickstart

Activating the target system configuration in installer (after
switchroot) can result for example in unreachable source,
disconnected/stalled nfs mount of installer image, ...

I can see three options to support such use cases:

1) A workaround: use dummy first network command with non-existing
device. Anaconda will just ignore it:

network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4

Or in case hostname is configured, use this as first network command

network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4

... well, it is just an ugly workaround

2) Change the behaviour - treat the first network command same as other

network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4

... I am afraid we can't afford such a change with respect to users
already relying on current behaviour.IIRC

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?


Radek

[1] or reactivate it with kickstart configuration in case it has been
already activated in dracut
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1338631
https://bugzilla.redhat.com/show_bug.cgi?id=1277975

[Radek Vykydal]

Post by Radek Vykydal
1) A workaround: use dummy first network command with non-existing
network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
Or in case hostname is configured, use this as first network command
network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4

I mean
network --hostname=mynode
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4

[Brian C. Lane]

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

[Radek Vykydal]

Post by Brian C. Lane

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.

[Radek Vykydal]

Post by Radek Vykydal

Post by Brian C. Lane

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.

[Chuck Anderson]

Post by Radek Vykydal
Now to me it seems we need to use "--donotactivate". Perhaps Chris
could have some idea, but I am out of them.

--no-activate may be better. It is common to negate arguments by prefixing them with "no".

[Brian C. Lane]

Post by Chuck Anderson

Post by Radek Vykydal
Now to me it seems we need to use "--donotactivate". Perhaps Chris
could have some idea, but I am out of them.

--no-activate may be better. It is common to negate arguments by prefixing them with "no".

Good point, and it's shorter :)