- ceph-users - lists.ceph.io

resize underlying volume - disk size increase ?
by lejeczek 15 Jan '26

15 Jan '26

Hi guys. I do not suppose this happens in often - it's a lab in my case - when disks sizes, which Ceph uses increase. Is there a procedure - or howto/method if such thing is not approved/recommended - to have Ceph make use of such added disk space? many thanks, L.

1 0

Re: Dual stack support in squid?
by Adam Prycki 15 Jan '26

15 Jan '26

Hello, ceph doesn't support dual-stack networking. Cluster components bind to either v4 or v6 address. It's the same with multiple subnets. You can have multiple subnets configured in your cluster, but each component binds only to one of these subnets. > - How does the mon process decide which address to use? Lookup ms_bind_ipv4 and ms_bind_ipv6. (these options are exclusive, as I mentioned above) Best regerds Adam Prycki On 15/01/2026 14:10, Burkhard Linke via ceph-users wrote: > Hi, > > > we are currently migrating our ipv4 infrastructure to ipv6, and maybe > later to ipv6 only. This also include our ceph clusters. > > My naive approach this is: > > 1. add a forth (ipv4) mon as safe guard and remove an existing mon > > 2. set ms_bind_ipv6 to true and add ipv6 networks to public_network > (both in ceph.conf and via ceph config) > > 3. manually re-add the removed mon with current map and key > > 4. repeat with other mons and afterwards restart osds and other services > to bind to ipv6, too > > > The re-added mon in step 3 does not bind to ipv6, only to ipv4. (both > port 3300 and 6789). According to the `ceph tell mon.XYZ config show` > output both the ms_bind_ipv6 and the public_network settings are > recognized by the process. > > > So the questions are: > > - Is dual stack supported for mons? The documentation does not mention > it explicitly... > > - Can a mon bind to multiple addresses at all, e.g. one IPv4 and one IPv6? > > - How does the mon process decide which address to use? > > > Best regards, > > Burkhard > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Dual stack support in squid?
by Burkhard Linke 15 Jan '26

15 Jan '26

Hi, we are currently migrating our ipv4 infrastructure to ipv6, and maybe later to ipv6 only. This also include our ceph clusters. My naive approach this is: 1. add a forth (ipv4) mon as safe guard and remove an existing mon 2. set ms_bind_ipv6 to true and add ipv6 networks to public_network (both in ceph.conf and via ceph config) 3. manually re-add the removed mon with current map and key 4. repeat with other mons and afterwards restart osds and other services to bind to ipv6, too The re-added mon in step 3 does not bind to ipv6, only to ipv4. (both port 3300 and 6789). According to the `ceph tell mon.XYZ config show` output both the ms_bind_ipv6 and the public_network settings are recognized by the process. So the questions are: - Is dual stack supported for mons? The documentation does not mention it explicitly... - Can a mon bind to multiple addresses at all, e.g. one IPv4 and one IPv6? - How does the mon process decide which address to use? Best regards, Burkhard

1 0

Re: Huge (and increasing) list of removed_snaps
by Eugen Block 15 Jan '26

15 Jan '26

Hi, do you maybe have some history about snapshot usage etc? Did someone create a pool snapshot on rados level (which would make those unmanaged snaps) but isn't allow to delete it? At least that's what I interpret here [0]: if (!is_unmanaged_snap_op_permitted(cct, mon->key_server, session->entity_name, session->caps, session->get_peer_socket_addr(), pool_name)) { dout(0) << "got unmanaged-snap pool op from entity with insufficient " << "privileges. message: " << *m << std::endl << "caps: " << session->caps << dendl; _pool_op_reply(op, -EPERM, osdmap.get_epoch()); return true; } And reading that, is your log excerpt missing some more output? If you have, please add more details. Anyway, I expect the log to contain the entity's name and the relevant caps. Those could help to understand better what exactly is going on here. Regards, Eugen [0] https://github.com/ceph/ceph/blob/v14.2.22/src/mon/OSDMonitor.cc#L13017 Zitat von Work Ceph via ceph-users <ceph-users(a)ceph.io>: > Hello guys, > > We are using Ceph Nautilus, and we are facing an unexpected situation. We > see a huge list of removed_snaps, and they do not seem to be cleaned. We > also see increasing use of CPUs in Ceph monitors (we have thousands of > these elements). However, we are not sure if this situation is related. > > In the logs, we noticed the following message, which seems to be related to > this situation: > > ``` > got unmanaged-snap pool op from entity with insufficient privileges. > message: pool_op > ``` > > Has anyone faced similar situations with Ceph and RBD snapshots management? > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: Cannot adopt osd (on squid)
by Eugen Block 15 Jan '26

