Ceph » Orchestrator

Hm. Isn't this a big flaw in adopt, not just for MDS?

We might need to apply something like this before adopting any daemons

service_type: mds
service_id: XXX
unmanaged: true

And run something like

service_type: mds
service_id: XXX
unmanaged: false
placement: ...

after the adoption is done.

Sebastian Wagner wrote:

Hm. Isn't this a big flaw in adopt, not just for MDS?

Not in practice so far. The docs say to adopt MON, MGR and OSD, and to redeploy everything else. The cephadm orchestrator doesn't care if MON, MGR and OSD don't have service specs (https://github.com/ceph/ceph/blob/master/src/pybind/mgr/cephadm/module.py#L1889), so doesn't remove them as orphans.

That said, the comment on https://github.com/ceph/ceph/blob/master/src/pybind/mgr/cephadm/module.py#L1890 claims that MON and MGR specs should always exist, and the fact that they don't after an adopt may mean that this all only works by accident. In which case, yes, this probably needs some attention.

We might need to apply something like this before adopting any daemons
[...]

How do we apply service specs before adoption? The orchestrator can't be enabled until after MONs and MGRs are adopted...

It's not an accident that this is working. OTOH, this needs behavior needs improvement. Let me think about the chicken-and-egg problem a bit.

We have the same problem with adopted prometheus instances (I adopted one, it was working fine for a few minutes, then the orhcestrator went and removed it)