RHCS Feature: https://issues.redhat.com/browse/RHCEPH-8256
 
Related RHCS bugzillas:
1) https://bugzilla.redhat.com/show_bug.cgi?id=2259938
2) https://bugzilla.redhat.com/show_bug.cgi?id=2259461

 

What are the use cases this RFE is solving?

 

NFS-Ganesha supports NFSv4.1+ natively; however, NFS v3 is desirable in environments where NFS v4.1+ clients do not exist (Microsoft Windows hosts). 

 

High Level view on how the feature works

In RHCS 7.1, NFS export rules created via the ceph mgr API add NFS v3 and NFS v4.1+ export rules simultaneously. In RHOSO 18, we don’t have support for NFS-Ganesha standalone. If we did, we’d have to modify the export template that is in-tree. No export code changes are required in manila since ceph mgr handles the export structure.

 

Is this feature driver dependent or driver related?

Yes, related to CephFS/NFS

 

Are there any known limitations? (e.g multi attach + encryption)

While NFS v3 and NFS v4.1+ are enabled simultaneously for each share, we must strongly discourage:

• simultaneous access via both protocols
• access via NFSv3 when NFS v4.1 clients are available (i.e., all Linux clients must continue to use NFS v4.1+)
• NFS v3 has an order of magnitude performance degradation over NFS v4.1+
• NFS v3 clients cannot recover state when NFS-Ganesha server fails over. Recovery isn’t implemented or expected for Microsoft Windows clients, so this must be documented and understood

 

Is a CLI change required, does the openstack cmd support it?

No, driver changes only.

 

Does this RFE impact / need to be included into the control plane podification?

No impact on the operator

Does this RFE benefit/impact DCN?

This RFE is maintly expected to benefit Microsoft Windows clients, whether they’re running in a centralized OpenStack environment or at the Edge

Does this RFE benefit/impact shift on stack?

No

 

Can this feature be turned on or used in an existing environment?

Yes. There’s no upgrade code involved and no steps to enable this. As long as the environment has RHCS 7.1, this feature can be expected to work

 

Does this feature affect another DFG or product?

No

 

Does this feature depend on another RFE?

1) https://bugzilla.redhat.com/show_bug.cgi?id=2259938
2) https://bugzilla.redhat.com/show_bug.cgi?id=2259461

 

How will the feature affect Upgrades?

No impact

 

How will the feature affect performance or scaling?

CephFS NFS v3 doesn’t perform as well as CephFS NFS v4.1. Users must use this solution only because of incompatibility issues in the clients.

 

What are the test cases for this RFE?

• Create access rules and verify mount via NFS v3. We don’t need a Windows Host to verify NFS v3. 

Are there CI implications?

This feature must be tested in the CI; however, beyond enabling the tests above, no further CI implication is anticipated

 

Does it have documentation impact and require early planning with the doc team?

Yes, call out specifically the shortfalls listed as known limitations

 

Are there known packaging challenges?

No

 

Are there any security considerations?

NFS v3 has some protocol limitations and is considered “less secure” than NFS v4.1 because of the lack of idmapping, name server integration.

 

How much upstream resistance might there be to this feature?

None, supporting NFSv3 includes supporting clients using windows, even with lack of recovery support

 

Will this feature require new or different support skills?

No

 

Will this be required for knowledge transfer to GSS?

Yes. The limitations of using NFS v3 must be well understood; and GSS must be aware that we should actively discourage the use of CephFS NFS v3 mounts on Linux hosts

 

Will this feature impact existing partners or certification programs?

No

 

API Deprecation/Compatibility?

None

 

Are any GUI impact/changes required (Horizon)?

No