OK. Here's comprehensive info on ceph and spec files:
https://documentation.suse.com/ses/7.1/single-html/ses-deployment/index.html#cephadm-service-and-placement-specs
I was remembering correctly. You can use one file to deploy multiple
services. In essence, this replaces a lot of the stuff that used to go
into /etc/ceph/ceph.conf but doesn't now since it goes into Ceph's
configuration database.
I think this is just Suse's copy of the official Ceph docs, but I just
grabbed the first thing that looked familiar.
On 11/6/24 14:23, Adam King wrote:
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
