October 2023 - ceph-users

by Dan van der Ster

Hi all, Here are this week's notes from the CLT: * Collective review of the Reef/Squid "State of Cephalopod" slides. * Smoke test suite was unscheduled but it's back on now. * Releases: * 17.2.7: about to start building last week, delayed by a few issues (https://tracker.ceph.com/issues/63257, https://tracker.ceph.com/issues/63305, https://github.com/ceph/ceph/pull/54169). ceph_exporter test coverage will be prioritized. * 18.2.1: all PRs in testing or merged. * Ceph Board approved a new Foundation member tiers model, Silver, Gold, Platinum, Diamond. Working on implementation with LF. -- dan

6 months, 3 weeks

1
0
0 0

Ceph 16.2.14: pgmap updated every few seconds for no apparent reason

by Zakhar Kirpichenko

Hi, I am investigating excessive mon writes in our cluster and wondering whether excessive pgmap updates could be the culprit. Basically pgmap is updated every few seconds, sometimes over ten times per minute, in a healthy cluster with no OSD and/or PG changes: Oct 13 11:03:03 ceph03 bash[4019]: cluster 2023-10-13T11:03:01.515438+0000 mgr.ceph01.vankui (mgr.336635131) 838252 : cluster [DBG] pgmap v606575: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 60 MiB/s rd, 109 MiB/s wr, 5.65k op/s Oct 13 11:03:04 ceph03 bash[4019]: cluster 2023-10-13T11:03:03.520953+0000 mgr.ceph01.vankui (mgr.336635131) 838253 : cluster [DBG] pgmap v606576: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 64 MiB/s rd, 128 MiB/s wr, 5.76k op/s Oct 13 11:03:06 ceph03 bash[4019]: cluster 2023-10-13T11:03:05.524474+0000 mgr.ceph01.vankui (mgr.336635131) 838255 : cluster [DBG] pgmap v606577: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 64 MiB/s rd, 122 MiB/s wr, 5.57k op/s Oct 13 11:03:08 ceph03 bash[4019]: cluster 2023-10-13T11:03:07.530484+0000 mgr.ceph01.vankui (mgr.336635131) 838256 : cluster [DBG] pgmap v606578: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 79 MiB/s rd, 127 MiB/s wr, 6.62k op/s Oct 13 11:03:10 ceph03 bash[4019]: cluster 2023-10-13T11:03:09.533337+0000 mgr.ceph01.vankui (mgr.336635131) 838258 : cluster [DBG] pgmap v606579: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 66 MiB/s rd, 104 MiB/s wr, 5.38k op/s Oct 13 11:03:12 ceph03 bash[4019]: cluster 2023-10-13T11:03:11.537908+0000 mgr.ceph01.vankui (mgr.336635131) 838259 : cluster [DBG] pgmap v606580: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 85 MiB/s rd, 121 MiB/s wr, 6.43k op/s Oct 13 11:03:13 ceph03 bash[4019]: cluster 2023-10-13T11:03:13.543490+0000 mgr.ceph01.vankui (mgr.336635131) 838260 : cluster [DBG] pgmap v606581: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 78 MiB/s rd, 127 MiB/s wr, 6.54k op/s Oct 13 11:03:16 ceph03 bash[4019]: cluster 2023-10-13T11:03:15.547122+0000 mgr.ceph01.vankui (mgr.336635131) 838262 : cluster [DBG] pgmap v606582: 2400 pgs: 5 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 71 MiB/s rd, 122 MiB/s wr, 6.08k op/s Oct 13 11:03:18 ceph03 bash[4019]: cluster 2023-10-13T11:03:17.553180+0000 mgr.ceph01.vankui (mgr.336635131) 838263 : cluster [DBG] pgmap v606583: 2400 pgs: 1 active+clean+scrubbing, 5 active+clean+scrubbing+deep, 2394 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 75 MiB/s rd, 176 MiB/s wr, 6.83k op/s Oct 13 11:03:20 ceph03 bash[4019]: cluster 2023-10-13T11:03:19.555960+0000 mgr.ceph01.vankui (mgr.336635131) 838264 : cluster [DBG] pgmap v606584: 2400 pgs: 1 active+clean+scrubbing, 5 active+clean+scrubbing+deep, 2394 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 58 MiB/s rd, 161 MiB/s wr, 5.55k op/s Oct 13 11:03:22 ceph03 bash[4019]: cluster 2023-10-13T11:03:21.560597+0000 mgr.ceph01.vankui (mgr.336635131) 838266 : cluster [DBG] pgmap v606585: 2400 pgs: 1 active+clean+scrubbing, 5 active+clean+scrubbing+deep, 2394 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 62 MiB/s rd, 221 MiB/s wr, 6.19k op/s Oct 13 11:03:24 ceph03 bash[4019]: cluster 2023-10-13T11:03:23.565974+0000 mgr.ceph01.vankui (mgr.336635131) 838267 : cluster [DBG] pgmap v606586: 2400 pgs: 1 active+clean+scrubbing, 5 active+clean+scrubbing+deep, 2394 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 50 MiB/s rd, 246 MiB/s wr, 5.93k op/s Oct 13 11:03:26 ceph03 bash[4019]: cluster 2023-10-13T11:03:25.569471+0000 mgr.ceph01.vankui (mgr.336635131) 838269 : cluster [DBG] pgmap v606587: 2400 pgs: 1 active+clean+scrubbing, 5 active+clean+scrubbing+deep, 2394 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 41 MiB/s rd, 240 MiB/s wr, 4.99k op/s Oct 13 11:03:28 ceph03 bash[4019]: cluster 2023-10-13T11:03:27.575618+0000 mgr.ceph01.vankui (mgr.336635131) 838270 : cluster [DBG] pgmap v606588: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 44 MiB/s rd, 259 MiB/s wr, 5.38k op/s Oct 13 11:03:30 ceph03 bash[4019]: cluster 2023-10-13T11:03:29.578262+0000 mgr.ceph01.vankui (mgr.336635131) 838271 : cluster [DBG] pgmap v606589: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 31 MiB/s rd, 195 MiB/s wr, 4.06k op/s Oct 13 11:03:32 ceph03 bash[4019]: cluster 2023-10-13T11:03:31.582849+0000 mgr.ceph01.vankui (mgr.336635131) 838272 : cluster [DBG] pgmap v606590: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 35 MiB/s rd, 197 MiB/s wr, 4.43k op/s Oct 13 11:03:34 ceph03 bash[4019]: cluster 2023-10-13T11:03:33.588249+0000 mgr.ceph01.vankui (mgr.336635131) 838274 : cluster [DBG] pgmap v606591: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 39 MiB/s rd, 138 MiB/s wr, 4.50k op/s Oct 13 11:03:36 ceph03 bash[4019]: cluster 2023-10-13T11:03:35.591837+0000 mgr.ceph01.vankui (mgr.336635131) 838276 : cluster [DBG] pgmap v606592: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 35 MiB/s rd, 92 MiB/s wr, 3.90k op/s Oct 13 11:03:37 ceph03 bash[4019]: cluster 2023-10-13T11:03:37.597899+0000 mgr.ceph01.vankui (mgr.336635131) 838277 : cluster [DBG] pgmap v606593: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 42 MiB/s rd, 77 MiB/s wr, 4.47k op/s Oct 13 11:03:39 ceph03 bash[4019]: cluster 2023-10-13T11:03:39.600591+0000 mgr.ceph01.vankui (mgr.336635131) 838278 : cluster [DBG] pgmap v606594: 2400 pgs: 4 active+clean+scrubbing+deep, 2396 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 34 MiB/s rd, 39 MiB/s wr, 3.61k op/s Oct 13 11:03:41 ceph03 bash[4019]: cluster 2023-10-13T11:03:41.605546+0000 mgr.ceph01.vankui (mgr.336635131) 838279 : cluster [DBG] pgmap v606595: 2400 pgs: 1 active+clean+scrubbing, 4 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 41 MiB/s rd, 42 MiB/s wr, 4.21k op/s Oct 13 11:03:43 ceph03 bash[4019]: cluster 2023-10-13T11:03:43.610694+0000 mgr.ceph01.vankui (mgr.336635131) 838281 : cluster [DBG] pgmap v606596: 2400 pgs: 1 active+clean+scrubbing, 4 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 49 MiB/s rd, 49 MiB/s wr, 4.59k op/s Oct 13 11:03:45 ceph03 bash[4019]: cluster 2023-10-13T11:03:45.614721+0000 mgr.ceph01.vankui (mgr.336635131) 838283 : cluster [DBG] pgmap v606597: 2400 pgs: 1 active+clean+scrubbing, 4 active+clean+scrubbing+deep, 2395 active+clean; 16 TiB data, 61 TiB used, 716 TiB / 777 TiB avail; 44 MiB/s rd, 49 MiB/s wr, 4.15k op/s Within 14 hours of today pgmap was updated 19960 times for no apparent reason. The cluster is healthy and nothing is going on apart from normal I/O. Are frequent pgmap updates expected behavior? What may be causing these updates? I would very much appreciate your comments and suggestions. Best regards, Zakhar

6 months, 3 weeks

3
5
0 0

Combining masks in ceph config

by Frank Schilder

Hi all, I have a case where I want to set options for a set of HDDs under a common sub-tree with root A. I have also HDDs in another disjoint sub-tree with root B. Therefore, I would like to do something like ceph config set osd/class:hdd,datacenter:A option value The above does not give a syntax error, but I'm also not sure it does the right thing. Does the above mean "class:hdd and datacenter:A" or does it mean "for OSDs with device class 'hdd,datacenter:A'"? Thanks and best regards, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14

6 months, 3 weeks

1
0
0 0

Quincy: failure to enable mgr rgw module if not --force

by Michel Jouvin

Hi, I'm trying to use the rgw mgr module to configure RGWs. Unfortunately it is not present in 'ceph mgr module ls' list and any attempt to enable it suggests that one mgr doesn't support it and that --force should be added. Adding --force effectively enabled it. It is strange as it is a brand new cluster, created in Quincy, using cephadm. Why this need for --force? And it seems that even if the module is listed as enabled, the 'ceph rgw' command is not recognized and the help is not available for the rgw subcommand? What are we doing wrong? Cheers, Michel

6 months, 3 weeks

3
3
0 0

Dashboard crash with rook/reef and external prometheus

by r-ceph＠rich0.org

I'm fairly new to the community so I figured I'd ask about this here before creating an issue - I'm not sure how supported this config is. I am running rook v1.12.6 and ceph 18.2.0. I've enabled the dashboard in the CRD and it has been working for a while. However, the charts are empty. I do have Prometheus+Grafana running on my cluster, and I can access many of the ceph metrics from there. With the upgrade to reef I noticed that many of the qunicy dashboard elements have been replaced by charts, so I wanted to get those working. I discovered that if I run ceph dashboard set-prometheus-api-host <url> the charts immediately are populated (including historical data). However, when I do this I rapidly start getting ceph health alerts due to a crashing mgr module. If I set the prometheus api host url to '' the crashes stop accumulating, though this disables the charts. I am running the prometheus-community/prometheus-25.2.0 chart. Various ceph grafana dashboards that I've found published work fine. The following are relevant dumps. Please let me know if you have any ideas, or if I should go ahead and create an issue for this... mgr console output during crash: debug 2023-10-24T15:11:23.498+0000 7fc81fa5d700 -1 mgr.server reply reply (2) No such file or directory This Orchestrator does not support `orch prometheus access info` debug 2023-10-24T15:11:23.502+0000 7fc7ea3f3700 0 [dashboard INFO request] [::ffff:10.1.0.106:49760] [GET] [200] [0.012s] [admin] [101.0B] /api/health/get_cluster_capacity debug 2023-10-24T15:11:23.502+0000 7fc813985700 0 [stats WARNING root] cmdtag not found in client metadata debug 2023-10-24T15:11:23.502+0000 7fc813985700 0 [stats WARNING root] cmdtag not found in client metadata debug 2023-10-24T15:11:23.502+0000 7fc7e83ef700 0 [dashboard INFO request] [::ffff:10.1.0.106:5580] [GET] [200] [0.011s] [admin] [73.0B] /api/osd/settings debug 2023-10-24T15:11:23.506+0000 7fc85411a700 0 log_channel(audit) log [DBG] : from='mon.2 -' entity='mon.' cmd=[{"prefix": "balancer status", "format": "json"}]: dispatch debug 2023-10-24T15:11:23.506+0000 7fc813985700 0 [stats WARNING root] cmdtag not found in client metadata debug 2023-10-24T15:11:23.506+0000 7fc7e9bf2700 0 [dashboard INFO request] [::ffff:10.1.0.106:20241] [GET] [200] [0.014s] [admin] [34.0B] /api/prometheus/rules debug 2023-10-24T15:11:23.630+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:23.734+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:23.802+0000 7fc86511c700 0 log_channel(cluster) log [DBG] : pgmap v126: 617 pgs: 53 active+remapped+backfill_wait, 2 active+remapped+backfilling, 562 active+clean; 34 TiB data, 68 TiB used, 64 TiB / 132 TiB avail; 2.4 MiB/s rd, 93 KiB/s wr, 21 op/s; 1213586/22505781 objects misplaced (5.392%) debug 2023-10-24T15:11:23.862+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:23.962+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.058+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.158+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.270+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.546+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.654+0000 7fc7ebbf6700 0 [dashboard INFO orchestrator] is orchestrator available: True, debug 2023-10-24T15:11:24.654+0000 7fc7ebbf6700 0 [dashboard INFO request] [::ffff:10.1.0.106:13711] [GET] [200] [1.170s] [admin] [3.2K] /api/health/minimal debug 2023-10-24T15:11:25.802+0000 7fc86511c700 0 log_channel(cluster) log [DBG] : pgmap v127: 617 pgs: 53 active+remapped+backfill_wait, 2 active+remapped+backfilling, 562 active+clean; 34 TiB data, 68 TiB used, 64 TiB / 132 TiB avail; 1.1 MiB/s rd, 53 KiB/s wr, 17 op/s; 1213586/22505781 objects misplaced (5.392%) debug 2023-10-24T15:11:27.802+0000 7fc86511c700 0 log_channel(cluster) log [DBG] : pgmap v128: 617 pgs: 53 active+remapped+backfill_wait, 2 active+remapped+backfilling, 562 active+clean; 34 TiB data, 68 TiB used, 64 TiB / 132 TiB avail; 1.8 MiB/s rd, 58 KiB/s wr, 18 op/s; 1213586/22505781 objects misplaced (5.392%) debug 2023-10-24T15:11:28.494+0000 7fc813985700 0 [stats WARNING root] cmdtag not found in client metadata debug 2023-10-24T15:11:28.498+0000 7fc7eb3f5700 0 [dashboard INFO request] [::ffff:10.1.0.106:20241] [GET] [200] [0.011s] [admin] [73.0B] /api/osd/settings debug 2023-10-24T15:11:28.498+0000 7fc85411a700 0 log_channel(audit) log [DBG] : from='mon.2 -' entity='mon.' cmd=[{"prefix": "orch prometheus access info"}]: dispatch debug 2023-10-24T15:11:28.502+0000 7fc7ec3f7700 0 [dashboard INFO request] [::ffff:10.1.0.106:5580] [GET] [200] [0.006s] [admin] [102.0B] /api/health/get_cluster_capacity debug 2023-10-24T15:11:28.502+0000 7fc7e93f1700 0 [dashboard INFO request] [::ffff:10.1.0.106:44009] [GET] [200] [0.005s] [admin] [22.0B] /api/prometheus/notifications debug 2023-10-24T15:11:28.502+0000 7fc81fa5d700 -1 Remote method threw exception: Traceback (most recent call last): File "/usr/share/ceph/mgr/orchestrator/_interface.py", line 675, in get_prometheus_access_info raise NotImplementedError() NotImplementedError ceph crash info dump: { "backtrace": [ " File \"/usr/share/ceph/mgr/orchestrator/_interface.py\", line 675, in get_prometheus_access_info\n raise NotImplementedError()", "NotImplementedError" ], "ceph_version": "18.2.0", "crash_id": "2023-10-24T14:59:52.921427Z_08e06575-0431-47fe-afc5-be8e4a7d1144", "entity_name": "mgr.a", "mgr_module": "rook", "mgr_module_caller": "ActivePyModule::dispatch_remote get_prometheus_access_info", "mgr_python_exception": "NotImplementedError", "os_id": "centos", "os_name": "CentOS Stream", "os_version": "8", "os_version_id": "8", "process_name": "ceph-mgr", "stack_sig": "bbf52dcdbbe54d67edf59ebdb5d201fffd921db5a9dd4431964c2aaac2250c7e", "timestamp": "2023-10-24T14:59:52.921427Z", "utsname_hostname": "k8s4", "utsname_machine": "x86_64", "utsname_release": "5.15.0-87-generic", "utsname_sysname": "Linux", "utsname_version": "#97-Ubuntu SMP Mon Oct 2 21:09:21 UTC 2023" } -- Rich

6 months, 4 weeks

1
0
0 0

traffic by IP address / bucket / user

by Boris Behrens

Hi, did someone have a solution ready to monitor traffic by IP address? Cheers Boris

6 months, 4 weeks

2
1
0 0

Modify user op status=-125

by mahnoosh shahidi

Hi all, I couldn't understand what does the status -125 mean from the docs. I'm getting 500 response status code when I call rgw admin APIs and the only log in the rgw log files is as follows. s3:get_obj recalculating target initializing for trans_id = tx00000aa90f570fb8281cf-006537bf9e-84395fa-default s3:get_obj reading permissions getting op 1 s3:put_obj verifying requester s3:put_obj normalizing buckets and tenants s3:put_obj init permissions s3:put_obj recalculating target s3:put_obj reading permissions s3:put_obj init op s3:put_obj verifying op mask s3:put_obj verifying op permissions s3:put_obj verifying op params s3:put_obj pre-executing s3:put_obj executing :modify_user completing WARNING: set_req_state_err err_no=125 resorting to 500 :modify_user op status=-125 :modify_user http status=500 ====== req done req=0x7f3f85a78620 op status=-125 http_status=500 latency=0.076000459s ====== Can anyone explain what this error means and why it's happening? Best Regards, Mahnoosh

6 months, 4 weeks

2
4
0 0

RadosGW load balancing with Kubernetes + ceph orch

by Janek Bevendorff

Hey all, My Ceph cluster is managed mostly by cephadm / ceph orch to avoid circular dependencies between in our infrastructure deployment. Our RadosGW endpoints, however, are managed by Kubernetes, since it provides proper load balancing and service health checks. This leaves me in the unsatisfactory situation that Ceph complains about 'stray' RGW daemons in the cluster. The only two solutions to this that I found were a) to turn of the warning, which applies to all daemons and not just the RGWs (not pretty!), or b) to move the deployment out of Kubernetes. For the latter, I could define external Endpoints in Kubernetes, so that I still have load balancing, but then I don't have proper health checks any more. Meaning, if one of the RGW endpoints goes down, requests to our S3 endpoint will intermittently time out in round-robin fashion (not pretty at all!). Can you think of a better option to solve this? I would already be satisfied with turning off the warning for RGW daemons only, but there doesn't seem to be a config option for that. Thanks Janek

