New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mgr/cephadm: automatically configure dashboard <-> RGW connection #41590
Conversation
1d82ddb
to
8ee1ee2
Compare
8ee1ee2
to
b0bb373
Compare
b235e8a
to
a69ea64
Compare
f83023b
to
9f7e87f
Compare
9f7e87f
to
1e8a4c8
Compare
if self.mgr.need_connect_dashboard_rgw and self.mgr.config_dashboard: | ||
self.mgr.need_connect_dashboard_rgw = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not persistent, which means there is a race between MGR failover and making this connection. Feeling slightly uneasy, but I guess we can fix this later, if it turns out to be a problem
def update_dashboard(what: str, value: str) -> None: | ||
_, out, _ = self.mgr.check_mon_command({'prefix': f'dashboard get-{what}'}) | ||
if out.strip() != value: | ||
if what.endswith('-key'): | ||
self.mgr.check_mon_command( | ||
{'prefix': f'dashboard set-{what}'}, | ||
inbuf=value | ||
) | ||
else: | ||
self.mgr.check_mon_command({'prefix': f'dashboard set-{what}', | ||
"value": value}) | ||
self.mgr.log.info(f'Updated dashboard {what}') | ||
|
||
completion = self.mgr.list_daemons(daemon_type='rgw') | ||
raise_if_exception(completion) | ||
daemons = completion.result | ||
if not daemons: | ||
self.mgr.log.info('No remaining RGW daemons; disconnecting dashboard') | ||
self.mgr.check_mon_command({'prefix': 'dashboard reset-rgw-api-host'}) | ||
self.mgr.check_mon_command({'prefix': 'dashboard reset-rgw-api-port'}) | ||
self.mgr.check_mon_command({'prefix': 'dashboard reset-rgw-api-scheme'}) | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alfonsomthd you'd be interested in reviewing this (I meant the whole file, not just this section, but my ability to drag & scroll is affected 🙈 ).
@liewegas, as @Daniel-Pivonka pointed out, there are 2 ways of feeding these params:
- single RGW daemon deployment: where access key and secret key contain each a single plain value (key)
- multi-daemon (zone, zg, realm) deployment: where a dict-like syntax needs to be used for each: api-access-key=$ echo -n "{'<daemon1.id>': '', '<daemon2.id>': '', ...}"
We'd really like to see this simplified, but we couldn't find a better way to locate and configure connection to multiple daemons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the multisite case, do you need a separate keypair for each zone, and the daemon is any daemon for that zone? or one per realm? (I thought the user creds were all per-realm...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liewegas Currently we need a dict-like syntax per daemon. Form the mgr service map we can see the zone/zonegroup of the daemon but not the realm (and without first creds we cannot consume the admin ops API), so for now the credentials are per-daemon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still confused about the limitation, though: what can/can't you see depending on which daemon you connect to? Is the issue that you only see the zonegroup? Or everything in the realm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liewegas @alfonsomthd if any, credentials would be per zone and not per gateway. In the stable state all users will be synced from the main/primary zone. During its bootstrap, a zone would not have any users defined (it will only hold credentials to connect to the primary as a client).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yehudasa Does this mean that the Dashboard dropdown menu for selecting gateways should instead allow a user to select zones (not gateways, not realms) and then connect to the first daemon that matches the <zone_id> ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alfonsomthd I'm not sure what would make the most sense, maybe gateway selection can be a secondary and optional/advanced selection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it seems like in most cases the important part is to select the realm? It should be rare that a specific zone needs to be selected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liewegas A daemon cannot operate on a zone other than its zone, so we need to select a zone.
Regarding credentials, after orch. weekly meeting the agreement is to set credentials on a per-realm basis. In order to do that on Dashboard side (to identify the daemons that run on zones belonging to a certain realm), this is required:
#41739
1e8a4c8
to
3cf1c66
Compare
3cf1c66
to
3d77100
Compare
Automatically configure the dashboard creds to talk to RGW. Fixes: https://tracker.ceph.com/issues/44605 Signed-off-by: Sage Weil <sage@newdream.net>
3d77100
to
310c1b8
Compare
jenkins test make check |
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
replaced by #42252 |
Automatically configure the credential(s) for dashboard to talk to RGW.
We do not provide any endpoint information--we assume that dashboard can figure that out on its own.
Note that this path is triggered any time we add or remove an rgw daemon, which isn't quite right--what we really want is to trigger this change when teh first or last rgw daemon is deployed, and/or when the realm configuration is modified. Once a mgr/rgw module exists, we should probably migrate this code there.
Fixes: https://tracker.ceph.com/issues/51302