Unification of the NFS format

[poncovka]

Summary

During the modularization of the additional repositories, I have noticed that we support two different NFS formats, nfs: and nfs://. We are trying to unify the support for the base repository and the additional repositories as much as possible to reduce the amount of code and prevent inconsistencies. Therefore, it would be great if we could unify the formats as well and eventually support only one of them.

The benefits:

• The Anaconda backend can start to use the unified format right away.
• It will improve the user experience, because the current state can be frustrating.
• Consistency, no special cases in the code and in the documentation.

The plan:

1. Start to support the unified NFS format everywhere.
2. The output kickstart file will use only the unified format.
3. Document the unified format and deprecate the previous one.
4. Show a warning for the deprecated format, but keep the support.
5. Eventually, show an error for the deprecated format and drop the support.

As you can see in the details below, it looks like the formats started to diverge with additional repositories, because only the repo kickstart command and the inst.addrepo boot option support the nfs:// format. Based on that, it would make sense to choose the nfs: format. On the other side, this format can be confusing due to the optional <options> part that is for some reason at the beginning of the string instead of the end. Anyway, none of these formats follow RFC 2224 and we cannot use it without modifications, because it doesn't allow to specify mount options.

I propose to choose the nfs: format and deprecate the nfs:// format. What do you think?

The nfs:// format

Scheme:
nfs://<server>:<path>
nfs://<server>

The inst.addrepo boot option [docs]
inst.addrepo=REPO_NAME,nfs://<server>:/<path>

The repo kickstart command [docs]
Fun fact! This is not documented in RHEL 9 or RHEL 8.
repo --name=REPO_NAME--baseurl=nfs://host:/path/to/repo

The nfs: format

Scheme:
nfs:<options>:<server>:<path>
nfs:<server>:<path>
nfs:<server>

The inst.repo boot option [docs]
inst.repo=nfs:[<options>:]<server>:/<path>

The inst.ks boot option [docs]
inst.ks=nfs:<next_server>:/<filename>

The driverdisk kickstart command [docs]
driverdisk --source=nfs:host:/path/to/dd.img

Other formats

The nfs kickstart command [docs]
nfs --server <hostname> --dir <directory> [--opts <options>]

[poncovka]

@jkonecny12 @jstodola @bcl What do you think about this proposal?

[jstodola]

I propose to choose the nfs: format and deprecate the nfs:// format. What do you think?

I agree.

[poncovka]

Btw. dracut uses, for example, root=nfs:[<server-ip>:]<root-dir>[:<nfs-options>] [docs]. The interesting thing is that anaconda uses the dracut's nfs_to_var function for parsing nfs formats and this function supports all these styles:

• nfs://<server>[:<port>]/<path> defined by RFC2224
• nfs:[<server-ip>:]<root-dir>[:<nfs-options>] defined by dracut
• nfs:<options>:<server>:/<path> defined by anaconda

Therefore, it is possible that some of the anaconda's boot options can work with other variants of the nfs format and some suspicions parts of the code seem to confirm that even though it is not documented.

[bcl]

A quick look at the code history seems to imply that dracut and anaconda were adding this at the same time (late 2009) and IIRC at that time Anaconda wasn't using dracut yet, it was still using the loader written in C. So that may explain the different order of options :)

From pykickstart's perspective it doesn't care what the url is. It does have nfs:// documented in the repo command but that is easily changed, and it doesn't mention options. Lorax and livemedia-creator also don't care, they use pykickstart and the parsed methods.

I would lean towards using the dracut format, with the options at the end, because that form is likely to be more familiar to users.

[poncovka]

I agree with @bcl, it would be better the support the dracut format with the mount options at the end. It shouldn't be too difficult:

• There will be no change for users who don't care about the mount options.
• Thanks to the nfs_to_var function, the amount of changes in the anaconda dracut module should be minimal or none.
• The installer has to be able to parse both formats and show a warning if the mount points are at the beginning of the string. We can use the nfs_to_var function for an inspiration and use a list of common nfs options to be more precise if necessary.

@jstodola @jkonecny12 Would it be acceptable?

[poncovka]

I feel like this change will eventually happen no matter what we decide here, because the mount options at the beginning make no sense. Making this change after the unification will be more difficult. Right now, the mount options are supported only by inst.repo and some other boot options. However, the unified format will be used everywhere and integrated into the DBus API.

[jkonecny12]

I'm more inclined to @jstodola . Using a Dracut format doesn't seems like a big benefit right now when people are already using our current formats. I think that it would be better for them to stick what they know.

However, true is that NFS solution from Dracut is taken from kernel: https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt which makes the format a bit more stable.

On one hand we shouldn't break API for users if we don't have a strong reason to so I'm opposed to change it to a completely new format but instead take this as a fix of inconsistency between API of Anaconda (fix the least used).
On the other hand the proposed format is used by Dracut and kernel which might simplify stuff in the future.

@jstodola given that the Dracut format is not Dracut invention, do you still think it is a good idea to go with the current way instead of switching to something which is more consistent in the Linux world?

[jstodola]

The dracut and kernel formats are not the same, there is no consistency in this world:
dracut: nfs:[<server-ip>:]<root-dir>[:<nfs-options>]
kernel: nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

I'm not strongly against the dracut format, since the current behavior still has to be supported for a while.

The currently documented and the new format should be covered by automated tests to avoid possible regressions before the support for the current format is removed in RHEL-1x.

[jkonecny12]

Ha you are correct, they changed the syntax later in the Dracut:

dracutdevs/dracut@5103130

In that case I'm also against using the Dracut format. It seems that even they changed it and I'm not convinced that we should follow them now instead of kernel or another project. If none of these is taken as standard than migrating us to them gives no point.

I would be in favor of doing as minimal changes as possible which I think is nfs:... solution. It is also closer to the Dracut than the other we have.

[poncovka]

Ok, the nfs:<options>:<server>:<path> format seems to be the winner.