6 months, 4 weeks

1
0
0 0

Ceph orch OSD redeployment after boot on stateless RAM root

by Janek Bevendorff

Hi, I recently moved from a manual Ceph deployment using Saltstack to a hybrid of Saltstack and cephadm / ceph orch. We are provisioning our Ceph hosts using a stateless PXE RAM root, so I definitely need Saltstack to bootstrap at least the Ceph APT repository and the MON/MGR deployment. After that, ceph orch can take over and deploy the remaining daemons. The MONs/MGRs are deployed after each reboot with cephadm deploy --name mon.{{ ceph.node_id }} --fsid {{ ceph.conf.global.fsid }} --config /etc/ceph/ceph.conf cephadm deploy --name mgr.{{ ceph.node_id }} --fsid {{ ceph.conf.global.fsid }} --config /etc/ceph/ceph.conf (the MON store is provided in /var/lib/ceph/{{ ceph.conf.global.fsid }}/mon.{{ ceph.node_id }}). Since cephadm ceph-volume lvm activate --all is broken (see https://tracker.ceph.com/issues/55395), I am activating each OSD individually like this: cephadm deploy --name osd.{{ osd_id }} --fsid {{ ceph.conf.global.fsid }} --osd-fsid {{ osd_fsid }} --config /etc/ceph/ceph.conf Now my question: Is there a better way to do this and can ceph orch take care of this in the same way it deploys my MDS? All OSDs are listed as <unmanaged> in ceph orch ls (I think this is by design?) and I cannot find a way to activate them automatically via ceph orch when the host boots up. I tried ceph cephadm osd activate HOSTNAME, but all I get is "Created no osd(s) on host HOSTNAME; already created?" The docs only talk about how I can create new OSDs, but not how I can automatically redeploy existing OSDs after a fresh boot. It seems like it is generally assumed that OSD deployments are persistent and next time the host boots, systemd simply activates the existing units. I'd be glad about any hints! Janek

6 months, 4 weeks

1
0
0 0

ATTN: DOCS rgw bucket pubsub notification.

by Artem Torubarov

Hi, The latest documentation <https://docs.ceph.com/en/latest/radosgw/s3-notification-compatibility/#supp…> says that: "pulling and acking of events stored in Ceph (as an internal destination)." is a valid source for s3 notifications. If i got it right, pull-based subscription was possible only with radosgw PubSub sync module, which was removed in reef release <https://docs.ceph.com/en/latest/releases/reef/#:~:text=The%20pubsub%20funct…> . Suggested changes: Currently, we support: HTTP/S, Kafka and AMQP. And also support pulling and acking of events stored in Ceph (as an internal destination). Best regards, Artem

7 months

3
2
0 0

2024

2023

2022

2021

2020

2019

ceph-users October 2023