As Eugen has noted, cephadm/containers were already available in Octopus. In fact, thanks to the somewhat scrambled nature of the documents, I had a mix of both containerized and legacy OSDs under Octopus and for the most part had no issues attributable to that. My bigger problem with Octopus was that the deployment scheduler would hang if the system wasn't totally healthy. Pacific is much more tolerant, so life got a lot easier when I moved up. I am a major fan of containers. I have most of my production services in-house containerized at this point. I never really felt comfortable with dumping a heterogeneous mish-mash of critical apps on a single machine even with the package manager riding herd on them. VMs were better, but hungry. Containers are very lightweight and many of the Ceph containers are running different service off a common base image which makes them even lighter. The biggest argument I've heard against containers is security, but I don't think that Ceph requires any of the elevated security options that have proven problematic. The real reason why I think many resist containers is that they don't understand how they work. They are a different sort of world, but not that complicated really. Especially since Ceph's internal administration handles most of it. One difference you will see between administered (containerised) and legacy Ceph resources is that the administered stuff supports more than one FSID per host. The downside of that is that instead of saying "sysadmin restart osd.4", you have to include the entire fsid in your control commands. For example "sysadmin restart ceph-2993cd86-0551-01ee-aadf-8bc5c3286cf8f-osd-4". This also shows up in the /var/lib/ceph directory, which now has a subdirectory for each fsid. There is a simple way to convert a legacy ceph OSD to an administered one (it's in the docs). Sometime the process with jam, especially if things aren't as clean as they ought to be, but I think we've reached the point where if you ask on the list, we can clear that. Hope that helps, Tim On 4/1/25 16:40, Eugen Block wrote:
Hi,
first of all, the Ceph docs are "official", here's the relevant section for upgrading Ceph:
https://docs.ceph.com/en/latest/cephadm/upgrade/
Octopus was the first version using the orchestrator, not Pacific. So you could adopt your cluster to cephadm in your current version already:
https://docs.ceph.com/en/octopus/cephadm/adoption/
There are many people on this list (and probably off list, too) who don't really like the orchestrator, or don't like containers etc. It will require some time to get used to it, but I find the benefits worth it. One of them being able to upgrade your cluster without touching the host OS. I would recommend to get some practice in a lab cluster and familiarize yourself with cephadm before practicing on a production environment. ;-)
One of the questions that arise is whether the clients (depending on the OpenStack version) in Octopus and the mons, mrgs, osds, mds etc. etc. in Pacific/Quincy will function correctly.
Note that Quincy is already EOL, you could go from Pacific to Reef directly (18.2.5 will be released soon). You could also go from Octopus to Quincy and then Squid, all those upgrade paths are safe and supported. Your OpenStack clients should also work fine with a newer Ceph cluster, just recently I upgraded a customer Ceph cluster to Reef while their OpenStack clients are still on Octopus, and there haven't been any complaints yet.
Hope this helps! Eugen
Zitat von Iban Cabrillo <cabrillo@ifca.unican.es>:
Dear cephers,
We intend to begin the migration of our Ceph cluster from Octopus to Pacific and subsequently to Quincy. I have seen that from Pacific onwards, it is possible to automate installations with cephadm.
One of the questions that arise is whether the clients (depending on the OpenStack version) in Octopus and the mons, mrgs, osds, mds etc. etc. in Pacific/Quincy will function correctly.
The second is whether it is feasible, advisable to switch to cephadm/orch, since I have always performed updates manually for many, many years.
And the third, if there is any 'official' guide available for these updates. Thanks in advance, I
--
================================================================ Ibán Cabrillo Bartolomé Instituto de Física de Cantabria (IFCA-CSIC) Santander, Spain Tel: +34942200969/+34669930421 Responsible for advanced computing service (RSC) =========================================================================================
=========================================================================================
All our suppliers must know and accept IFCA policy available at:
https://confluence.ifca.es/display/IC/Information+Security+Policy+for+Extern...
==========================================================================================
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io