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
On 24.5.2016 14:28, Radek Vykydal wrote:
- 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
I mean network --hostname=mynode network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
On Tue, May 24, 2016 at 02:28:49PM +0200, Radek Vykydal wrote:
- 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
On 24.5.2016 20:37, Brian C. Lane wrote:
On Tue, May 24, 2016 at 02:28:49PM +0200, Radek Vykydal wrote:
- 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.
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:
- 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.
On Wed, May 25, 2016 at 02:14:25PM +0200, Radek Vykydal wrote:
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".
On Wed, May 25, 2016 at 09:29:03AM -0400, Chuck Anderson wrote:
On Wed, May 25, 2016 at 02:14:25PM +0200, Radek Vykydal wrote:
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 :)
anaconda-devel@lists.stg.fedoraproject.org