- ceph-users - lists.ceph.io

umbrella 21.1.0 RC QE validation status
by Yuri Weinstein 13 Jul '26

13 Jul '26

Details of this release are summarized here: https://tracker.ceph.com/issues/76757 Release Notes - TBD LRC upgrade - TBD *PLEASE ADD YOUR COMMENTS/APPROVALS TO THE TRACKER!* Seeking approvals/reviews for: smoke: Radek, Laura, Nitzan rados: Radek, Laura, Notzan, Afreen, Travis rgw: Adam Emerson fs: Venky orch/ceph-volume: Adam King & Guillaume rbd: Ilya krbd: Ilya nvmeof: PASSED upgrade: Laura, Patrick upgrade-clients:client-upgrade-tentacle-umbrella-umbrella: TBD ( https://github.com/ceph/ceph/pull/69888) upgrade-clients:client-upgrade-squid-umbrella-umbrella: TBD ( https://github.com/ceph/ceph/pull/69887) perf-basic: PASSED crimson-rados: Matan powercycle: Brad TIA

1 1

Re: Argonaut: an open-source terminal UI for Ceph administration
by Sinan Polat 13 Jul '26

13 Jul '26

Thanks for the feedback and good catch on the release history. The name is actually a deliberate nod to Ceph's first stable release. It felt fitting for a tool aimed at Ceph operators to point back to where Ceph started. That said, I take your point about the potential for confusion, I am genuinely open to revisiting it. For now, though, I would like to keep the focus on the tool itself and whether it is actually useful. If you (or anyone on the list) get a chance to try it I would really value feedback on the functionality: which day-to-day operations you want it to handle and anything that feels missing or wrong. Thanks again for taking the time to look. Sinan Op za 11 jul 2026 om 17:58 schreef Eugen Block via ceph-users < ceph-users(a)ceph.io>: > The only comment I have (at the moment) is the naming. Argonaut was > the first stable Ceph release: > > https://docs.ceph.com/en/latest/releases/argonaut/ > > So that might be a bit misleading here, at least in combination with > Ceph. There have been several discussions about naming on this list as > well (for example the Ceph Nautilus release vs. file browser on gnome > desktop). > > Just my 2 cents. > > Zitat von Sinan Polat via ceph-users <ceph-users(a)ceph.io>: > > > Hi everyone, > > > > I have been working on a new open-source project called Argonaut. I would > > love to get feedback from the Ceph community. > > > > Argonaut is a terminal UI for administering Ceph clusters. The > inspiration > > comes from tools like k9s and lazydocker: a keyboard-driven interface for > > common operational tasks while remaining transparent about what is > > happening under the hood. > > > > It is still an early release and I am particularly interested in feedback > > from operators who manage production clusters. > > > > Some questions I would like to ask you: > > - Which operational workflows consume the most time today? > > - Which information do you find difficult to discover quickly? > > - Which features would make a TUI genuinely useful in your daily > workflow? > > > > The project is available here: https://github.com/cinpol/argonaut > > > > Any feedback, feature requests, bug reports, or criticism would be > greatly > > appreciated. > > > > Kind regards > > Sinan Polat > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-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 >

2 2

Re: Argonaut: an open-source terminal UI for Ceph administration
by Thomas Schneider 13 Jul '26

13 Jul '26

Because some users won't trust tools that have limited or no human oversight. Having a repository that is written by "AI" with one single large commit calls into question * the maintainability of the code * the understanding of the author of the code * the longevity of the project * the safety If the software was read only it _could_ be ok, but I would never give a vibe coded piece of software that I didn't read completely access to my cluster. If a human maintains a piece of software I can look at the commit history, understand the design, be reasonable sure to follow the code and could in theory follow the development. LLM code-dumps that span thousands of lines and aren't even completely shown in the github diff view are a nightmare. Oh and I find it intransparent and questionable if someone isn't open about using AI. If a project is transparent about it's usage I'm more willing to give them the benefit of the doubt as if they don't mention it at all. Kind regards, Thomas On 2026-07-13 16:43, Anthony D'Atri wrote: > Why does that matter? > >> On Jul 13, 2026, at 10:41 AM, Thomas Schneider via ceph-users >> <ceph-users(a)ceph.io> wrote: >> Looking at the README and "commit history" this kind of screams vibe >> coded which turns me off from even trying to use it tbh. If you used >> LLMs you should be transparent about it. -- Thomas Schneider IT.SERVICES Wissenschaftliche Informationsversorgung Ruhr-Universität Bochum | 44780 Bochum Telefon: +49 234 32 23939 http://www.it-services.rub.de/

