Hi Adam, Thanks a lot for sharing this information. It confirms our observations. Regards, Frédéric. ----- Le 6 Nov 24, à 20:23, Adam King adking@xxxxxxxxxx a écrit : > 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@xxxxxxxxxxxxx> 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@xxxxxxx >> To unsubscribe send an email to ceph-users-leave@xxxxxxx >> > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |