fixing TestCephadm.test_apply_osd_save

Signed-off-by: Joshua Schmid jschmid@suse.de

#34835 is merged now.

There is a big pitfall to this patch:

When the mgr is updated before the osd daemons, the mgr will crash. Currently there is no safeguard against this scenario besides the 'update order' itself.

well, the upgrade order demands that MGRs are upgraded before OSDs.

well, the upgrade order demands that MGRs are upgraded before OSDs.

err.. right

I guess the best option we have is to wait a bit more until we get this in

hm. Why do we have a problem here at all?

• In case MGR is new and existing OSDs are old and we pause the upgrade, OSDs will simply don't have a spec affinity.

• In case MGR is new and existing OSDs are old and we deploy a new OSD, then we're going to download a new container image for the OSD.

• In case the MGR is new and we want to deploy an old OSD, (which I think might be a valid use case), waiting a bit longer to merge this PR won't help, as we would need to wait post pacific to merge this.

• In case MGR is new and existing OSDs are old and we pause the upgrade, OSDs will simply don't have a spec affinity.

I think this is the most problematic case. In this case the OSDs don't have a version of ceph-osd that supports the --osdspec-affinity option. cephadm however wants to assign assign new OSDs to the osdspec name and passes the --osdspec-affinity flag to ceph-osd, which results in a crash.

Problems like this will probably occur more often in the future when we have cross-dependencies (that are not easily resolvable with version constraints)

https://pulpito.ceph.com/swagner-2020-07-03_08:12:34-rados:cephadm-wip-swagner-testing-2020-07-02-1034-distro-basic-smithi/

• https://tracker.ceph.com/issues/46336