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
<[email protected]>:
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
<[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
--
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 -- [email protected]
To unsubscribe send an email to [email protected]
