On 07/17/2012 08:07 PM, Will Woods wrote:
On Fri, 2012-06-29 at 13:24 +0200, Radek Vykydal wrote:
Hi,
this proposition is mainly for Will. Currently we create missing
default ifcfg files
(i.e. file of devices not activated in dracut or configured by
kickstart) in anaconda:
[...]
This has a problem that NetworkManager activates default connections
for devices lacking ifcfg file which differs from behaviour in rhel6
and
I think we don't want to start to do this.
Why not? Why is it our job to maintain policy for when to start network
interfaces? And why should that policy differ from the normal system?
Actually we have been always setting the policy (of which devices should
be activated on first boot)for normal system. I think configuration of which
devices should be activated after installation is something we need
to be able to set/control in installer.
Here's a general rule I'm trying to follow for anaconda:
Unless there is an *explicit, documented* use case that requires
otherwise, we should use the system defaults.
When the system defaults conflict with current anaconda behavior, yes,
that will require behavior changes. But *not all behavior changes are
bugs*.
In this concrete case it is anaconda which is setting the "system
defaults" [1].
Our policy (for both normal system and anaconda) has been: don't activate
device unless it was activated during installation (using the device,
--activate
option) or explicitly configured (onboot value in ks, or in GUI) [2].
Can we drop current behaviour?
The rhel (server) realm will require to keep current policy. No matter
if we will decide to keep it for Fedora, I am trying to get ready to
the pile of BZs asking to bring the behaviour back and make fixing them
less painful.
I am not contesting the change of policy, if we want to do it for Fedora,
all right. I care to keep *ability* to set some configuration/policy
(i.e. set ONBOOT in ifcfg files) and to be able to set it consistently
for anaconda and normal system.
If there's a reason that we *need* to have a *completely different*
policy for unconfigured network interfaces inside anaconda from the
normal system, that's fine - let's talk about those use cases and figure
out the best thing to do.
Currently (in noloader) with your patch we are creating default ifcfg files
in anaconda. That means they will be there for NM in "normal system",
but not for NM in anaconda environment. With my patch, they will be there
both for anaconda and normal system - which is step towards unifying the
two,
not making them different.
You are assuming here the policy of normal system is activating unconfigured
devices. There is no such policy, it is just behaviour of NM.
I was trying to keep in mind installations without NM, e.g. what
minimal install used to be although think NM is becoming part of minimal
install
so we might not worry about this case.
Also I'd like to bring back functionality of --activate option,
but activation of additional devices could be done in anaconda
kickstart processing, even though doing that in dracut might be
as simple as writing ONBOOT=yes by dracut/ks to ifcfg file.
..or we could add a --no-activate option to override the system default
behavior, if the user so chooses?
Sure, --activate fits into our current policy. If we drop/change it
to activate everything by default then we'll want --no-activate instead.
There are also some technical issues with not having control over
device configuration with ifcfg files [3] (e.g. NM and root on iSCSI),
but I will put them aside now.
Radek
[1] for which devices should be activated on first boot
[2] this has been sightly modified in Fedora to ensure activation
of some device after reboot
[3] NM doesn't write configuration of auto (missing ifcfg) connections
into ifcfg files.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
