Bug 836782 - NM flawed design needs changes
NM flawed design needs changes
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-07-01 05:51 EDT by udo
Modified: 2012-08-29 09:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-29 09:32:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description udo 2012-07-01 05:51:41 EDT
Description of problem:
After migrating a ferfectly working Fedora 16 box to Fedora 17 I found that the ethernet interface got a DHCP number instead of the configured static IP.
I found that  after dowing: ifdown eth0; ifup eth0 the desired static IP was assigned.
I concluded that NM was the fault.
I found that NM has an administration of its own.
I found that none of the existing correct configuration was migrated to this new situation.
I found that this NM administration has doubled info from the ifcfg-eth0 script.

Version-Release number of selected component (if applicable):

How reproducible:

Actual results:
See above

Expected results:
No doubling of configuration info, no change in configured behaviour 

Additional info:
We really need a much simpler version of NM without all the strange ideas but with the possibility to use a GUI to configure a network device; this simpler NM should NOT have a mind of its own.
Comment 1 Pavel Šimerda (pavlix) 2012-08-29 06:18:18 EDT
Please use descriptive summaries. This one is useless.

Please attach configuration files, logs, as much information as you can.
Comment 2 udo 2012-08-29 09:05:30 EDT
I corrected the situations and described what I could.
So I cannot currently easily reproduce the situation.

NM is a pain in the butt.
NM cannot cope with hardware without a static hardware address. (fact)
NM chooses not to trust udev which is THE place for device naming. (fact)
NM keeps a separate administration from teh 101% working network scripts, duplicating stuff for no reason. (the root cause for this bug) (fact!)

So no real logs are neded.just a chat with the main developer(s).
All these issues occur with simple wired connections. No wireless, no ppp, no ipv6-related issues.
Comment 3 Pavel Šimerda (pavlix) 2012-08-29 09:32:13 EDT
Please submit individual bug reports with steps to reproduce, observed behavior and expected behavior. Or write a blogpost on how NetworkManager sucks.
Comment 4 udo 2012-08-29 09:40:02 EDT
The source is there to prove these hard accusations.
If you let a dev run loose to create this Frankenstein then it was not my fault.

I forgot to mention the dependency-hell.

As you may understand I use this system daily.
So after upgrading I make it work ASAP.
Only afterwards, when IP works again, I can think about filing reports.
The other issues are longer standing and make one wonder about the design process.

Note You need to log in before you can comment on or make changes to this bug.