Project

General

Profile

Actions

Bug #46582

closed

cephadm: NFS services should not share the same namespace in a pool

Added by Kiefer Chang almost 4 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
cephadm/nfs
Target version:
-
% Done:

0%

Source:
Tags:
low-hanging-fruit
Backport:
octopus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

NFS services should have their dedicated pool and namespace to store export and conf objects.

cephadm allow me to apply these two specs:

service_type: nfs
service_id: foo
placement:
    hosts:
    - mgr0
spec:
    pool: rbd
    namespace: nfs

service_type: nfs
service_id: bar
placement:
    hosts:
    - osd0
spec:
    pool: rbd
    namespace: nfs

The namespace should be checked if it's already occupied by other services.

Actions #1

Updated by Sebastian Wagner almost 4 years ago

  • Priority changed from Normal to High
  • Tags set to low-hanging-fruit
Actions #2

Updated by Sebastian Wagner over 3 years ago

  • Category changed from cephadm to cephadm/nfs
Actions #3

Updated by Melissa Li about 3 years ago

I was thinking about this issue and wondering a few things. If we make a class variable e.g. `namespace_set` in the NFSServiceSpec class (assuming this can be fixed on that level), and then use that variable to maintain a set of every namespace the user applied in the service spec (and not let them use those again), would that be a potential solution? Reason I say class variable is because if the user applies two specs one after another, I think that is two instances of the class, so we need the set to persist.

Although, now as I'm typing this, I realize what would happen if someone edited their service spec to have a different namespace, but then the namespace still exists in the set and won't let them use it? Then I'm not really sure how to account for that. What are your thoughts?

Actions #4

Updated by Sage Weil over 2 years ago

  • Status changed from New to Resolved

This is solved indirectly since the namespace always == service_id now.

Actions

Also available in: Atom PDF