Re: Argonaut: an open-source terminal UI for Ceph administration
Hi Thomas, Thanks for taking the time to write all that out, it is genuinely useful. Let me deal with the AI thing first since you raised it. I did lean on AI a lot while building this and I want to be clear I was never trying to hide that. I have been open about it elsewhere (I said as much on Reddit) and I am actually working on a blog post about how the whole thing came together, so it's not something I'm shy about. It wasn't "prompt and ship." I acted as the architect and reviewer, I made every design, UX, and safety decision, set the hard constraints (strict separation between UI, logic, and a single isolated Ceph transport; every destructive action confirms and previews the exact ceph command before it runs; version-aware JSON decoding in one place), reviewed the changes, and maybe importantly I myself validated it against real Reef, Squid, and Tentacle clusters (the decoding layer is covered by golden fixtures captured from live clusters), plus a full audit pass before release. On the single commit: that is a fair read and I owe an explanation. The project does have a real, iterative development history, it lives in a private dev repo. The public repo is a clean snapshot because some early commits contained infrastructure credentials I didn't want to publish. I can see how one squashed commit looks like an opaque code-dump. That was absolutely not the intent. And your point about not handing cluster access to a tool you haven't read, I'd do exactly the same :-) It authenticates the same way the ceph CLI does, with your keyring and your permissions, and there is a mock mode (--client mock) that runs on fake in-memory data if you just want to click around without touching a real cluster. About your feedback, which I really appreciate: The connected-clients overview is a great idea! The same goes for a view with the real recovery ETA. The hung-but-still-marked-up OSDs sound nasty! I will have to think about how you'd even detect that reliably. Perhaps you can share that part of your script? Unrelated note, based on other feedback about the name the project is now called Siphon. Repo here: https://github.com/cinpol/siphon Thanks again for the honest feedback :) Cheers, Sinan Op ma 13 jul 2026 om 16:58 schreef Thomas Schneider via ceph-users < ceph-users@ceph.io>:
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@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/ _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hey Sinan, thanks for answering, I appreciate that.
Unrelated note, based on other feedback about the name the project is now called Siphon. Repo here: https://github.com/cinpol/siphon
Great! That will make recommending and searching for it way easier.
The public repo is a clean snapshot because some early commits contained infrastructure credentials I didn't want to publish.
That's too bad. I find it always nice to have a commit history to fall back on, but I understand the fear of leaving credentials/information in when rewriting a source repo. This is why I usually start with a config (outside of the repo) that gets read from the code. Makes it more flexible and no risk of contaminating your history.
It authenticates the same way the ceph CLI does, with your keyring and your permissions, and there is a mock mode (--client mock) that runs on fake in-memory data if you just want to click around without touching a real cluster.
Yeah I actually may have to validate that, but I really didn't want to talk down on your project just voice my concerns. I'm glad you liked my feedback.
The hung-but-still-marked-up OSDs sound nasty! I will have to think about how you'd even detect that reliably. Perhaps you can share that part of your script?
It is, but to be honest I don't like my solution. Got a few solutions that more or less work, but aren't great. Right now I'm basically trying to write data and if it does not respond I restart the OSD and hope it works. Yeah it's not really great. I have a few other solutions I wanted to test, but the problem is so rare that I'm not sure if it's that problem until I try a restart of an OSD. I can't reproduce it and if I know that the problem exists I usually try to fix it ASAP, because a stuck cluster is a bad cluster. If I got a more elegant solution I will write though. Anyway. Thanks for sharing your tool and responding to my feedback. Kind regards, Thomas On 2026-07-13 21:32, Sinan Polat wrote:
Hi Thomas,
Thanks for taking the time to write all that out, it is genuinely useful.
Let me deal with the AI thing first since you raised it. I did lean on AI a lot while building this and I want to be clear I was never trying to hide that. I have been open about it elsewhere (I said as much on Reddit) and I am actually working on a blog post about how the whole thing came together, so it's not something I'm shy about. It wasn't "prompt and ship." I acted as the architect and reviewer, I made every design, UX, and safety decision, set the hard constraints (strict separation between UI, logic, and a single isolated Ceph transport; every destructive action confirms and previews the exact ceph command before it runs; version-aware JSON decoding in one place), reviewed the changes, and maybe importantly I myself validated it against real Reef, Squid, and Tentacle clusters (the decoding layer is covered by golden fixtures captured from live clusters), plus a full audit pass before release.
On the single commit: that is a fair read and I owe an explanation. The project does have a real, iterative development history, it lives in a private dev repo. The public repo is a clean snapshot because some early commits contained infrastructure credentials I didn't want to publish. I can see how one squashed commit looks like an opaque code-dump. That was absolutely not the intent.
And your point about not handing cluster access to a tool you haven't read, I'd do exactly the same :-) It authenticates the same way the ceph CLI does, with your keyring and your permissions, and there is a mock mode (--client mock) that runs on fake in-memory data if you just want to click around without touching a real cluster.
About your feedback, which I really appreciate: The connected-clients overview is a great idea! The same goes for a view with the real recovery ETA. The hung-but-still-marked-up OSDs sound nasty! I will have to think about how you'd even detect that reliably. Perhaps you can share that part of your script?
Unrelated note, based on other feedback about the name the project is now called Siphon. Repo here: https://github.com/cinpol/siphon
Thanks again for the honest feedback :)
Cheers, Sinan
Op ma 13 jul 2026 om 16:58 schreef Thomas Schneider via ceph-users <ceph-users@ceph.io>:
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@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/ _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@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/
participants (2)
-
Sinan Polat
-
Thomas Schneider