Project

General

Profile

Actions

Bug #59463

closed

mgr/nfs: Setting NFS export config using -i option is not working

Added by Dhairya Parmar about 1 year ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Category:
Correctness/Safety
Target version:
% Done:

0%

Source:
Q/A
Tags:
Backport:
reef,quincy,pacific
Regression:
No
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
mgr/nfs
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Unable to set NFS export configuration using config.conf

Steps followed

1. created nfs cluster
$ ceph nfs cluster create nfs-cephfs "hostname" 
NFS Cluster Created Successfully

2. created config file with below contents
$ cat config.conf 
EXPORT {
  Export_Id = 110;
  Transports = TCP;
  Path = /;
  Pseudo = /ceph/;
  pseudo_path = /ceph/;
  Protocols = 4;
  Access_Type = RO;
  Attr_Expiration_Time = 0;
  Squash = None;
  FSAL {
    Name = CEPH;
    Filesystem = "cephfs";
    User_Id = "nfstest01";
    Secret_Access_Key = "SomeKeyValue";
  }
}

3. Created user nfstest01
$ ceph auth get-or-create client.nfstest01 mon 'allow r' osd 'allow rw pool=nfs-ganesha namespace=nfs-cephfs, allow rw tag cephfs data=cephfs' mds 'allow rw path=/'
[client.nfstest01]
    key = SomeKeyValue

4. created nfs export
$ ceph nfs export create cephfs nfs-cephfs /ceph cephfs --path=/ 
{
    "bind": "/ceph",
    "fs": "cephfs",
    "path": "/",
    "cluster": "nfs-cephfs",
    "mode": "RW" 
}

5. Tried changing the setting by reapplying
$ ceph nfs cluster config set nfs-cephfs -i config.conf 
NFS-Ganesha User Config already exists

$ ceph nfs export ls nfs-cephfs --detailed
[
  {
    "export_id": 1,
    "path": "/",
    "cluster_id": "nfs-cephfs",
    "pseudo": "/ceph",
    "access_type": "RW",
    "squash": "none",
    "security_label": true,
    "protocols": [
      4
    ],
    "transports": [
      "TCP" 
    ],
    "fsal": {
      "name": "CEPH",
      "user_id": "nfs.nfs-cephfs.1",
      "fs_name": "cephfs" 
    },
    "clients": []
  }
]

$ cat config.conf 
EXPORT {
  Export_Id = 110;
  Transports = TCP;
  Path = /;
  Pseudo = /ceph/;
  pseudo_path = /ceph/;
  Protocols = 4;
  Access_Type = RO;
  Attr_Expiration_Time = 0;
  Squash = None;
  FSAL {
    Name = CEPH;
    Filesystem = "cephfs";
    User_Id = "nfstest01";
    Secret_Access_Key = "SomeKeyValue";
  }
}

It is not applying the configs present as part of config.conf


Related issues 2 (0 open2 closed)

Related to CephFS - Bug #61183: mgr/nfs: Applying for first time, NFS-Ganesha Config Added Successfully but doesn't actually reflect the changesClosedDhairya Parmar

Actions
Related to CephFS - Bug #61184: mgr/nfs: setting config using external file gets overiddenClosedDhairya Parmar

Actions
Actions #1

Updated by Dhairya Parmar about 1 year ago

  • Severity deleted (3 - minor)
Actions #2

Updated by Venky Shankar about 1 year ago

  • Status changed from New to Triaged
  • Assignee set to Dhairya Parmar
  • Target version set to v19.0.0
  • Backport set to reef,quincy,pacific
Actions #3

Updated by Dhairya Parmar about 1 year ago

I was going through the config file content and found `pseudo_path` to be a bit doubtful, it should be `pseudo-path` if i remember. I also checked RedHat's doc as well Ceph doc, none of the config file mentioned have `pseudo_path` in them, we have a testcase too namely `test_cluster_set_reset_user_config` which uses config file to create cephfs export over nfs and that too doesn't have `pseudo_path` in it. Do we know how severe this can be for the issue?