1 0

Re: Argonaut: an open-source terminal UI for Ceph administration
by Thomas Schneider 13 Jul '26

13 Jul '26

> I have been working on a new open-source project called Argonaut. I > would > love to get feedback from the Ceph community. Looking at the README and "commit history" this kind of screams vibe coded which turns me off from even trying to use it tbh. If you used LLMs you should be transparent about it. > Argonaut is a terminal UI for administering Ceph clusters. The > inspiration > comes from tools like k9s and lazydocker: a keyboard-driven interface > for > common operational tasks while remaining transparent about what is > happening under the hood. Sounds great in concept! Especially being transparent about what happens. > Some questions I would like to ask you: > - Which operational workflows consume the most time today? > - Which information do you find difficult to discover quickly? > - Which features would make a TUI genuinely useful in your daily > workflow? Most admins probably have (shell) scripts for most actions so answering is kind of hit or miss. Some actions we have scripts for that take some time. Many of the things listed below are possible/easier over the dashboard. - Listing connected clients RBD, RGW, CephFS, ... every client connected is listed through a different interface. If I quickly want to check who is using what service right now I have to use my scripts. - Actual ETA for rebalance/recovery What it says on the tin. We got a script that checks how many objects need to be moved, are moved per second and depending on the remaining count map it to a curve to guesstimate an ETA - Diagnosing OSD problems This is probably a me problem, but: Sometimes OSDs hang intransparently (they are marked as up, react to status and even are able to be benched, but don't work and block the cluster) would be nice to test them using a tui instead of my script - Bucket usage/User usage by bucket we have automated usage statistics by user/bucket - it's important that the TUI supports different zone/realms Dumping everything to a json file or something like that would be a plus - managing data movement When doing maintenance, adding hosts, replacing OSDs and so on we often manage the data movement using scripts/by hand to minimize data movement. Doing this using a tui would be interesting. - better PG overview This is not something that normally takes up much time, but mostly because we do it seldom. We got a multi site cluster which (without extra patches) limits our usage of the autoscaler (it doesn't work at all without our patches) being able to browse pools by pg_num/size with some usage info Like I said got a heap of tools of my own and am using scripts like https://github.com/TheJJ/ceph-balancer as well. For Ceph newcomers something that would do something like the https://analyzer.clyso.com/ could be neat. Ceph warns you if you do really stupid things, but some tool that tells you if you did slightly stupid things or could optimize your setup could be neat. Anyway most of that should be relatively specific to my cluster and I probably forgot things I do by muscle memory, but I hope I at least gave you some inspiration. If anything what I said is wrong or could be done easily with the tools available I would be glad if someone pointed me in the right direction as well. Kind regards Thomas On 2026-07-11 17:32, Sinan Polat via ceph-users wrote: > Hi everyone, > > I have been working on a new open-source project called Argonaut. I > would > love to get feedback from the Ceph community. > > Argonaut is a terminal UI for administering Ceph clusters. The > inspiration > comes from tools like k9s and lazydocker: a keyboard-driven interface > for > common operational tasks while remaining transparent about what is > happening under the hood. > > It is still an early release and I am particularly interested in > feedback > from operators who manage production clusters. > > Some questions I would like to ask you: > - Which operational workflows consume the most time today? > - Which information do you find difficult to discover quickly? > - Which features would make a TUI genuinely useful in your daily > workflow? > > The project is available here: https://github.com/cinpol/argonaut > > Any feedback, feature requests, bug reports, or criticism would be > greatly > appreciated. > > Kind regards > Sinan Polat > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io -- Thomas Schneider IT.SERVICES Wissenschaftliche Informationsversorgung Ruhr-Universität Bochum | 44780 Bochum Telefon: +49 234 32 23939 http://www.it-services.rub.de/

1 0

Re: Argonaut: an open-source terminal UI for Ceph administration
by Anthony D'Atri 12 Jul '26

12 Jul '26

> The name is actually a deliberate nod to Ceph's first stable release. It > felt fitting for a tool aimed at Ceph operators to point back to where Ceph > started. That said, I take your point about the potential for confusion, I > am genuinely open to revisiting it. IMHO you’re good. There’s one in every crowd. > > For now, though, I would like to keep the focus on the tool itself and > whether it is actually useful. I’m confident someone will find it useful. > If you (or anyone on the list) get a chance > to try it I would really value feedback on the functionality: which > day-to-day operations you want it to handle and anything that feels missing > or wrong. > > Thanks again for taking the time to look. > > Sinan > > Op za 11 jul 2026 om 17:58 schreef Eugen Block via ceph-users < > ceph-users(a)ceph.io>: > >> The only comment I have (at the moment) is the naming. Argonaut was >> the first stable Ceph release: >> >> https://docs.ceph.com/en/latest/releases/argonaut/ >> >> So that might be a bit misleading here, at least in combination with >> Ceph. There have been several discussions about naming on this list as >> well (for example the Ceph Nautilus release vs. file browser on gnome >> desktop). >> >> Just my 2 cents. >> >> Zitat von Sinan Polat via ceph-users <ceph-users(a)ceph.io>: >> >>> Hi everyone, >>> >>> I have been working on a new open-source project called Argonaut. I would >>> love to get feedback from the Ceph community. >>> >>> Argonaut is a terminal UI for administering Ceph clusters. The >> inspiration >>> comes from tools like k9s and lazydocker: a keyboard-driven interface for >>> common operational tasks while remaining transparent about what is >>> happening under the hood. >>> >>> It is still an early release and I am particularly interested in feedback >>> from operators who manage production clusters. >>> >>> Some questions I would like to ask you: >>> - Which operational workflows consume the most time today? >>> - Which information do you find difficult to discover quickly? >>> - Which features would make a TUI genuinely useful in your daily >> workflow? >>> >>> The project is available here: https://github.com/cinpol/argonaut >>> >>> Any feedback, feature requests, bug reports, or criticism would be >> greatly >>> appreciated. >>> >>> Kind regards >>> Sinan Polat >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users(a)ceph.io >>> To unsubscribe send an email to ceph-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 >> > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: autoscale-status -no output
by listy 11 Jul '26

11 Jul '26

MONERO I created, I also removed other two-default classes, manually. I do use, prefer containerized env/lab, with: -> $ cephadm bootstrap ... all the hardware in VMs (Qemu KVM) which ceph use, is virtualized, as opposed to passed-through. In this lab of mine, used are host's LVM volumes utilized by Qemu XML's as: ... <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/cs_whale/ceph'/> ... In guests (hosts for ceph), centos 9, these are as 'virtio_blk': ... [ 1.580490] virtio_blk virtio4: [vdb] 39321600 4096-byte logical blocks (161 GB/150 GiB) ... I get that this is a not a use-case which ceph-devel think of much, if at all. thanks, L.

1 0

Re: Argonaut: an open-source terminal UI for Ceph administration
by Eugen Block 11 Jul '26

11 Jul '26

The only comment I have (at the moment) is the naming. Argonaut was the first stable Ceph release: https://docs.ceph.com/en/latest/releases/argonaut/ So that might be a bit misleading here, at least in combination with Ceph. There have been several discussions about naming on this list as well (for example the Ceph Nautilus release vs. file browser on gnome desktop). Just my 2 cents. Zitat von Sinan Polat via ceph-users <ceph-users(a)ceph.io>: > Hi everyone, > > I have been working on a new open-source project called Argonaut. I would > love to get feedback from the Ceph community. > > Argonaut is a terminal UI for administering Ceph clusters. The inspiration > comes from tools like k9s and lazydocker: a keyboard-driven interface for > common operational tasks while remaining transparent about what is > happening under the hood. > > It is still an early release and I am particularly interested in feedback > from operators who manage production clusters. > > Some questions I would like to ask you: > - Which operational workflows consume the most time today? > - Which information do you find difficult to discover quickly? > - Which features would make a TUI genuinely useful in your daily workflow? > > The project is available here: https://github.com/cinpol/argonaut > > Any feedback, feature requests, bug reports, or criticism would be greatly > appreciated. > > Kind regards > Sinan Polat > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: autoscale-status -no output
by Anthony D'Atri 11 Jul '26

11 Jul '26

> > Deployment process did create both _hdd_ & _ssd_ classes. > I've read somewhere in docs that device classes are more of a concept rather than a real thing Hmm. I've written that the *names* are arbitrary, so one can assign different ones, but it's best to only do that if you have a specific reason. Say you have NVMe SSDs, SATA SSDs, and SATA HDDs, and enough of each that you want to constrain which pool goes on which. By default, without anything exotic, the HDDs will be reported by the kernel as rotational, so OSDs on them will get the device class "hdd". The SATA and NVMe SSDs will be reported by the kernel as nonrotational, so they will get the device class "ssd". With both, one might, for example wish to place pools: * CephFS .meta : NVMe SSDs * CephFS first .data: SATA SSDs * CephFS additional .data pools: HDDs In that case one might assign the NVMe SSDs a CRUSH device class of "nvme" and define a CRUSH rule that only uses those. In a cluster with mixed media, one almost never wants a given pool to use more than one, like you wouldn't want a CephFS .meta pool on both HDDs and SSDs, or the data pools eating the SSD capacity. > - which would confirm since my cluster is a lab, all in virtual env, all storage devices/drives all the same "type" and yet these two classes were auto-created (and used by default if I remember, at osd-creation time) How is your cluster deployed? Something would have to go out of its way to create a device class called MONERO. I suspect that you might have misinterpreted a configuration item. Virtual storage devices as seen by Ceph may be classed differently than one would want, usually as non-rotational when there are SSDs behind the abstraction. This does matter in some ways, as some configuration options have _hdd and _ssd variants that are used depending on the rotational attribute. In such cases a udev rule can coerce what you want. Are you using Proxmox or Rook or something to deploy? > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Argonaut: an open-source terminal UI for Ceph administration
by Sinan Polat 11 Jul '26

11 Jul '26

Hi everyone, I have been working on a new open-source project called Argonaut. I would love to get feedback from the Ceph community. Argonaut is a terminal UI for administering Ceph clusters. The inspiration comes from tools like k9s and lazydocker: a keyboard-driven interface for common operational tasks while remaining transparent about what is happening under the hood. It is still an early release and I am particularly interested in feedback from operators who manage production clusters. Some questions I would like to ask you: - Which operational workflows consume the most time today? - Which information do you find difficult to discover quickly? - Which features would make a TUI genuinely useful in your daily workflow? The project is available here: https://github.com/cinpol/argonaut Any feedback, feature requests, bug reports, or criticism would be greatly appreciated. Kind regards Sinan Polat

1 0

Re: autoscale-status -no output
by Anthony D'Atri 11 Jul '26

11 Jul '26

.mgr will always have a single PG. If for some reason that PG wasn't placed on any OSDs, you'd have a bigger problem. > On Jul 11, 2026, at 11:14 AM, listy via ceph-users <ceph-users(a)ceph.io> wrote: > > Yes, changing: > > -> $ ceph osd pool set .mgr crush_rule replicated_rule_MONERO > > fixes: > > -> $ ceph osd pool autoscale-status > > What was (not)happening there? _.mgr_ had no OSDs assigned, if so how did it work, showing no errors (which I could spot)? You had a situation that was more complex than the PG autoscaler is equipped to deal with. Like I said, I have an RFE in to prevent this kind of thing. > > thanks, L. > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0