* refs/pull/36554/head:
mgr/volumes: Make number of cloner threads configurable
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Reviewed-by: Shyamsundar R <srangana@redhat.com>
Implement a root_squash mode in MDS auth caps to deny operations for
clients with uid=0 or gid=0 that need write access. It's mainly to
prevent operations such as accidental `sudo rm -rf /path`.
The root squash mode can be enforced in one of the following ways in
the MDS caps,
'allow rw root_squash'
(across file systems)
or
'allow rw fsname=a root_squash'
(on a file system)
or
'allow rw fsname=a path=/vol/group/subvol00 root_squash'
(on a file system path)
Fixes: https://tracker.ceph.com/issues/42451
Signed-off-by: Ramana Raja <rraja@redhat.com>
The number of cloner threads is set to 4 and it can't be
configured. This patch makes the number of cloner threads
configurable via the mgr config option "max_concurrent_clones".
On an increase in number of cloner threads, it will just
spawn the difference of threads between existing number of
cloner threads and the new configuration. It will not cancel
the running cloner threads.
On decrease in number of cloner threads, the cases are as follows.
1. If all cloner threads are waiting for the job:
In this case, all threads are notified and required number
threads are terminated.
2. If all the cloner threads are processing a job:
In this case, the condition is validated for each thread after
the current job is finished and the thread is termianted if the
condition for required number of cloner threads is not satisified.
3. If few cloner threads are processing and others are waiting:
The threads which are waiting are notified to validate the
number of threads required. If terminating those doesn't satisfy the
required number of threads, the remaining threads are terminated
upon completion of existing job.
Fixes: https://tracker.ceph.com/issues/46892
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Add new auth caps to restrict access to clients based on fsnames. To
specify this, for example:
mds 'allow rw fsname=cephfs1'
This will restrict client access to fs name "cephfs1" only. Messages to
active MDS assigned to any other FSMap will be dropped. Standby MDS not
associated with an FSMap will accept messages from clients. To allow
multiple file systems, create MDS cap as follows -
mds 'allow rw fsname=cephfs1, allow rw fsname=cephfs2'
Fixes: http://tracker.ceph.com/issues/15070
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Add a 'fsname' clause to mon auth caps to restrict a client's view
of the FSMap. Example:
mon 'allow rw fsname=cephfs2'
This would restrict the client's view of the FSMap to the MDSMap for
cephfs2. Any MDS allocated to a different filesystem will be invisible.
Global standby daemons are always visible. To allow multiple CephFSs,
add multiple caps:
mon 'allow rw fsname=cephfs2, allow rw fsname=cephfs2'
Fixes: http://tracker.ceph.com/issues/15070
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Since RADOS is an acronym, albeit a somewhat difficult-to-remember one,
it is customary to write it ALL-CAPS.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The document seemed to be wanting to refer to the software as "NFS
Ganesha", but was failing to do so in some places.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The "ceph fs volume create" command takes a placement string,
just like "ceph nfs cluster create" does. Align the documentation
so the placement string is explained in the same manner in both
places.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
When a reader sees "ceph nfs create <type=cephfs>" it's not
clear that this means they should type "ceph nfs create cephfs".
I also took this opportunity to clarify the command description
based on my testing and discussions with the CephFS developers.
Fixes: https://tracker.ceph.com/issues/46559
Signed-off-by: Nathan Cutler <ncutler@suse.com>
* refs/pull/36773/head:
mgr/volumes: Prevent subvolume recreate if trash is not-empty
mgr/volumes: Disallow subvolume group level snapshots
mgr/volumes: Add test case to ensure subvolume is marked
mgr/volumes: handle idempotent subvolume marks
mgr/volumes: Tests amended and added to ensure subvolume trash functionality
mgr/volumes: Mark subvolume root with the vxattr ceph.dir.subvolume
mgr/volumes: Move incarnations for v2 subvolumes, to subvolume trash
mgr/volumes: maintain per subvolume trash directory
mgr/volumes: make subvolume_v2::_is_retained() object property
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
* refs/pull/35755/head:
mgr/volumes: Deprecate protect/unprotect CLI calls for subvolume snapshots
Reviewed-by: Ramana Raja <rraja@redhat.com>
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Kotresh Hiremath Ravishankar <khiremat@redhat.com>
Reviewed-by: Victoria Martinez de la Cruz <vkmc@redhat.com>
Reviewed-by: Goutham Pacha Ravi <gouthamr@redhat.com>
Subvolume snapshots required to be protected, prior to cloning the same.
Also, protected snapshots were not allowed to be unprotected or removed,
if there were in-flight clones, whose source was the snapshot being
removed.
The protection of snapshots explicitly is not required, as these can be
prevented from being removed based only on the in-flight clones checks.
This commit hence deprecates the additional protect/unprotect requirements
prior to cloning a snapshot.
In addition to deprecating the above, support to query a subvolume for
supported features, via the info command, is added. The feature list
is set to "clone" and "auto-protect", where the latter is useful to
decide if protect/unprotect commands are required or not.
Fixes: https://tracker.ceph.com/issues/45371
Signed-off-by: Shyamsundar Ranganathan <srangana@redhat.com>
* refs/pull/32288/head:
test_cephfs_shell: remove test_every_shell_cmd_at_invocation
test_cephfs_shell: catch specific exception instead of catching all
cephfs-shell: set return value before exiting
test_cephfs_shell: re-arrange TestCephFSShell's methods
cephfs-shell: re-arrange code under __main__
test_cephfs_shell: add new test for shell cmd at invocation
cephfs-shell: launch shell only if there are no args following
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Varsha Rao <varao@redhat.com>
* refs/pull/34716/head:
mgr/volumes: Add snapshot info command
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Jos Collin <jcollin@redhat.com>
Code for each command has a return value set yet cephfs-shell itself
doesn't exit with proper return value. This makes cephfs-shell quit with
zero return value all the time.
Also, many tests execute cephfs-shell commands expecting the command to
fail but without expecting the method issuing the command to fail. Fix
these test accordingly by adding a new method (negtest_cephfs_shell_cmd)
that expects the command to fail and allows verifying return value and
error messages.
Fixes: https://tracker.ceph.com/issues/44113
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Commands like "cephfs-shell mkdir a" should just create the directory
and quit immediately with the command's return value instead of
launching a shell session. A shell session should be launched only if
there are no arguments following "cephfs-shell".
Fixes: https://tracker.ceph.com/issues/43248
Signed-off-by: Rishabh Dave <ridave@redhat.com>
