I see option (3) as such a large restriction on one of largest (if not the largest) end-users of librbd that it's effectively a vote for just reverting the change. In answer to your other question, yes, Cinder/Nova/Glance will all be happy w/ a string integer since that is exactly what they were getting before (the librados API only provides string representations for config values). On Wed, Dec 14, 2016 at 9:12 AM, Mykola Golub <mgolub@xxxxxxxxxxxx> wrote: > On Wed, Dec 14, 2016 at 08:39:03AM -0500, Jason Dillaman wrote: >> In the short and medium term, there isn't any way to get multiple >> versions of OpenStack to stop directly parsing librbd configuration >> options and switch to new API methods. The only reason they are >> overriding the default image features is to ensure layering support is >> enabled. In the C/C++ APIs, we have a clean way [1] to add individual >> features while keeping the default feature set, but this isn't >> currently exposed in the Python API. >> >> For the Kraken release, I think the only two real options are to (1) >> add internal support for a config validator that takes the human >> friendly, comma delimited feature names and automatically converts >> them to the integer that has previously been expected, or (2) revert >> the change and go back to using a non-user friendly bitmask. > > (3) Hardcode rbd_default_features in common/config_opts.h to its > numerical value (currently it should work both way). It would make > cinder (and other users who parse rbd_default_features) happy until it > is explicitly set in the config using a new way (as a list of feature > names). Document this restriction -- cinder users who want to change > rbd_default_features in ceph.conf would need to continue to use a > numeric value. > > This may be used as workaround on currently affected installations. > Victor, could you please try to set rbd_default_features in ceph.conf > to its numeric value (61) and see if it fixes the issue? > > -- > Mykola Golub -- Jason -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
