Not sure what exact issue you have with deploying services (alertmanager in the example). But choosing which service to deploy, how many instances and where should be really easy by using specs: https://docs.ceph.com/en/latest/cephadm/services/ https://docs.ceph.com/en/latest/cephadm/services/monitoring/ In general it's as easy as calling the following command (which will use the default placement):
ceph orch apply my-service
Or use any of the supported placement options: https://docs.ceph.com/en/latest/cephadm/services/#daemon-placement Anyway, in general If you have suggestions for improvements/features I'd recommend opening a ticket on the below tracker providing as much information as possible: https://tracker.ceph.com/projects/orchestrator/issues/new The Cephadm team continuously reviews the list and tries to implement any features that would improve the overall user experience. Best, Redouane. On Fri, Nov 21, 2025 at 9:30 PM Adrian Sevcenco <Adrian.Sevcenco@cern.ch> wrote:
-------- Original Message -------- Subject: [ceph-users] Re: cephadm without containers From: John Mulligan To: ceph-users Date: 11/21/2025, 8:27:43 PM
Hi!
There *are* a lot of options to bootstrap. A quick and dirty grep counts around 47 options that are unique to bootstrap (it didn't count global options). However, environment variables strike me as a bit unwieldy. What would your opinion of a configuration file be instead? Are there benefits to environment variables over a configuration file that I'm overlooking? well, easy of use, and easy knowledge intake. e.g --mon-addrv as env var would be enough to have an hypothetical CEPHENV_MON_ADDRV with the clear information of : put as value the list of host:port monitors split-ed by comma as configuration file: where should be this configuration placed? and with what name? what content format does it have? can it be modular? (to enable configuration by dropped-in files)
So, basically it boils down to the easy knowledge to do something .. i'm struggling to understand what get configured where and the only tip that i found so far is https://docs.ceph.com/en/squid/dev/config-key/#configuration
I did not find so far a template configuration with content explained and with an example format.
i found also https://docs.ceph.com/en/squid/cephadm/services/#service-specification which seems to indicate that for configuration of a service one need to create a temporary yml and then apply it and then https://docs.ceph.com/en/squid/cephadm/services/#retrieving-the-running-serv... show an easy way to get current configuration and then apply it but i'm not sure how can this be used for a client configuration.
2. the second pain point is that the cephadm does not act remotely .. it could be really useful to add a --host argument and to act through ssh on the remote host
The cephadm binary is a bit stretched now (IMO). It acts as both something users are expected to interact with as well as the backend for lower level deployment operations. I think it makes it a bit harder for it to act as a general administration tool.
For now I suggest just sticking to `ssh user@host cephadm ...` and/or tools like ansible to invoke the cephadm version installed on the particular host. i see, got it, i can template something for this ..
For tasks that need just the ceph command, I have a toy (protoype) tool that you might find interesting: https://github.com/ceph/ceph/pull/66061 It allows the use of (the equivalent of) cephadm shell outside of the ceph cluster admin nodes. If I hear people are interested in this, it will motivate me to work on it more :-) Do note that it's so much of a prototype you do have to check out a branch and build it yourself if you want to try it in action, but the PR should describe what it can do sufficiently (I hope). Nice! yeah, it actually check what i felt the need for!!! i will try it out and let you know how it feels or any other feedback Thanks a lot!!
3. documentation : explanation of arguments is missing for example for cephadm deploy --name NAME where NAME should be type.id i get the type which maybe i can get a list, but what is id? an index, number? if it's an index, cannot cephadm enumerate it automatically and just put it? i.e i want to deploy alert mananager that would be the 6th service in cluster, so automatically the name could be alertmanager.6 ?
--config and --config-json can be inferred that they are expecting a filepath but what about --keyring and --key ? some kind of example and structure of names should be shown or linked what content/information is present in the name of the key? is it arbitrary?
Yes there a a lot of help texts that can be improved. Please consider filing individual tracker tickets for these items. Putting them in the tracker makes it easier to find in the future and adding them individually makes it easy for leads to assign them as tasks for Jr devs (good first issue type stuff), for example. tracker tickets mean this? https://github.com/ceph/ceph.io/issues ?
Thanks a lot! Adrian
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io