- remove upgrades from nautilus
- stubs for completing upgrade to quincy
Still missing the pacific-x upgrade tests.
Signed-off-by: Sage Weil <sage@newdream.net>
Existing pools might have too many/few PGs and produce a warning that
prevents us from getting to HEALTH_OK.
Signed-off-by: Sage Weil <sage@redhat.com>
- start with msgr2 enabled (defaults)
- run nautilus branch for workunits
- drop msgr2 enable step at teh end
- add octopus placeholder (although it is empty for now)
Signed-off-by: Sage Weil <sage@redhat.com>
* add qa/releases/nautilus.yaml so it can be reused.
* use releases/nautilus.yaml in luminous-x upgrade test, so
test_librbd_python.sh is able to use the feature introduced in
nautilus.
Fixes: http://tracker.ceph.com/issues/37432
Signed-off-by: Kefu Chai <kchai@redhat.com>
- OSDMap encode and decode translate between the flags and int
representations.
- OSDMap::Incremental only does decode; we do not expect to ever encode
an incremental osdmap for an old osd that sets any of these flags.
- the 'osd set' command still lets you set the jewel and kraken flags,
but not luminous.
- OSDMap::apply_incremental handles the conversion of legacy require flags
to the new field if the jewel or kraken flags have to be set before
starting the osd upgrade.
- clear out the legacy flags when we make the luminous transition only;
until then we keep using the old flag in the encoded and decoded version
(although the require_osd_release field will be accurate in memory in all
cases).
Signed-off-by: Sage Weil <sage@redhat.com>
Start warning once mons are luminous; start erroring once
require_luminous is set in osdmap. Allow a grace period for
mgr to restart or standby to take over before we turn a warning
into an error.
Signed-off-by: Sage Weil <sage@redhat.com>
Sage Weil
Sage Weil
Kefu Chai
Yuri Weinstein