15 Jan '26

Since SUSE is building Ceph packages again, I tested the adoption of a Squid package based test cluster (no data in it), and it worked like a charm. Of course, the MDS container image part came up again, that should definitely be in the docs to override the default before creating MDS containers. I'm gonna file a tracker for that. Zitat von Chris Palmer via ceph-users <ceph-users(a)ceph.io>: > I have a squid package-installed test cluster that I am trying to > adopt into cephadm. > > Monitors & managers have been adopted, and the orchestrator is functioning. > > When I try to adopt an OSD though (e.g. osd.0), cephadm creates the > new directory (<fsid>/osd.0) and populates the files from the legacy > directory. It then crashes complaining that the directory osd/ceph-0 > is not empty so cannot be removed. In some cases none of the files > have been removed, and in others the block symlink and > require_osd_release file remain. I can remove the new <fsid>/osd.0 > and use ceph-volume to activate the OSD again. > > cephadm.log reports that every file has been moved and the ownership > set - even for files that still remain in the legacy directory. It > doesn't report any other errors (apart from the directory not empty > error. when it crashes). > > I really can't find where to go from here. Any pointers appreciated... > > Thanks, Chris > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Huge (and increasing) list of removed_snaps
by Work Ceph 14 Jan '26

14 Jan '26

Hello guys, We are using Ceph Nautilus, and we are facing an unexpected situation. We see a huge list of removed_snaps, and they do not seem to be cleaned. We also see increasing use of CPUs in Ceph monitors (we have thousands of these elements). However, we are not sure if this situation is related. In the logs, we noticed the following message, which seems to be related to this situation: ``` got unmanaged-snap pool op from entity with insufficient privileges. message: pool_op ``` Has anyone faced similar situations with Ceph and RBD snapshots management?

1 0

Re: Downgrading from Tentacle to Squid
by Redouane Kachach 14 Jan '26

14 Jan '26

Hi Michael, Unfortunately downgrade is not supported between two Ceph major releases. You will need to re-install the old release. Best, Redouane. On Tue, Jan 13, 2026 at 3:48 PM Michael Worsham via ceph-users < ceph-users(a)ceph.io> wrote: > Currently in a test-lab / sandbox environment, I am running the latest > version of Ceph Tentacle release (v20.2.0) in a virtualized environment. If > I wanted to downgrade back to Squid (v19.2.3), what steps would I go about > doing that? I am not worried about any of the data in the environment as > its strictly for testing purposes, patch assessment for OS and Ceph, etc. > > ubuntu@ceph-mon1:~$ sudo ceph versions > { > "mon": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 2 > }, > "mgr": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 2 > }, > "osd": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 3 > }, > "mds": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 1 > }, > "rgw": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 2 > }, > "overall": { > "ceph version 20.2.0 (69f84cc2651aa259a15bc192ddaabd3baba07489) > tentacle (stable - RelWithDebInfo)": 10 > } > } > > Environment is running Ubuntu v22.04 and Ceph was deployed via cephadm. > > -- Michael > > This message and its attachments are from Data Dimensions and are intended > only for the use of the individual or entity to which it is addressed, and > may contain information that is privileged, confidential, and exempt from > disclosure under applicable law. If the reader of this message is not the > intended recipient, or the employee or agent responsible for delivering the > message to the intended recipient, you are hereby notified that any > dissemination, distribution, or copying of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately and permanently delete the original email and > destroy any copies or printouts of this email as well as any attachments. > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >

