Project

General

Profile

Feature #23376

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

Added by supriti singh 9 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
nfs-ganesha
Target version:
Start date:
03/15/2018
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
luminous
Reviewed:
Affected Versions:
Component(FS):
Client, Ganesha FSAL
Labels (FS):
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.

History

#1 Updated by Patrick Donnelly 8 months ago

  • Project changed from Ceph to fs
  • 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 nfs-ganesha
  • 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

#2 Updated by Jeff Layton 8 months 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.

#3 Updated by Matt Benjamin 8 months 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

#4 Updated by Patrick Donnelly 8 months ago

  • Target version changed from 552 to v14.0.0

#5 Updated by Jeff Layton about 2 months 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?

#6 Updated by Patrick Donnelly about 2 months 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.

Also available in: Atom PDF