Actions #4

Updated by Patrick Donnelly about 1 year ago

I believe the problem is you're trying to set a config for an export that the module is managing itself. i.e. you're getting an EEXIST error somewhere in the stack. You're should not create the export using the module if you want to create the export using a custom config.

Actions #5

Updated by Venky Shankar almost 1 year ago

Dhairya Parmar wrote:

I was going through the config file content and found `pseudo_path` to be a bit doubtful, it should be `pseudo-path` if i remember. I also checked RedHat's doc as well Ceph doc, none of the config file mentioned have `pseudo_path` in them, we have a testcase too namely `test_cluster_set_reset_user_config` which uses config file to create cephfs export over nfs and that too doesn't have `pseudo_path` in it. Do we know how severe this can be for the issue?

I'm not sure about this since I don't know much history about mgr/nfs, but I think you might be correct. Have you tried using `pseudo-path` in the export block?

Actions #6

Updated by Dhairya Parmar 11 months ago

  • Related to Bug #61183: mgr/nfs: Applying for first time, NFS-Ganesha Config Added Successfully but doesn't actually reflect the changes added
Actions #7

Updated by Dhairya Parmar 11 months ago

Dhairya Parmar wrote:

I was going through the config file content and found `pseudo_path` to be a bit doubtful, it should be `pseudo-path` if i remember. I also checked RedHat's doc as well Ceph doc, none of the config file mentioned have `pseudo_path` in them, we have a testcase too namely `test_cluster_set_reset_user_config` which uses config file to create cephfs export over nfs and that too doesn't have `pseudo_path` in it. Do we know how severe this can be for the issue?

I tested this out, and for now `pseudo_path` or `pseudo-path` or no pseudo path has no effect on this bug.

Actions #8

Updated by Dhairya Parmar 11 months ago

  • Related to Bug #61184: mgr/nfs: setting config using external file gets overidden added
Actions #9

Updated by Dhairya Parmar 11 months ago

  • Status changed from Triaged to Closed

`ceph nfs cluster config set <cluster_id> -i <config_file>` isn't actually meant for creating exports, rather it is used for storing user defined config along with the common config in the RADOS object(which is created when the nfs cluster is created), therefore a custom export block can be included as a part of the user defined config which in turn creates an export, but FYI this is the cluster RADOS object, it cannot be manipulated by `ceph nfs export` interface.

Nothing looks broken from the code side but what lead to confusion at the first glance was the red hat doc [0] that mingles `ceph nfs cluster` and `ceph nfs export` interfaces for explaining export creation. Ceph docs [1] provides proper segregation and explanation of both the interfaces.

[0] https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/5/html/file_system_guide/ceph-file-system-administration#exporting-ceph-file-system-namespaces-over-the-nfs-protocol_fs

[1] https://docs.ceph.com/en/latest/mgr/nfs/

Actions #10

Updated by Venky Shankar 10 months ago

Hi Dhairya,

Dhairya Parmar wrote:

`ceph nfs cluster config set <cluster_id> -i <config_file>` isn't actually meant for creating exports, rather it is used for storing user defined config along with the common config in the RADOS object(which is created when the nfs cluster is created), therefore a custom export block can be included as a part of the user defined config which in turn creates an export, but FYI this is the cluster RADOS object, it cannot be manipulated by `ceph nfs export` interface.

Are you saying that `ceph nfs cluster config set` does the right thing by not updating the config block or the interface itself is not required?

Nothing looks broken from the code side but what lead to confusion at the first glance was the red hat doc [0] that mingles `ceph nfs cluster` and `ceph nfs export` interfaces for explaining export creation. Ceph docs [1] provides proper segregation and explanation of both the interfaces.

The config block provided by the user did not get applied.

Is there a discussion somewhere about this which I am missing? (its possible since I was out for ~3 weeks).

Actions

Also available in: Atom PDF