]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc: zero PendingReleaseNotes in preparation for v10.2.9 16273/head
authorNathan Cutler <ncutler@suse.com>
Tue, 11 Jul 2017 20:53:56 +0000 (22:53 +0200)
committerNathan Cutler <ncutler@suse.com>
Tue, 11 Jul 2017 20:53:56 +0000 (22:53 +0200)
Signed-off-by: Nathan Cutler <ncutler@suse.com>
PendingReleaseNotes

index 61bcb62e65a8e99aeffa6033e1fb04ad66919afc..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 100644 (file)
@@ -1,43 +0,0 @@
-published in 10.2.8 announcement:
-
-* There was a bug introduced in Jewel (#19119) that broke the mapping behavior
-  when an "out" OSD that still existed in the CRUSH map was removed with 'osd rm'.
-  This could result in 'misdirected op' and other errors.  The bug is now fixed,
-  but the fix itself introduces the same risk because the behavior may vary between
-  clients and OSDs.  To avoid problems, please ensure that all OSDs are removed
-  from the CRUSH map before deleting them.  That is, be sure to do::
-
-     ceph osd crush rm osd.123
-
-  before::
-
-     ceph osd rm osd.123
-
-* This release greatly improves control and throttling of the snap trimmer. It
-  introduces the "osd max trimming pgs" option (defaulting to 2), which limits
-  how many PGs on an OSD can be trimming snapshots at a time. And it restores
-  the safe use of the "osd snap trim sleep" option, wihch defaults to 0 but
-  otherwise adds the given number of seconds in delay between every dispatch
-  of trim operations to the underlying system.
-
-
-feature included in 10.2.7, but not announced:
-
-* Calculation of recovery priorities has been updated.
-  This could lead to unintuitive recovery prioritization
-  during cluster upgrade. In case of such recovery, OSDs
-  in old version would operate on different priority ranges
-  than new ones. Once upgraded, cluster will operate on
-  consistent values.
-
-
-published in 10.2.6 announcement:
-
-* In previous versions, if a client sent an op to the wrong OSD, the OSD
-  would reply with ENXIO.  The rationale here is that the client or OSD is
-  clearly buggy and we want to surface the error as clearly as possible.
-  We now only send the ENXIO reply if the osd_enxio_on_misdirected_op option
-  is enabled (it's off by default).  This means that a VM using librbd that
-  previously would have gotten an EIO and gone read-only will now see a
-  blocked/hung IO instead.
-