On Thu, Feb 28, 2019 at 01:32:12AM -0800, si-wei liu wrote: > > > Will the > > > change break userspace further? > > > > > > -Siwei > > Didn't you show userspace is already broken. You can't "further > > break it", rename already fails. > It's a race, userspace tends to give slave a user(space) desired name but > sometimes may fail due to this race. Today if failover master is not up, > rename would succeed anyway. While what you proposed prohibits user from > providing a name in all circumstances if I understand you correctly. That's > what I meant of breaking userspace further. On the other hand, you seem to > tighten the kernel default naming to udev predictable names, which is > derived from only recent systemd-udevd, while there exists many possible > userspace naming schemes out of that. Users today who deliberately chooses > to disable predictable naming (net.ifnames=0 biosdevname=0) and fall back to > kernel provided names would expect the ethX pattern, with this change > admin/user scripts which matches the ethX pattern could potentially break. Whatever crashes with a name not matching ethX will crash on the standby interface *anyway*. So I think what you are saying is that someone might have already written scripts and gotten them to work on v4.17 when STANDBY was included and these scripts rely on ethX. Now these scripts will break. Maybe it is still early enough (just half a year passed) that the number of these users would be small. So how about a kernel config option and maybe a module parameter to rename the primary? People can then opt in to the old broken behaviour. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
