[ceph-users] Re: Reef RGWs stop processing requests
Thanks Enrico, We are only syncing metadata between sites, so I don't think that bug will be the cause of our issues. I have been able to delete ~30k objects without causing the RGW to stop processing. Thanks Iain From: Enrico Bocchi Sent: 22 May 2024 13:48 To: Iain Stott ; ceph-users@ceph.io Subject: Re: [ceph-users] Reef RGWs stop processing requests CAUTION: This email originates from outside THG Hi Iain, Can you check if it relates to this? -- https://tracker.ceph.com/issues/63373<https://tracker.ceph.com/issues/63373> There is a bug when bulk deleting objects, causing the RGWs to deadlock. Cheers, Enrico On 5/17/24 11:24, Iain Stott wrote: > Hi, > > We are running 3 clusters in multisite. All 3 were running Quincy 17.2.6 and > using cephadm. We upgraded one of the secondary sites to Reef 18.2.1 a couple > of weeks ago and were planning on doing the rest shortly afterwards. > > We run 3 RGW daemons on separate physical hosts behind an external HAProxy HA > pair for each cluster. > > Since we upgrade to Reef we have had issues with the RGWs stopping processing > requests. We can see that they don't crash as they still have entries in the > logs about syncing, but as far as request processing goes, they just stop. > While debugging this we have 1 of the 3 RGWs running a Quincy image, and this > has never had an issue where it stops processing requests. Any Reef > containers we deploy have always stopped within 48Hrs of being deployed. We > have tried Reef versions 18.2.1, 18.2.2 and 18.1.3 and all exhibit the same > issue. We are running podman 4.6.1 on Centos 8 with kernel > 4.18.0-513.24.1.el8_9.x86_64. > > We have enabled debug logs for the RGWs but we have been unable to find > anything in them that would shed light on the cause. > > We are just wondering if anyone had any ideas on what could be causing this > or how to debug it further? > > Thanks > Iain > > Iain Stott > OpenStack Engineer > iain.st...@thg.com > [THG Ingenuity Logo]<https://www.thg.com<https://www.thg.com>> > www.thg.com<http://www.thg.com><https://www.thg.com/<https://www.thg.com/>> > [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk>> > [Instagram] <https://www.instagram.com/thg<https://www.instagram.com/thg>> > [X] <https://twitter.com/thgplc?lang=en<https://twitter.com/thgplc?lang=en>> > ___ > ceph-users mailing list -- ceph-users@ceph.io > To unsubscribe send an email to ceph-users-le...@ceph.io -- Enrico Bocchi CERN European Laboratory for Particle Physics IT - Storage & Data Management - General Storage Services Mailbox: G20500 - Office: 31-2-010 1211 Genève 23 Switzerland ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Reef RGWs stop processing requests
Hi, We are running 3 clusters in multisite. All 3 were running Quincy 17.2.6 and using cephadm. We upgraded one of the secondary sites to Reef 18.2.1 a couple of weeks ago and were planning on doing the rest shortly afterwards. We run 3 RGW daemons on separate physical hosts behind an external HAProxy HA pair for each cluster. Since we upgrade to Reef we have had issues with the RGWs stopping processing requests. We can see that they don't crash as they still have entries in the logs about syncing, but as far as request processing goes, they just stop. While debugging this we have 1 of the 3 RGWs running a Quincy image, and this has never had an issue where it stops processing requests. Any Reef containers we deploy have always stopped within 48Hrs of being deployed. We have tried Reef versions 18.2.1, 18.2.2 and 18.1.3 and all exhibit the same issue. We are running podman 4.6.1 on Centos 8 with kernel 4.18.0-513.24.1.el8_9.x86_64. We have enabled debug logs for the RGWs but we have been unable to find anything in them that would shed light on the cause. We are just wondering if anyone had any ideas on what could be causing this or how to debug it further? Thanks Iain Iain Stott OpenStack Engineer iain.st...@thg.com [THG Ingenuity Logo]<https://www.thg.com> www.thg.com<https://www.thg.com/> [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [Instagram] <https://www.instagram.com/thg> [X] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Reef RGWs stop processing requests
Hi, We are running 3 clusters in multisite. All 3 were running Quincy 17.2.6 and using cephadm. We upgraded one of the secondary sites to Reef 18.2.1 a couple of weeks ago and were planning on doing the rest shortly afterwards. We run 3 RGW daemons on separate physical hosts behind an external HAProxy HA pair for each cluster. Since we upgrade to Reef we have had issues with the RGWs stopping processing requests. We can see that they don't crash as they still have entries in the logs about syncing, but as far as request processing goes, they just stop. While debugging this we have 1 of the 3 RGWs running a Quincy image, and this has never had an issue where it stops processing requests. Any Reef containers we deploy have always stopped within 48Hrs of being deployed. We have tried Reef versions 18.2.1, 18.2.2 and 18.1.3 and all exhibit the same issue. We are running podman 4.6.1 on Centos 8 with kernel 4.18.0-513.24.1.el8_9.x86_64. We have enabled debug logs for the RGWs but we have been unable to find anything in them that would shed light on the cause. We are just wondering if anyone had any ideas on what could be causing this or how to debug it further? Thanks Iain Iain Stott OpenStack Engineer iain.st...@thg.com [THG Ingenuity Logo]<https://www.thg.com> www.thg.com<https://www.thg.com/> [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [Instagram] <https://www.instagram.com/thg> [X] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] RGWs stop processing requests after upgrading to Reef
Hi, We have recently upgraded one of our clusters from Quincy 17.2.6 to Reef 18.2.1, since then we have had 3 instances of our RGWs stop processing requests. We have 3 hosts that run a single instance of RGW on each, and all 3 just seem to stop processing requests at the same time causing our storage to become unavailable. A restart or redeploy of the RGW service brings them back ok. The cluster was deployed using ceph ansible, but since we have adopted it to cephadm which is how the upgrade was performed. We have enabled debug logging as there was nothing out of the ordinary in normal logs and are currently sifting through them from the last crash. We are just wondering if it possible to run Quincy RGWs instead of Reef as we didn't have this issue prior to the upgrade? We have 3 clusters in a multisite setup, we are holding off on upgrading the other 2 clusters due to this issue. Thanks Iain Iain Stott OpenStack Engineer iain.st...@thg.com [THG Ingenuity Logo]<https://www.thg.com> www.thg.com<https://www.thg.com/> [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [Instagram] <https://www.instagram.com/thg> [X] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] RGWs stop processing requests after upgrading to Reef
Hi, We have recently upgraded one of our clusters from Quincy 17.2.6 to Reef 18.2.1, since then we have had 3 instances of our RGWs stop processing requests. We have 3 hosts that run a single instance of RGW on each, and all 3 just seem to stop processing requests at the same time causing our storage to become unavailable. A restart or redeploy of the RGW service brings them back ok. The cluster was deployed using ceph ansible, but since we have adopted it to cephadm which is how the upgrade was performed. We have enabled debug logging as there was nothing out of the ordinary in normal logs and are currently sifting through them from the last crash. We are just wondering if it possible to run Quincy RGWs instead of Reef as we didn't have this issue prior to the upgrade? We have 3 clusters in a multisite setup, we are holding off on upgrading the other 2 clusters due to this issue. Thanks Iain Iain Stott OpenStack Engineer iain.st...@thg.com [THG Ingenuity Logo]<https://www.thg.com> www.thg.com<https://www.thg.com/> [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [Instagram] <https://www.instagram.com/thg> [X] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Cephadm on mixed architecture hosts
O thanks John, will give it a try and report back From: John Mulligan Sent: 26 March 2024 14:24 To: ceph-users@ceph.io Cc: Iain Stott Subject: Re: [ceph-users] Cephadm on mixed architecture hosts CAUTION: This email originates from outside THG On Tuesday, March 26, 2024 7:22:18 AM EDT Iain Stott wrote: > Hi, > > We are trying to deploy Ceph Reef 18.2.1 using cephadm on mixed architecture > hosts using x86_64 for the mons and aarch64 for the OSDs. > > During deployment we use the following config for the bootstrap process, > where $REPOSITORY is our docker repo. > > [global] > container_image = $REPOSITORY/ceph/ceph:v18.2.1 > [mgr] > mgr/cephadm/container_image_base = $REPOSITORY/ceph/ceph:v18.2.1 > mgr/cephadm/container_image_prometheus = $REPOSITORY/ceph/prometheus:v2.33.4 > mgr/cephadm/container_image_node_exporter = > $REPOSITORY/ceph/node-exporter:v1.3.1 mgr/cephadm/container_image_grafana = > $REPOSITORY/ceph/ceph-grafana:8.3.5 > mgr/cephadm/container_image_alertmanager = > $REPOSITORY/ceph/alertmanager:v0.23.0 [osd] > container_image = $REPOSITORY/ceph/ceph:v18.2.1 > Once the bootstrap process is complete, if we do a ceph config dump, the > container image for global and osd changes from version tag to sha > reference, meaning that when deploying the containers on the OSDs they try > using the amd64 container image and not the aarch64 image and fail > deployment. > > Is there a config setting we are missing or a workaround for this? > Try: `ceph config set mgr mgr/cephadm/use_repo_digest false` This comes up often enough that we should document it. I don't think that option is documented right now because I searched for the option with google and all that came up were other tracker issues and older mailing-list posts. In the longer term we may want to make cephadm arch-aware (volunteers welcome :-) ). ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Cephadm on mixed architecture hosts
Hi, We are trying to deploy Ceph Reef 18.2.1 using cephadm on mixed architecture hosts using x86_64 for the mons and aarch64 for the OSDs. During deployment we use the following config for the bootstrap process, where $REPOSITORY is our docker repo. [global] container_image = $REPOSITORY/ceph/ceph:v18.2.1 [mgr] mgr/cephadm/container_image_base = $REPOSITORY/ceph/ceph:v18.2.1 mgr/cephadm/container_image_prometheus = $REPOSITORY/ceph/prometheus:v2.33.4 mgr/cephadm/container_image_node_exporter = $REPOSITORY/ceph/node-exporter:v1.3.1 mgr/cephadm/container_image_grafana = $REPOSITORY/ceph/ceph-grafana:8.3.5 mgr/cephadm/container_image_alertmanager = $REPOSITORY/ceph/alertmanager:v0.23.0 [osd] container_image = $REPOSITORY/ceph/ceph:v18.2.1 Once the bootstrap process is complete, if we do a ceph config dump, the container image for global and osd changes from version tag to sha reference, meaning that when deploying the containers on the OSDs they try using the amd64 container image and not the aarch64 image and fail deployment. Is there a config setting we are missing or a workaround for this? Thanks Iain Iain Stott OpenStack Engineer iain.st...@thg.com [THG Ingenuity Logo]<https://www.thg.com> www.thg.com<https://www.thg.com/> [LinkedIn]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [Instagram] <https://www.instagram.com/thg> [X] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Slow recovery and inaccurate recovery figures since Quincy upgrade
Hi Sridhar,
Thanks for the response, I have added the output you requested below, I have
attached the output from the last command in a file as it was rather long. We
did try to set high_recovery_ops but it didn't seem to have any visible effect.
root@gb4-li-cephgw-001 ~ # ceph versions
{
"mon": {
"ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy
(stable)": 3
},
"mgr": {
"ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy
(stable)": 3
},
"osd": {
"ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy
(stable)": 72
},
"mds": {},
"rgw": {
"ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy
(stable)": 3
},
"overall": {
"ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy
(stable)": 81
}
}
root@gb4-li-cephgw-001 ~ # ceph config get osd.0 osd_op_queue
mclock_scheduler
root@gb4-li-cephgw-001 ~ # ceph config show osd.0 | grep osd_max_backfills
osd_max_backfills3
override (mon[3]),default[10]
root@gb4-li-cephgw-001 ~ # ceph config show osd.0 | grep osd_recovery_max_active
osd_recovery_max_active 9
override (mon[9]),default[0]
osd_recovery_max_active_hdd 10
default
osd_recovery_max_active_ssd 20
default
Thanks
Iain
From: Sridhar Seshasayee
Sent: 03 October 2023 09:07
To: Iain Stott
Cc: ceph-users@ceph.io ; dl-osadmins
Subject: Re: [ceph-users] Slow recovery and inaccurate recovery figures since
Quincy upgrade
CAUTION: This email originates from outside THG
Hello Iain,
Does anyone have any ideas of what could be the issue here or anywhere we can
check what is going on??
You could be hitting the slow backfill/recovery issue with mclock_scheduler.
Could you please provide the output of the following commands?
1. ceph versions
2. ceph config get osd. osd_op_queue
3. ceph config show osd. | grep osd_max_backfills
4. ceph config show osd. | grep osd_recovery_max_active
5. ceph config show-with-defaults osd. | grep osd_mclock where 'id' can be
any valid osd id
With the mclock_scheduler enabled and with 17.2.5, it is not possible to
override
recovery settings like 'osd_max_backfills' and other recovery related config
options.
To improve the recovery rate, you can temporarily switch the mClock profile to
'high_recovery_ops'
on all the OSDs by issuing:
ceph config set osd osd_mclock_profile high_recovery_ops
During recovery with this profile, you may notice a dip in the client ops
performance which is expected.
Once the recovery is done, you can switch the mClock profile back to the
default 'high_client_ops' profile.
Please note that the upcoming Quincy release will address the slow backfill
issues along with other
usability improvements.
-Sridhar
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Slow recovery and inaccurate recovery figures since Quincy upgrade
-003(active, since 2h), standbys: gb4-li-cephgw-002.iqmxgu, gb4-li-cephgw-001 osd: 72 osds: 72 up (since 39m), 72 in (since 3d); 1 remapped pgs flags noout,norebalance rgw: 3 daemons active (3 hosts, 1 zones) data: pools: 11 pools, 1457 pgs objects: 63.76M objects, 173 TiB usage: 251 TiB used, 275 TiB / 526 TiB avail pgs: 58157/371260644 objects degraded (0.016%) 1452 active+clean 4active+clean+scrubbing+deep 1active+undersized+degraded+remapped+backfilling io: client: 243 MiB/s rd, 285 KiB/s wr, 252 op/s rd, 197 op/s wr recovery: 13 KiB/s, 0 keys/s, 1 objects/s progress: Global Recovery Event (39m) [===.] (remaining: 1s) [ceph: root@gb4-li-cephgw-001 /]# Iain Stott OpenStack Engineer iain.st...@thehutgroup.com [THG Ingenuity Logo]<https://www.thg.com> [https://i.imgur.com/wbpVRW6.png]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk> [https://i.imgur.com/c3040tr.png] <https://twitter.com/thgplc?lang=en> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Cephadm adoption - service reconfiguration changes container image
Yeah this seems to have done the trick. I still need to complete the full cluster adoption, but after mon and mgr reconfigure they have come back up and built from the correct image. Thanks for this. ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Cephadm adoption - service reconfiguration changes container image
Thanks Adam,
Will give it a try today.
Cheers
From: Adam King
Sent: 15 August 2023 15:40
To: Iain Stott
Cc: ceph-users@ceph.io
Subject: Re: [ceph-users] Cephadm adoption - service reconfiguration changes
container image
CAUTION: This email originates from outside THG
you could maybe try running "ceph config set global container
quay.io/ceph/ceph:v16.2.9<http://quay.io/ceph/ceph:v16.2.9>" before running the
adoption. It seems it still thinks it should be deploying mons with the default
image
(docker.io/ceph/daemon-base:latest-pacific-devel<http://docker.io/ceph/daemon-base:latest-pacific-devel>
) for some reason and maybe that config option is why.
On Tue, Aug 15, 2023 at 7:29 AM Iain Stott
mailto:iain.st...@thehutgroup.com>> wrote:
Hi Everyone,
We are looking at migrating all our production clusters from ceph-ansible to
cephadm. We are currently experiencing an issue where when reconfiguring a
service through ceph orch, it will change the running container image for that
service which has led to the mgr services running an earlier version than the
rest of the cluster, this has caused cephadm/ceph orch to not be able to manage
services in the cluster.
Does anyone have any help with this as I cannot find anything in the docs that
would correct this.
Cheers
Iain
[root@de1-ceph-mon-ceph-site-a-1 ~]# cephadm --image
quay.io/ceph/ceph:v16.2.9<http://quay.io/ceph/ceph:v16.2.9> adopt --style
legacy --name mon.$(hostname -s)
[root@de1-ceph-mon-ceph-site-a-1 ~]# cat ./mon.yaml
service_type: mon
service_name: mon
placement:
host_pattern: '*mon*'
extra_container_args:
- -v
- /etc/ceph/ceph.client.admin.keyring:/etc/ceph/ceph.client.admin.keyring
[root@de1-ceph-mon-ceph-site-a-1 ~]# cephadm shell -- ceph config get mgr
mgr/cephadm/container_image_base
quay.io/ceph/ceph<http://quay.io/ceph/ceph>
[root@de1-ceph-mon-ceph-site-a-1 ~]# podman ps -a | grep mon
55fe8bc10476 quay.io/ceph/ceph:v16.2.9<http://quay.io/ceph/ceph:v16.2.9>
-n mgr.de1-ceph-m... 5 minutes ago Up 5
minutes
ceph-da9e9837-a3cf-4482-9a13-790a721598cd-mgr-de1-ceph-mon-ceph-site-a-1
[root@de1-ceph-mon-ceph-site-a-1 ~]# cat ./mon.yaml | cephadm --image
quay.io/ceph/ceph:v16.2.9<http://quay.io/ceph/ceph:v16.2.9> shell -- ceph orch
apply -i -
Inferring fsid da9e9837-a3cf-4482-9a13-790a721598cd
Scheduled mon update...
[root@de1-ceph-mon-ceph-site-a-1 ~]# podman ps -a | grep mon
ecec1d62c719
docker.io/ceph/daemon-base:latest-pacific-devel<http://docker.io/ceph/daemon-base:latest-pacific-devel>
-n mon.de1-ceph-m... 25 seconds ago Up 26 seconds
ceph-da9e9837-a3cf-4482-9a13-790a721598cd-mon-de1-ceph-mon-ceph-site-a-1
[root@de1-ceph-mon-ceph-site-a-2 ~]# ceph versions
{
"mon": {
"ceph version 16.2.5-387-g7282d81d
(7282d81d2c500b5b0e929c07971b72444c6ac424) pacific (stable)": 3
},
"mgr": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 3
},
"osd": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 8
},
"mds": {},
"rgw": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 3
},
"overall": {
"ceph version 16.2.5-387-g7282d81d
(7282d81d2c500b5b0e929c07971b72444c6ac424) pacific (stable)": 3,
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 14
}
}
Iain Stott
OpenStack Engineer
iain.st...@thehutgroup.com<mailto:iain.st...@thehutgroup.com>
[THG Ingenuity Logo]<https://www.thg.com<https://www.thg.com>>
[https://i.imgur.com/wbpVRW6.png<https://i.imgur.com/wbpVRW6.png>]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk>>
[https://i.imgur.com/c3040tr.png<https://i.imgur.com/c3040tr.png>]
<https://twitter.com/thgplc?lang=en<https://twitter.com/thgplc?lang=en>>
___
ceph-users mailing list -- ceph-users@ceph.io<mailto:ceph-users@ceph.io>
To unsubscribe send an email to
ceph-users-le...@ceph.io<mailto:ceph-users-le...@ceph.io>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Cephadm adoption - service reconfiguration changes container image
Hi Everyone,
We are looking at migrating all our production clusters from ceph-ansible to
cephadm. We are currently experiencing an issue where when reconfiguring a
service through ceph orch, it will change the running container image for that
service which has led to the mgr services running an earlier version than the
rest of the cluster, this has caused cephadm/ceph orch to not be able to manage
services in the cluster.
Does anyone have any help with this as I cannot find anything in the docs that
would correct this.
Cheers
Iain
[root@de1-ceph-mon-ceph-site-a-1 ~]# cephadm --image quay.io/ceph/ceph:v16.2.9
adopt --style legacy --name mon.$(hostname -s)
[root@de1-ceph-mon-ceph-site-a-1 ~]# cat ./mon.yaml
service_type: mon
service_name: mon
placement:
host_pattern: '*mon*'
extra_container_args:
- -v
- /etc/ceph/ceph.client.admin.keyring:/etc/ceph/ceph.client.admin.keyring
[root@de1-ceph-mon-ceph-site-a-1 ~]# cephadm shell -- ceph config get mgr
mgr/cephadm/container_image_base
quay.io/ceph/ceph
[root@de1-ceph-mon-ceph-site-a-1 ~]# podman ps -a | grep mon
55fe8bc10476 quay.io/ceph/ceph:v16.2.9
-n mgr.de1-ceph-m... 5 minutes ago Up 5 minutes
ceph-da9e9837-a3cf-4482-9a13-790a721598cd-mgr-de1-ceph-mon-ceph-site-a-1
[root@de1-ceph-mon-ceph-site-a-1 ~]# cat ./mon.yaml | cephadm --image
quay.io/ceph/ceph:v16.2.9 shell -- ceph orch apply -i -
Inferring fsid da9e9837-a3cf-4482-9a13-790a721598cd
Scheduled mon update...
[root@de1-ceph-mon-ceph-site-a-1 ~]# podman ps -a | grep mon
ecec1d62c719 docker.io/ceph/daemon-base:latest-pacific-devel
-n mon.de1-ceph-m... 25 seconds ago Up 26 seconds
ceph-da9e9837-a3cf-4482-9a13-790a721598cd-mon-de1-ceph-mon-ceph-site-a-1
[root@de1-ceph-mon-ceph-site-a-2 ~]# ceph versions
{
"mon": {
"ceph version 16.2.5-387-g7282d81d
(7282d81d2c500b5b0e929c07971b72444c6ac424) pacific (stable)": 3
},
"mgr": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 3
},
"osd": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 8
},
"mds": {},
"rgw": {
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 3
},
"overall": {
"ceph version 16.2.5-387-g7282d81d
(7282d81d2c500b5b0e929c07971b72444c6ac424) pacific (stable)": 3,
"ceph version 16.2.9 (4c3647a322c0ff5a1dd2344e039859dcbd28c830) pacific
(stable)": 14
}
}
Iain Stott
OpenStack Engineer
iain.st...@thehutgroup.com
[THG Ingenuity Logo]<https://www.thg.com>
[https://i.imgur.com/wbpVRW6.png]<https://www.linkedin.com/company/thgplc/?originalSubdomain=uk>
[https://i.imgur.com/c3040tr.png] <https://twitter.com/thgplc?lang=en>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
