Project

General

Profile

Bug #39252

mgr/dashboard: RGW port autodetection does not support "Beast" RGW frontend

Added by Nathan Cutler 12 months ago. Updated about 1 month ago.

Status:
Pending Backport
Priority:
Normal
Assignee:
Category:
dashboard/rgw
Target version:
% Done:

0%

Source:
Tags:
Backport:
nautilus
Regression:
Yes
Severity:
2 - major
Reviewed:
ceph-qa-suite:
Pull request ID:
Crash signature:

Description

The documentation at http://docs.ceph.com/docs/master/mgr/dashboard/#enabling-the-object-gateway-management-frontend currently makes an unequivocal statement:

"This is all you have to do to get the Object Gateway management functionality working. The host and port of the Object Gateway are determined automatically."

However, with the advent of Beast this is no longer the case.

In the "RGW always uses civetweb" paradigm, the RGW port could be determined automatically using a regex that matches port={}, like so:

match = re.search(r'port=(.*:)?(\d+)(s)?', config)

But nowadays, assuming the dashboard should also support Beast, that regex is broken because Beast has different semantics for specifying the RGW endpoint. For example, the relevant line in ceph.conf might look like this:

rgw frontends = "beast endpoint=[::]:80" 

I'm not sure what the "correct" regex should be. Should it support both Civetweb and Beast, or just one or the other?
Should it support both IPv4 and IPv6?

(My thanks to Ricardo Marques for helping gather the above information.)


Related issues

Copied to mgr - Backport #44203: nautilus: mgr/dashboard: RGW port autodetection does not support "Beast" RGW frontend New

History

#1 Updated by Nathan Cutler 12 months ago

  • Category set to dashboard/rgw

#2 Updated by Nathan Cutler 12 months ago

  • Description updated (diff)

#3 Updated by Lenz Grimmer 12 months ago

  • Subject changed from dashboard: RGW port autodetection does not support beast to mgr/dashboard: RGW port autodetection does not support beast
  • Description updated (diff)
  • Target version set to v15.0.0
  • Backport set to nautilus

#4 Updated by Nathan Cutler 12 months ago

  • Subject changed from mgr/dashboard: RGW port autodetection does not support beast to mgr/dashboard: RGW port autodetection does not support "Beast" RGW frontend

#5 Updated by Nathan Cutler 12 months ago

I was told that the Beast frontend supports "port=" as well as "endpoint=", so maybe the fix is simpler than I thought?

#6 Updated by Nathan Cutler 12 months ago

One further point. Though I am by far not an expert on RGW/Beast, my understanding is that the "endpoint" configuration line that is being parsed by this regex could potentially be quite complicated - even with multiple endpoints.

In that light, would it make sense to mention these possible complications in the documentation? I.e. instead of the unequivocal statement

"This is all you have to do to get the Object Gateway management functionality working. The host and port of the Object Gateway are determined automatically."

it could be more careful and say something like:

"In a typical default configuration with a single RGW endpoint, this is all you have to do to get the Object Gateway management functionality working. The dashboard will try to automatically determine the host and port of the Object Gateway by parsing the relevant line in ceph.conf."

#7 Updated by Marcus Watts 12 months ago

The civetweb interface has supported multiple ports and optional host or ssl for a while now.

So, for instance,
rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/private/keyandcert.pem

Last I checked, ceph-ansible wasn't very good about this, but it also wasn't very good about ssl either.

#8 Updated by Lenz Grimmer 12 months ago

Nathan Cutler wrote:

One further point. Though I am by far not an expert on RGW/Beast, my understanding is that the "endpoint" configuration line that is being parsed by this regex could potentially be quite complicated - even with multiple endpoints.

In that light, would it make sense to mention these possible complications in the documentation? I.e. instead of the unequivocal statement

"This is all you have to do to get the Object Gateway management functionality working. The host and port of the Object Gateway are determined automatically."

it could be more careful and say something like:

"In a typical default configuration with a single RGW endpoint, this is all you have to do to get the Object Gateway management functionality working. The dashboard will try to automatically determine the host and port of the Object Gateway by parsing the relevant line in ceph.conf."

Sounds good to me, except for the last part - the dashboard actually obtains this information from the service map, not ceph.conf. I'll update the documentation accordingly, until we have found a more generic solution for this.

#9 Updated by Lenz Grimmer 12 months ago

Lenz Grimmer wrote:

Nathan Cutler wrote:

One further point. Though I am by far not an expert on RGW/Beast, my understanding is that the "endpoint" configuration line that is being parsed by this regex could potentially be quite complicated - even with multiple endpoints.

In that light, would it make sense to mention these possible complications in the documentation? I.e. instead of the unequivocal statement

"This is all you have to do to get the Object Gateway management functionality working. The host and port of the Object Gateway are determined automatically."

it could be more careful and say something like:

"In a typical default configuration with a single RGW endpoint, this is all you have to do to get the Object Gateway management functionality working. The dashboard will try to automatically determine the host and port of the Object Gateway by parsing the relevant line in ceph.conf."

Sounds good to me, except for the last part - the dashboard actually obtains this information from the service map, not ceph.conf. I'll update the documentation accordingly, until we have found a more generic solution for this.

Docs pull request: https://github.com/ceph/ceph/pull/27581 - please review.

#10 Updated by Lenz Grimmer 12 months ago

In general, when enhancing the autodetection, we should ensure that it also supports IPv6 addresses

#11 Updated by Lenz Grimmer 10 months ago

  • Target version deleted (v15.0.0)
  • Affected Versions v14.2.0, v14.2.1, v15.0.0 added

The documentation has been updated. Leaving this one open, as the dashboard implementation itself should be enhanced.

#12 Updated by Lenz Grimmer 2 months ago

  • Tags changed from usability to usability, feature-gap
  • Regression changed from No to Yes

#13 Updated by Lenz Grimmer 2 months ago

  • Tags changed from usability, feature-gap to usability, feature-gap, low-hanging-fruit
  • Severity changed from 3 - minor to 2 - major

#14 Updated by Lenz Grimmer 2 months ago

  • Tags changed from usability, feature-gap, low-hanging-fruit to usability, feature-gap

#15 Updated by Lenz Grimmer 2 months ago

  • Assignee set to Volker Theile

#16 Updated by Abhishek Lekshmanan 2 months ago

so with beast port=<> would bind to both ipv4 and v6, endpoint binds to the ip:port combination which can be v4 or v6

with civetweb port=<> would bind to a v4 port if it is just a number. It can also be a ip:port combo in which case both v4 and v6 endpoints are supported

See https://docs.ceph.com/docs/master/radosgw/frontends/#id1 for some additional info

#17 Updated by Volker Theile about 2 months ago

  • Status changed from New to Fix Under Review
  • Pull request ID set to 33060

#18 Updated by Lenz Grimmer about 1 month ago

  • Status changed from Fix Under Review to Pending Backport
  • Target version set to v15.0.0

#19 Updated by Konstantin Shalygin about 1 month ago

  • Copied to Backport #44203: nautilus: mgr/dashboard: RGW port autodetection does not support "Beast" RGW frontend added

Also available in: Atom PDF