1 0

Ceph Tech Talks 2026
by Anthony Middleton 13 Jan '26

13 Jan '26

Hey Ceph Friends, Exciting news for tomorrow:* Ceph Tech Talks are happening*! Be sure not to miss our very first session of 2026: “*Running Teuthology Outside of the Sepia Lab*” with the wonderful Deepshikha Singh. *Join us on Jan 14, 2026, at 8:30 am PDT* via Jitsi (virtual) at https://meet.jit.si/ceph-tech-talks. And don’t worry if you can’t make it live, the session will be recorded and shared on YouTube! See you tomorrow. -- Anthony Middleton Community Manager, Ceph Foundation community-manager(a)ceph.io LinkedIn <https://www.linkedin.com/company/ceph>| BlueSky <https://bsky.app/profile/ceph.io> | Twitter <https://x.com/Ceph>

1 0

Re: Advice on managing adopted OSDs
by Chris Palmer 13 Jan '26

13 Jan '26

Ok, that was the conclusion that I was starting to come to. Thanks so much for the notes - I'll have a careful look through them. I found this note in Service Management\Declarative State that reinforces that... /The “osd” service used to track OSDs that are not tied to any specific service spec is special and will always be marked unmanaged. Attempting to modify it with |ceph orch set-unmanaged| or |ceph orch set-managed| will result in a message |No service of name osd found. Check "ceph orch ls" for all known services|/ I also found a note in OSD Service\Creating New OSDs... /When deploying new OSDs with |cephadm|, ensure that the |ceph-osd| package is not already installed on the target host. If it is installed, conflicts may arise in the management and control of the OSD that may lead to errors or unexpected behavior./ ...so will remove all the packages first (except cephadm). It would be useful to have some definitive statements about managing OSDs in the Converting an existing cluster to cephadm doc, other than just the initial OSD adoption itself. Regards, Chris On 13/01/2026 17:45, Julien Laurenceau via ceph-users wrote: > Hello, > > To my knowledge there is no “adopt” or in-place migration procedure in > Squid. > > You must remove and redeploy OSDs to bring them under management. > > Migration Steps: > a. Identify unmanaged OSDs > ``` > ceph orch ls --service-type osd > ceph orch ps --daemon-type osd > ``` > or > ``` > ceph osd tree > # easy way to retrieve the device used by a specific osd : > ceph device ls > # ceph device ls |grep -v nvme | awk -F '.' '{print $NF}' | sort -n > ceph osd metadata ${osdid} |grep -e '"hostname"' -e '"devices"' > > listosd=$(ceph device ls |grep $h |grep osd | awk -F '.' '{print $NF}' > | awk '{print $1}'| sort -n) > osd_devices=$(ceph device ls |grep $h |grep osd | awk -F "${h}:" > '{print $NF}' | awk '{print $1}'| sort -n) > for osdid in ${listosd}; do ceph osd metadata ${osdid} |grep -e > '"hostname"' -e '"devices"'; done > ``` > b. Mark OSDs out and wait for healthy > ``` > ceph osd out ${osdid} > for osdid in ${listosd}; do ceph osd out ${osdid}; done > # Wait for until no object degraded and no Reduced data availability > ``` > Wait until there are no degraded objects. > c. Mark the OSD as “down” > ``` > ceph osd down ${osdid} > for osdid in ${listosd}; do ceph osd down ${osdid}; done > ``` > d. Stop the OSD daemon on the host > On the host where the OSD runs, stop the OSD service: > ``` > systemctl list-units --no-legend --no-pager "ceph-*(a)osd.*" > systemctl stop ceph-${clusterid}(a)osd.${osdid} > for osdid in ${listosd}; do systemctl stop > ceph-${clusterid}(a)osd.${osdid}; done > ``` > e. Remove the OSD > ``` > ceph osd purge ${osdid} --yes-i-really-mean-it > ceph orch daemon rm osd.$osdid --force > for osdid in ${listosd}; do ceph osd purge ${osdid} > --yes-i-really-mean-it; done > for osdid in ${listosd}; do ceph orch daemon rm osd.$osdid --force; done > ``` > f. Clean the device on the host > ``` > # osd_devices="nvme0n1 nvme1n1 nvme2n1 nvme3n1 nvme4n1 nvme5n1 nvme6n1 > nvme7n1" > # osd_devices="sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn > sdo sdp sdq sdr sds sdt sdu sdv sdw sdx" > ceph-volume lvm zap /dev/sdX --destroy > # or > sgdisk --zap-all /dev/sdX > for d in ${osd_devices}; do sgdisk --zap-all /dev/${d}; done > > if zap it is not sufficient NUKE THE DRIVE : > for dm in $(dmsetup ls | grep '^ceph--' | awk '{print $1}'); do > dmsetup remove ${dm}; done > for vg in $(vgdisplay -s | grep '"ceph-' |awk '{print $1}' | tr -d > '"') ; do vgremove --force $vg; done > for d in ${osd_devices}; do echo "nuke $d"; pvremove /dev/${d}; > wipefs -af /dev/${d}; sfdisk --delete /dev/${d}; partprobe /dev/${d}; > done > ``` > g. Create and apply a DriveGroup YAML for the host/device > > (see section above) > ``` > cat << EOF >ceph-osd-$h.yaml > service_type: osd > service_id: osd-${h} > placement: > hosts: > - ${h} > data_devices: > paths: > EOF > for dev in $(echo ${osd_devices} | tr -s ',' ' '); do > echo " - /dev/${dev}" >> ceph-osd-$h.yaml > done > ceph orch apply -i ceph-osd-${h}.yaml > ceph orch ls --service-type osd > # ceph orch rm osd.osd-$h > > # apply device-class if needed : > mydevclass=nvme-all > listosd=$(ceph device ls |grep $h |grep osd | awk -F '.' '{print $NF}' > | awk '{print $1}'| sort -n) > for osdid in ${listosd}; do ceph osd crush set-device-class > ${mydevclass} ${osdid}; done > ``` > > h. Verify > ``` > ceph orch ps --daemon-type osd > ceph osd tree > ceph -s > ``` > > > On 1/13/26 17:00, Kirby Haze via ceph-users wrote: >> There should be a >> `orch set-managed` and `orch set-unmanaged` >> so doing `ceph orch set-managed osd` should work, then it should >> reflect in >> the yaml shortly after. >> >> - Kirby >> >> On Tue, Jan 13, 2026 at 1:24 AM Chris Palmer via ceph-users < >> ceph-users(a)ceph.io> wrote: >> >>> I would appreciate advice on the "best" way to manage adopted OSDs. >>> >>> This is a test squid 19.2.3 cluster, originally installed using >>> centos 9 >>> packages. I am testing the procedure for adopting, then will use >>> cephadm >>> to update to tentacle. Once I am happy with the whole process I will >>> repeat on a small production cluster. >>> >>> I have successfully adopted mon, mgr, osd, rgw & mds as described in >>> the >>> docs. That left rgw & mds managed, but mon, mgr & osds unmanaged. >>> Setting the mon & mgr services managed was easy by tweaking the yml and >>> applying. But I am unclear how to best handle osds. That leaves me in >>> this state: >>> >>> [root@c4 ~]# ceph orch ls >>> NAME PORTS RUNNING REFRESHED AGE PLACEMENT >>> mds.cephfs 2/2 51s ago 21h c1;c2 >>> mgr 3/3 52s ago 21h c1;c2;c4 >>> mon 3/3 51s ago 21h c1;c2;c3 >>> osd 12 51s ago - <unmanaged> >>> rgw.rgw ?:80 2/2 51s ago 21h c1;c2 >>> >>> >>> The exported yml had the following for osds, which had to be commented >>> out as it would not parse (missing placement, missing data_devices >>> etc): >>> >>> service_type: osd >>> service_name: osd >>> unmanaged: true >>> spec: >>> filter_logic: AND >>> objectstore: bluestore >>> >>> >>> My questions are: >>> >>> * With the OSDs unmanaged, what functionality am I missing? In >>> particular, things like using cephadm to replace a failed disk... >>> * These are only small clusters, so I am happy to have the OSDs >>> enumerated in the yml, and not have ceph try to find and >>> automatically use available disks. Is it possible to have the full >>> functionality except from automatically grabbing available disks? >>> * How can I generate yml that reflects the current state of the >>> OSDs? >>> We currently have pools (per application) for NVMe, SSD, and HDD >>> with shared NVMe DB/WAL. >>> * I can't find documentation for transitioning OSDs from >>> unmanaged to >>> managed. Have I just overlooked it? >>> * Is any part of this easier on tentacle than squid? If so I can >>> upgrade the package squid to tentacle before adopting. (But unless >>> there is a good reason, I would rather have familiarised myself >>> with >>> the cephadm upgrade process before starting any of this on the >>> production cluster...) >>> >>> Many thanks for any insights. >>> >>> Chris >>> _______________________________________________ >>> ceph-users mailing list --ceph-users(a)ceph.io >>> To unsubscribe send an email toceph-users-leave(a)ceph.io >>> >> _______________________________________________ >> ceph-users mailing list --ceph-users(a)ceph.io >> To unsubscribe send an email toceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: Advice on managing adopted OSDs
by Julien Laurenceau 13 Jan '26

