Quick comment on the CLI argos vs. the spec file. It actually shouldn't allow you to do both for any flags that actually affect the service. If you run `ceph orch apply -i <filepath>` it will only make use of the spec file and should return an error if flags that affect the service like `--unamanged` or `--placement` are passed. Separately, there are a number of `ceph orch apply <service-name>` commands e.g. `ceph orch apply nfs` that will return an error if a spec file is passed in. The only exception off the top of my head is `ceph orch apply osd` which will force you to either pass a spec file or pass `--all-available-devices`. If anything else does let you pass in relevant CLI args and a spec file at the same time it's likely an oversight / bug. As for the osd service, it is correct that the service just called "osd" is not a real service / a placeholder for OSDs that don't have a service. In later releases it will actually block you from creating a service with service_type: osd service_name: osd so that that placeholder isn't attached to an actual spec file. Since that's already happened, what I'd personally recommend is re-applying that spec file but without the `service_name` field and instead adding something like `service_id: foo`. That would create an osd.foo service. For the time being, given nothing else in the spec was modified, it won't have any OSDs on it as the only matching device has already been made part of an OSD. To get that OSD to fall under that service, you can go onto the `ceph01` node directly, and edit the "service_name" field of the /var/lib/ceph/<fsid>/osd.<osd-id>/unit.meta file to be "osd.foo" or whatever name you pick, then run `ceph orch ps --refresh`, wait a bit and it should appear under `osd.foo` rather than the "osd" service. Then you can just do `ceph orch rm osd` to delete the old spec file that became attached to the "osd" service. In the future there are also plans to add a `ceph orch` command to change the OSD spec affinity so you don't need to do the extra steps, as well as probably allowing service actions against the "osd" service (even though it's just a placeholder in reality) but none of that exists currently. On Wed, Nov 6, 2024 at 11:50 AM Tim Holloway <timh@mousetech.com> wrote:
On 11/6/24 11:04, Frédéric Nass wrote:
... You could enumerate all hosts one by one or use a pattern like 'ceph0[1-2]'
You may also use regex patterns depending on the version of Ceph that you're using. Check [1]. Regex patterns should be available in next minor Quincy release 17.2.8.
[1] https://github.com/ceph/ceph/pull/53803 [2] https://github.com/ceph/ceph/pull/56222
This simple wildcard scheme is called "globbing" and it's what is typically used by Unix-style command shells.
It's convenient, but limited. For more subtlety you'd need a regex.
More generally, is there a higher level document that talks about Ceph spec files and the orchestrator - something that deals with the general concepts?
I've submitted an outline on the issue tracker for a comprehensive and coherent document on the creation and maintenance of OSDs.
Spec files, as I mentioned earlier, are YAML-format declarations of the specifications to be applied to create or update one or more resources. You can define spec files not only for OSDs, but for other Ceph resources as well and I *think* a unified spec file for multiple resource types.
By convention, any orchestrator command that can get its options from a spec file will do so via the "-i {filename}" command line option. If you put options on both the spec file and the orchestrator command line, presumably the command line will take precedence, as that's the general convention for such things. It may or may not warn you that it's doing so, though.
Tim _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io