On Friday, November 21, 2025 11:01:36 AM Eastern Standard Time Adrian Sevcenco wrote: > Thank you so much everyone for helping me view and understand the bigger > picture. I do realize (or did realize) that the container model AND > cephadm have a goal to both isolate and remove any kind of middle layer > between developers (or developing party) and any other build > process/repository, system dependencies or other 3rd party tools used for > configuration (as ansible is) > This create a short circuit from developers to end users which of course > increase stability through fast response and independence of underlying > environment .. > So, understanding this, now i can ask about potential improvements to > cephadm .. > 1. first of my pain problem is the assumption of lacking of ssh > communication between hosts. while there is --skip-ssh for bootstrap, it > would be so much easier if there could be some environment variables that > could steer and configure the behavior of the whole cluster without having > to remember what i choose for the cluster. > it would be really useful if all bootstrap options could be automatically > read from CEPHENV_<name of option without -- and s/-/_/> > so i.e. --skip-ssh would firstly be read/checked for as CEPHENV_skip_ssh > this would allow to automatically "seed" the main parameters of cluster to > all involved nodes with something like ansible :) > > there are some other global options that are usually managed by other tools > and have nothing to do with cephadm like --skip-firewalld
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? > > 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. 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). > 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. _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
