Feature #23376
closednfsgw: add NFS-Ganesha to service map similar to "rgw-nfs"
Added by supriti singh about 6 years ago. Updated about 4 years ago.
0%
Description
Not sure, if there is already a tracker issue for this feature. Feel Free to close if that is the case.
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
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.
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
Updated by Patrick Donnelly about 6 years ago
- Target version changed from 552 to v14.0.0
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?
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.
Updated by Patrick Donnelly about 5 years ago
- Target version changed from v14.0.0 to v15.0.0
Updated by Jeff Layton about 4 years ago
- Status changed from New to Rejected
There still doesn't seem to be any need for this, and if there were we'd want to open a new bug that articulated the rationale better.