On 12/21/2017 04:17 AM, Sam Varshavchik wrote:
I'm not sure I see why this has to be a factor.
Because NetworkManager is an event-driven system. If an interface loses
carrier for a defined period of time (5 seconds prior to the commit I've
referenced), NM will remove the IP configuration from that interface.
When an interface changes state and gets a link, NM will add the IP
configuration to that interface. There isn't an option in NM to assign
configurations to interfaces regardless of their state.
The fundamental problem is that NM had a hard-coded delay for link state
changes. Prior to NM, some systems still had boot problems due to long
link negotiation periods, as in Francis' case with NFS mount failures.
The old "network" service had provisions for this. You could set a
custom delay if you had an interface that took a long time to come up.
NM didn't have this, which contributes both to your problem and to
problems like Francis'.
But why is there a problem with simply reading a configuration file
that says: "assign this static IP address to the port", and then
assigning this static IP address to the port? That's all anyone wants
to do here. Nothing more. Everything will then boot normally.
You can always suggest to the NM team that event-driven configuration is
inappropriate in some instances, and that interfaces should be
configured regardless of state.
There's such a basic, fundamental disconnect here, somewhere,
not sure I can even describe it correctly. But to me, all of this
seems to be a no-brainer. There's an IP address in the ifcfg file.
nm-online simply needs to wait until this IP address is assigned to
the network port. The End.
I understand what you're saying. It's just that static configuration
isn't what NM does. The old network service does, and I sincerely hope
no one ever suggests deprecating the network service unless NM offers
that mode of operation, which it does not, today.