Created attachment 558841 [details]
Use 'ip addr' instead of ifconfig

I updated net-tools in rawhide to upstream git snapshot.
The ifconfig output is now little different (see bug #784314).
Fixing cloud-init to understand the new output format is nonsense as
ifconfig has been deprecated for long time and 'ip addr' should be used instead.
And that exactly does my patch.
As you can see the code is now much shorter and more simple
while the output is almost identical
so I think it should be easily acceptable for upstream.

Created attachment 558845 [details]
Use 'ip route' instead of 'route'

Unlike the previous patch this one could be harder for upstream to accept as the 'ip route' output is quite different from 'route' output. However the main argument for the change remains, i.e. 'route' tool is no longer being developed and 'ip route' plays more nicely with nowadays kernels.

Good idea.  I submitted this upstream; let's see what they have to say.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

*** Bug 949832 has been marked as a duplicate of this bug. ***

Moved to https://bugs.launchpad.net/cloud-init/+bug/925145

*** Bug 1496124 has been marked as a duplicate of this bug. ***

Since the bug opened to cover this, blocking the tracking bug, was closed as a duplicate and that upstream the bug is still open this needs to be re-opened so it actively blocks the tracking bug.

CLOSED/UPSTREAM is valid for the situation it's been fixed upstream and it's just pending a new release upstream to get sucked into Fedora.

As this is an issue that still actively affects Fedora it needs to be open so that it's visible and correctly blocks the tracking bug to keep an eye on the progress.

The assignee has also been reset since this was from 2 years ago and the current package details may have changed.

I did a review of the patch this morning.

Ignoring the BSD etc issues that mean ifconfig probably still needs to be run as a fallback if ip is not found (so unfortunately I don't think it valid to just swap out the util.subp(["ifconfig", "-a"]) in the current code to "ip" instead) ...

It's not just ifconfig and route but also netstat being called that needs to be changed.

I think that should be it though.

Garrett are you in a position to drive this forward or would some assistance be appreciated?

After finishing off facter this looks like the next most troublesome package to fix up.

Since the cloud platforms I have access to don't generally employ the sort of instance-driven network configuration that cloud-init can do I am hesitant to try and fix the issue myself, but I am happy to pull in patches once they exist.  If you have the cycles to work on this I would certainly appreciate it.  Upstream suggested using python-netifaces as a means of abstracting the platform-specifics away; doing that might make the fallback you mentioned unnecessary.

To be frank, I am *this* close to forking net-tools just so I can go back to using the same network management commands that I use on every other operating system.  If all else fails, that would make this issue go away, too.

Upstream both suggested that and declared they wanted to avoid additional dependencies ...

Reading through the launchpad project history and issues ... well ... it's not very well resourced it appears.

I don't have a platform to actively test this on, but now Facter3 is done I do have some availability to update patches and try for a push upstream... 

On a side note ... forking net-tools doesn't help the issues at hand as it's fundamental problems with net-tools ... it uses the ioctl API rather than the netlink API which is why it's missing information about routing tables, IP addresses assigned and so on ...

You could re-write net-tools against the netlink API but that would be a lot of effort and would probably get minimal assistance from the network stack kernel maintainers as they already maintain iproute2 themselves ... and would probably be reluctant to maintain two things themselves for the same tasks.

You might want to review this old LWN article: https://lwn.net/Articles/710533/

There's previously been discussion of a wrapper... especially within RHEL where consistency of behaviour is critical ...

https://bugzilla.redhat.com/show_bug.cgi?id=687920#c8

--------------------------------------

This is a comment from the previous net-tools maintainer I found in one (private) RHEL bug, where the wrapper for 'ip' to emulate ifconfig was also discussed:
"we've already tried that but the command line options of both commands
differ significantly. In fedora most of the
scripts (initscripts/networking) has been using iproute commands now and we're
trying to teach customers to switch to ip as well. (iproute has active upstream
following kernel changes closely, immediately bringing features kernel adds
into iproute releases). 

Wrapper is one option, but that would have to be properly staffed. We're
talking not only about ifconfig but as well about netstat and other tools
net-tools package is providing. All of them have their equivalents in other
packages, but unfortunately we still have customers relying on net-tools."

---------------------------------------

On the bright side once this work to use iproute2 is complete it is going to be safer looking forwards towards RHEL8 etc.

Yes, I went down the wrapper route as well some time ago before realizing it would be far more maintainable to port the entire suite to netlink.  It isn't like iproute2 is the only thing that uses that interface.  As always, it's just a matter of finding enough time to finish it, but if it means Fedora can behave consistently with every other operating system again it will be well worth the effort.

You're right about cloud-init being understaffed.  Most of its main maintainers have their hands full with wrangling all the different cloud platforms and operating systems out there that they need to support, so technical debt like this often goes neglected.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.