Regarding the upgrade/compatibility: If the script is reliable, I'd support option 1, otherwise the upgrade will result in a broken system until the user takes an action based on a message they may very well miss.

This is going to be a one-time pain point. I think I'd prefer for option 2, so that the admins have to take a specific action to move forward. Remember that many admins will be using config-management tools that force the current configuration into place; converting them on an upgrade isn't going to fix their situation and we should account for that in the first place.

I'd prefer that we provide this script as a helpful tool, but we should probably have nfsd simply refuse to accept the older configuration, if that's the path we are on.

(To be clear, I'm +1 for the Change in general; I believe this question can be worked out as we go).

+1

I am +1 for this change as well, and agree that the 2nd option is best. We need to make sure it is well advertised, but I don't like the idea of mangling configs in an update script and calling it done.

Would it be possible to have option 3:
- keep the support for the old format, but emit a warning if /etc/sysconfig/nfs is found and non-empty on each daemon startup
- start the daemon as usual supporting both formats
- in F31, remove the support for the work-around, and support only the new format.

This would give maintainers one release to convert the script, and thing would continue to work all the time.

Would it be possible to have option 3:
- keep the support for the old format, but emit a warning if /etc/sysconfig/nfs is found and non-empty on each daemon startup

There will be a way to continue using sysconfig/nfs as a systemd "drop-in" file
which described in nfs.system(7).

• start the daemon as usual supporting both formats
• in F31, remove the support for the work-around, and support only the new format.
  This would give maintainers one release to convert the script, and thing would continue to work all the time.

There is a python script, nfsconvert, that converts the 15 values in sysconfig/nfs to values in /etc/nfs.conf, iff one of those values are set.

This is going to be a one-time pain point. I think I'd prefer for option 2, so that the admins have to take a specific action to move forward.

After working on this for the past week, I would strongly suggest we go with
option 1 due to the very well written python conversion script call nfsconvert.

Realize there are only 15 values that can be set in that file. So it is not very
challenging to convert those values into nfs.conf. nfsconvert does it very
well by uncommenting the value in nfs.conf then setting it to the given value.

Remember that many admins will be using config-management tools that force the current configuration into place; converting them on an upgrade isn't going to fix their situation and we should account for that in the first place.

Will this break configuration tools... Yes! No question about it. The Red Hat QE team
is dealing with just that problem. The format in sysconfig/nfs is simple different than
in nfs.conf... There is nothing we can do about that... but...

Once converted, those same config tools will be able to manage configs over multiple
distors... which is the one of the reasons to make this change.

I'd prefer that we provide this script as a helpful tool, but we should probably have nfsd simply refuse to accept the older configuration, if that's the path we are on.

This is not possible... with the sysconfig/nfs configuration command line arguments are added. So saying "refusing the older configuration" is saying refuse command line arguments can't happen.

+1 to the change in general.

Here is the key part of this entire update:

See if a sysconfig/nfs to nfs.conf converstion is needed

if [ -f /etc/sysconfig/nfs ]; then
grep "nfs.conf" /etc/sysconfig/nfs > /dev/null
if [ $? -eq 1 ]; then
cp /etc/nfs.conf /etc/nfs.conf.rpmsave
/usr/sbin/nfsconvert
fi
fi

The format is better in this paste that shows the key part

https://paste.fedoraproject.org/paste/T8xeZOcOa1yaL6Il9kU0~A

agreed we accept the Change, but that sgallagh will volunteer to help the Change Owners find a better migration path. (+5,0,-0)