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 <[email protected]> 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-service-specification > 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 -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
