Project

General

Profile

Actions

Bug #62641

open

mgr/(object_format && nfs/export): enhance nfs export update failure response

Added by Dhairya Parmar 8 months ago. Updated 5 months ago.

Status:
Pending Backport
Priority:
Normal
Category:
python interface
Target version:
% Done:

0%

Source:
Development
Tags:
backport_processed
Backport:
quincy,reef
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Currently when an export update fails, the response is like this:

[
  {
    "msg": "Failed to apply export: export FSAL user_id must be 'nfs.my-nfs.1'",
    "state": "error" 
  },
  {
    "pseudo": "/ceph1",
    "state": "added" 
  },
  {
    "msg": "Failed to apply export: export FSAL user_id must be 'nfs.my-nfs.2'",
    "state": "error" 
  }
]
Error EIO:

this needs to be corrected to proper errno, I'd say EINVAL is a better fit since it indicates the export block contains invalid entries and needs correction. Apart from errno, the last line looks incomplete; there needs to be a err msg after 'Error EIO:', this aided by a prefix indicating how many export block contain invalid entries would also be useful, and the index of those problematic export block(s) can also be shown. So the final output could be like

[
  {
    "msg": "Failed to apply export: export FSAL user_id must be 'nfs.my-nfs.1'",
    "state": "error" 
  },
  {
    "pseudo": "/ceph1",
    "state": "added" 
  }
  {
    "msg": "Failed to apply export: export FSAL user_id must be 'nfs.my-nfs.2'",
    "state": "error" 
  }
]
Error EINVAL: 2 export blocks(at index 0, 1) contain invalid entries.

I had a conversation with John about this on one of my PR and it seems we might need to make some modifications/additions to the object_format.py code. Would be happy to assist for any help needed.


Related issues 3 (1 open2 closed)

Related to mgr - Bug #62659: mgr/nfs: report actual errno instead of EIO for single export update failureClosedDhairya Parmar

Actions
Copied to mgr - Backport #63690: quincy: mgr/(object_format && nfs/export): enhance nfs export update failure responseRejectedDhairya ParmarActions
Copied to mgr - Backport #63691: reef: mgr/(object_format && nfs/export): enhance nfs export update failure responseIn ProgressDhairya ParmarActions
Actions #1

Updated by John Mulligan 8 months ago

Changing the errno should be simple and straightforward. When I added support for object_format to mgr/nfs I chose EIO because it strikes me as more general than EINVAL. From the `errno` manpage (on fedora 38):

       EINVAL          Invalid argument (POSIX.1-2001).
       EIO             Input/output error (POSIX.1-2001).

So I don't know if I'm fully on board with the idea that EINVAL is better because all errors are not necessarily triggered by bad input (invalid arguments).
Some errors could be triggered by back-end issues (for example). That said, I don't object to the use of EINVAL if there's a loose consensus that it's better.

As for adding the status text, that's a little more work and the cleanest way to add this is (probably) to enhance object_format. We need the non-error path to be able to provide a protocol that has a method for supplying a specific status string. Not difficult but extra work, and in a little bit of a unique area. Let me know if you'd prefer I provide patches for this OR if you would like some coaching on how to add it yourself.

Actions #2

Updated by Dhairya Parmar 8 months ago

John Mulligan wrote:

Changing the errno should be simple and straightforward. When I added support for object_format to mgr/nfs I chose EIO because it strikes me as more general than EINVAL. From the `errno` manpage (on fedora 38):

[...]

So I don't know if I'm fully on board with the idea that EINVAL is better because all errors are not necessarily triggered by bad input (invalid arguments).
Some errors could be triggered by back-end issues (for example). That said, I don't object to the use of EINVAL if there's a loose consensus that it's better.

As for adding the status text, that's a little more work and the cleanest way to add this is (probably) to enhance object_format. We need the non-error path to be able to provide a protocol that has a method for supplying a specific status string. Not difficult but extra work, and in a little bit of a unique area. Let me know if you'd prefer I provide patches for this OR if you would like some coaching on how to add it yourself.

Sure, what approach do you have in your mind? Let's team up and get this thing done :)

Actions #3

Updated by Dhairya Parmar 8 months ago

  • Related to Bug #62659: mgr/nfs: report actual errno instead of EIO for single export update failure added
Actions #4

Updated by Dhairya Parmar 8 months ago

  • Status changed from New to In Progress
  • Assignee set to Dhairya Parmar
Actions #5

Updated by Dhairya Parmar 8 months ago

  • Pull request ID set to 53431

FYI PR https://github.com/ceph/ceph/pull/53431 solves both https://tracker.ceph.com/issues/62659 and this tracker. Since https://tracker.ceph.com/issues/62659 is a subset of this isuse, the PR is attached to this tracker.

Actions #6

Updated by Dhairya Parmar 7 months ago

  • Status changed from In Progress to Fix Under Review
Actions #7

Updated by Venky Shankar 5 months ago

  • Status changed from Fix Under Review to Pending Backport
  • Backport set to quincy,reef

Holding back the backport till we decide on https://github.com/ceph/ceph/pull/53431#issuecomment-1823873370

Dhairya, please create a tracker for the same.

Actions #8

Updated by Backport Bot 5 months ago

  • Copied to Backport #63690: quincy: mgr/(object_format && nfs/export): enhance nfs export update failure response added
Actions #9

Updated by Backport Bot 5 months ago

  • Copied to Backport #63691: reef: mgr/(object_format && nfs/export): enhance nfs export update failure response added
Actions #10

Updated by Backport Bot 5 months ago

  • Tags set to backport_processed
Actions #11

Updated by Dhairya Parmar 5 months ago

backports withheld until https://tracker.ceph.com/issues/63692 is addressed. Updated the respective backport trackers with the details.

Actions

Also available in: Atom PDF