deprecation warnings about go-ceph HOT 16 CLOSED

Um, actually these are not just warnings, the list objects code doesn't work anymore on luminous (it returns rados: Operation not supported). These have to be replaced by the new versions that include the namespace.

from go-ceph.

Thank you for reporting this. I knew something like this would come along eventually. I guess we'll need to think about how to handle this general Go+C compat issue now.

My initial thought is to just now cut releases of Go and match them up with the span of Ceph versions that is compatible. I'm open to suggestions.

Another option would be to have the Go code introspect the librados version and adapt dynamically, but I'm not sure what limitations that has since presumably Go would have to link against the symbols even if they aren't being used in a newer version.

from go-ceph.

Cutting the go versions seems reasonable. I personally have had bad experiences trying to do dynamic adaption with cgo stuff because all the C symbols are in the same namespace so you cannot actually build and link against multiple versions of librados. Detecting at build time and only linking against one is no more useful than just using the correct go branch and is significantly more complex and error prone.

from go-ceph.

Thanks for the input. Also I misread your second comment above. It seems like you are saying that the methods are not just deprecated, they're not working either? :/

from go-ceph.

Yes, as of luminous those methods have been removed in librados. They just return not supported :(

from go-ceph.

This is still affecting me BTW

from go-ceph.

The rados_objects_list_* functions can harmlessly be changed to their namespace-aware versions rados_nobjects_list_* (which exist in jewel), passing nil as the namespace. It won't magically make go-ceph support namespaces, but will at least squash that warning.

The rados_read_op_omap_get_vals function needs to be replaced by rados_read_op_omap_get_vals2, which takes an additional flag-pointer to indicate if there are more values to fetch. This function doesn't exist in the jewel API, so it's going to need some conditional compilation.

These issues appear to have been addressed by hangzws#2 (albeit jewel support effectively dropped).

from go-ceph.

Is the code in @hangzws's fork going to be merged back here? Given that this is completely broken for luminous now, I am going to PR the nobjects functions first. It appears the deprecated omap function is still implemented so apart from the warning it will still work.

from go-ceph.

my ceph version is 12.2.2, I use the lastest go-ceph to operator ceph, i get the follow deprecation warning:
github.com/ceph/go-ceph/rados cgo-gcc-prolog: In function ‘_cgo_ee59cd06be73_Cfunc_rados_read_op_omap_get_vals’: cgo-gcc-prolog:498:2: warning: ‘rados_read_op_omap_get_vals’ is deprecated [-Wdeprecated-declarations] In file included from ../../github.com/ceph/go-ceph/rados/ioctx.go:6:0: /usr/include/rados/librados.h:3272:21: note: declared here CEPH_RADOS_API void rados_read_op_omap_get_vals(rados_read_op_t read_op

please re-check the lastest go-ceph work wall.Thx

my librados version is 12.2.2

from go-ceph.

@cloudislife that warning is harmless, it works well. It is quite difficult to fix that without losing jewel support.

from go-ceph.

@immesys thanks for your replay! Yes,it is, it's harmless and work well!

from go-ceph.

Hello everyone, this problem can't compile ceph_exporter, how should I solve it?

from go-ceph.

Hello everyone, this problem can't compile ceph_exporter, how should I solve it?

@lnsyyj Met the same issue, have you solved?

from go-ceph.

I have not solved it, no, but the warning does not cause any problems. You can ignore it

from go-ceph.

I'm speculating a bit here as I haven't tried any local experimentation yet, but it might make sense to move deprecated (or new) functions into files using go build constraints and provide tags to the build based on the ceph release codename (for example).

from go-ceph.

This is something worth investigating. It's been a while but I remember there being some complications because the code in question is in C

from go-ceph.