13 Jan '26

Hello, To my knowledge there is no “adopt” or in-place migration procedure in Squid. You must remove and redeploy OSDs to bring them under management. Migration Steps: a. Identify unmanaged OSDs ``` ceph orch ls --service-type osd ceph orch ps --daemon-type osd ``` or ``` ceph osd tree # easy way to retrieve the device used by a specific osd : ceph device ls # ceph device ls |grep -v nvme | awk -F '.' '{print $NF}' | sort -n ceph osd metadata ${osdid} |grep -e '"hostname"' -e '"devices"' listosd=$(ceph device ls |grep $h |grep osd | awk -F '.' '{print $NF}' | awk '{print $1}'| sort -n) osd_devices=$(ceph device ls |grep $h |grep osd | awk -F "${h}:" '{print $NF}' | awk '{print $1}'| sort -n) for osdid in ${listosd}; do ceph osd metadata ${osdid} |grep -e '"hostname"' -e '"devices"'; done ``` b. Mark OSDs out and wait for healthy ``` ceph osd out ${osdid} for osdid in ${listosd}; do ceph osd out ${osdid}; done # Wait for until no object degraded and no Reduced data availability ``` Wait until there are no degraded objects. c. Mark the OSD as “down” ``` ceph osd down ${osdid} for osdid in ${listosd}; do ceph osd down ${osdid}; done ``` d. Stop the OSD daemon on the host On the host where the OSD runs, stop the OSD service: ``` systemctl list-units --no-legend --no-pager "ceph-*(a)osd.*" systemctl stop ceph-${clusterid}(a)osd.${osdid} for osdid in ${listosd}; do systemctl stop ceph-${clusterid}(a)osd.${osdid}; done ``` e. Remove the OSD ``` ceph osd purge ${osdid} --yes-i-really-mean-it ceph orch daemon rm osd.$osdid --force for osdid in ${listosd}; do ceph osd purge ${osdid} --yes-i-really-mean-it; done for osdid in ${listosd}; do ceph orch daemon rm osd.$osdid --force; done ``` f. Clean the device on the host ``` # osd_devices="nvme0n1 nvme1n1 nvme2n1 nvme3n1 nvme4n1 nvme5n1 nvme6n1 nvme7n1" # osd_devices="sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn sdo sdp sdq sdr sds sdt sdu sdv sdw sdx" ceph-volume lvm zap /dev/sdX --destroy # or sgdisk --zap-all /dev/sdX for d in ${osd_devices}; do sgdisk --zap-all /dev/${d}; done if zap it is not sufficient NUKE THE DRIVE : for dm in $(dmsetup ls | grep '^ceph--' | awk '{print $1}'); do dmsetup remove ${dm}; done for vg in $(vgdisplay -s | grep '"ceph-' |awk '{print $1}' | tr -d '"') ; do vgremove --force $vg; done for d in ${osd_devices}; do echo "nuke $d"; pvremove /dev/${d}; wipefs -af /dev/${d}; sfdisk --delete /dev/${d}; partprobe /dev/${d}; done ``` g. Create and apply a DriveGroup YAML for the host/device (see section above) ``` cat << EOF >ceph-osd-$h.yaml service_type: osd service_id: osd-${h} placement: hosts: - ${h} data_devices: paths: EOF for dev in $(echo ${osd_devices} | tr -s ',' ' '); do echo " - /dev/${dev}" >> ceph-osd-$h.yaml done ceph orch apply -i ceph-osd-${h}.yaml ceph orch ls --service-type osd # ceph orch rm osd.osd-$h # apply device-class if needed : mydevclass=nvme-all listosd=$(ceph device ls |grep $h |grep osd | awk -F '.' '{print $NF}' | awk '{print $1}'| sort -n) for osdid in ${listosd}; do ceph osd crush set-device-class ${mydevclass} ${osdid}; done ``` h. Verify ``` ceph orch ps --daemon-type osd ceph osd tree ceph -s ``` On 1/13/26 17:00, Kirby Haze via ceph-users wrote: > There should be a > `orch set-managed` and `orch set-unmanaged` > so doing `ceph orch set-managed osd` should work, then it should reflect in > the yaml shortly after. > > - Kirby > > On Tue, Jan 13, 2026 at 1:24 AM Chris Palmer via ceph-users < > ceph-users(a)ceph.io> wrote: > >> I would appreciate advice on the "best" way to manage adopted OSDs. >> >> This is a test squid 19.2.3 cluster, originally installed using centos 9 >> packages. I am testing the procedure for adopting, then will use cephadm >> to update to tentacle. Once I am happy with the whole process I will >> repeat on a small production cluster. >> >> I have successfully adopted mon, mgr, osd, rgw & mds as described in the >> docs. That left rgw & mds managed, but mon, mgr & osds unmanaged. >> Setting the mon & mgr services managed was easy by tweaking the yml and >> applying. But I am unclear how to best handle osds. That leaves me in >> this state: >> >> [root@c4 ~]# ceph orch ls >> NAME PORTS RUNNING REFRESHED AGE PLACEMENT >> mds.cephfs 2/2 51s ago 21h c1;c2 >> mgr 3/3 52s ago 21h c1;c2;c4 >> mon 3/3 51s ago 21h c1;c2;c3 >> osd 12 51s ago - <unmanaged> >> rgw.rgw ?:80 2/2 51s ago 21h c1;c2 >> >> >> The exported yml had the following for osds, which had to be commented >> out as it would not parse (missing placement, missing data_devices etc): >> >> service_type: osd >> service_name: osd >> unmanaged: true >> spec: >> filter_logic: AND >> objectstore: bluestore >> >> >> My questions are: >> >> * With the OSDs unmanaged, what functionality am I missing? In >> particular, things like using cephadm to replace a failed disk... >> * These are only small clusters, so I am happy to have the OSDs >> enumerated in the yml, and not have ceph try to find and >> automatically use available disks. Is it possible to have the full >> functionality except from automatically grabbing available disks? >> * How can I generate yml that reflects the current state of the OSDs? >> We currently have pools (per application) for NVMe, SSD, and HDD >> with shared NVMe DB/WAL. >> * I can't find documentation for transitioning OSDs from unmanaged to >> managed. Have I just overlooked it? >> * Is any part of this easier on tentacle than squid? If so I can >> upgrade the package squid to tentacle before adopting. (But unless >> there is a good reason, I would rather have familiarised myself with >> the cephadm upgrade process before starting any of this on the >> production cluster...) >> >> Many thanks for any insights. >> >> Chris >> _______________________________________________ >> ceph-users mailing list --ceph-users(a)ceph.io >> To unsubscribe send an email toceph-users-leave(a)ceph.io >> > _______________________________________________ > ceph-users mailing list --ceph-users(a)ceph.io > To unsubscribe send an email toceph-users-leave(a)ceph.io

1 0