mgr/cephadm: automatically configure dashboard <-> RGW connection#41590
mgr/cephadm: automatically configure dashboard <-> RGW connection#41590liewegas wants to merge 1 commit intoceph:masterfrom
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.
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.
@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.
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.
@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.
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.
@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.
@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.
@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.
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.
@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