Feature #23376: nfsgw: add NFS-Ganesha to service map similar to "rgw-nfs" - CephFS - Ceph

Actions

Copy link

Feature #23376

closed

nfsgw: add NFS-Ganesha to service map similar to "rgw-nfs"

Added by supriti singh about 6 years ago. Updated about 4 years ago.

Status:

Rejected

Priority:

Low

Assignee:

Jeff Layton

Category:

Target version:

% Done:

Source:

Community (user)

Tags:

Backport:

luminous

Reviewed:

Affected Versions:

Component(FS):

Client, Ganesha FSAL

Labels (FS):

NFS-cluster

Pull request ID:

Description

Not sure, if there is already a tracker issue for this feature. Feel Free to close if that is the case.

Actions

Copy link

Updated by Patrick Donnelly about 6 years ago

Project changed from Ceph to CephFS
Subject changed from Add "cephfs-nfs" service registration similar to "rgw-nfs" to nfsgw: add NFS-Ganesha to service map similar to "rgw-nfs"
Category set to 109
Assignee set to Jeff Layton
Target version set to 552
Source set to Community (user)
Backport set to luminous
Component(FS) Client, Ganesha FSAL added

Actions

Copy link

Updated by Jeff Layton about 6 years ago

I'm not aware of any bugs open on this. Is there any background on the rgw-nfs map at all? I've not looked at the service map infrastructure, so I'm not at all familiar with it.

Actions

Copy link

Updated by Matt Benjamin about 6 years ago

The service map is a librados resource consumed by ceph-mgr. It periodically gets perfcounters, for example. When librgw starts, it registers an "rgw-nfs" entry in the service map. I assume Patrick is doing that when nfs-ganesha mounts libcephfs?

Matt

Actions

Copy link

Updated by Patrick Donnelly about 6 years ago

Target version changed from 552 to v14.0.0

Actions

Copy link

Updated by Jeff Layton over 5 years ago

Looking again at this, as I'm starting to look at how we'd populate fs_locations_info to handle clustered ganesha migration. I think we can probably have ganesha register itself with the service map so we can maintain a list of ganesha servers that are associated with this cluster, and have a k/v pair that indicates the public address(es) for that server.

From there, we should be able to allow ganesha to query the service map to get a list of servers and addresses. librados does not seem to have a way for daemons to query the service map as of yet, as I guess it's only intended to be consumed by the mgr. We'll also need a way for ganesha to reliably determine its public address, which may be non-trivial if we're running in some sort of containerized environment.

Patrick, you originally opened this bug -- what other info did you want to see stored in this map?

Actions

Copy link

Updated by Patrick Donnelly over 5 years ago

Jeff Layton wrote:

Looking again at this, as I'm starting to look at how we'd populate fs_locations_info to handle clustered ganesha migration. I think we can probably have ganesha register itself with the service map so we can maintain a list of ganesha servers that are associated with this cluster, and have a k/v pair that indicates the public address(es) for that server.

From there, we should be able to allow ganesha to query the service map to get a list of servers and addresses. librados does not seem to have a way for daemons to query the service map as of yet, as I guess it's only intended to be consumed by the mgr. We'll also need a way for ganesha to reliably determine its public address, which may be non-trivial if we're running in some sort of containerized environment.

Patrick, you originally opened this bug -- what other info did you want to see stored in this map?

What I envisioned was the service map to act as a mechanism for discovering Ganesha clusters but I'm not even sure anymore if that is an intended use of the ServiceMap.

I would table this for now until we're sure we need this.

Actions

Copy link