2017-01-16 20:14:00 +00:00
|
|
|
12.0.0
|
2016-03-09 09:40:59 +00:00
|
|
|
------
|
|
|
|
|
2017-01-16 23:03:05 +00:00
|
|
|
* When assigning a network to the public network and not to
|
|
|
|
the cluster network the network specification of the public
|
|
|
|
network will be used for the cluster network as well.
|
2017-01-24 03:16:09 +00:00
|
|
|
In older versions this would lead to cluster services
|
|
|
|
being bound to 0.0.0.0:<port>, thus making the
|
2017-01-16 23:03:05 +00:00
|
|
|
cluster service even more publicly available than the
|
|
|
|
public services. When only specifying a cluster network it
|
|
|
|
will still result in the public services binding to 0.0.0.0.
|
2017-01-24 03:16:09 +00:00
|
|
|
|
|
|
|
* Some variants of the omap_get_keys and omap_get_vals librados
|
2017-01-18 13:07:08 +00:00
|
|
|
functions have been deprecated in favor of omap_get_vals2 and
|
|
|
|
omap_get_keys2. The new methods include an output argument
|
|
|
|
indicating whether there are additional keys left to fetch.
|
|
|
|
Previously this had to be inferred from the requested key count vs
|
|
|
|
the number of keys returned, but this breaks with new OSD-side
|
|
|
|
limits on the number of keys or bytes that can be returned by a
|
|
|
|
single omap request. These limits were introduced by kraken but
|
|
|
|
are effectively disabled by default (by setting a very large limit
|
|
|
|
of 1 GB) because users of the newly deprecated interface cannot
|
|
|
|
tell whether they should fetch more keys or not. In the case of
|
|
|
|
the standalone calls in the C++ interface
|
|
|
|
(IoCtx::get_omap_{keys,vals}), librados has been updated to loop on
|
|
|
|
the client side to provide a correct result via multiple calls to
|
|
|
|
the OSD. In the case of the methods used for building
|
|
|
|
multi-operation transactions, however, client-side looping is not
|
|
|
|
practical, and the methods have been deprecated. Note that use of
|
|
|
|
either the IoCtx methods on older librados versions or the
|
|
|
|
deprecated methods on any version of librados will lead to
|
|
|
|
incomplete results if/when the new OSD limits are enabled.
|
2017-01-31 20:14:59 +00:00
|
|
|
|
|
|
|
* 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.
|