deprecation warnings

[immesys]

When I compile go-ceph I get:

# github.com/ceph/go-ceph/rados
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_objects_list_close’:
cgo-gcc-prolog:348:2: warning: ‘rados_objects_list_close’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3750:21: note: declared here
 CEPH_RADOS_API void rados_objects_list_close(
                     ^
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_objects_list_get_pg_hash_position’:
cgo-gcc-prolog:364:2: warning: ‘rados_objects_list_get_pg_hash_position’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3741:25: note: declared here
 CEPH_RADOS_API uint32_t rados_objects_list_get_pg_hash_position(
                         ^
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_objects_list_next’:
cgo-gcc-prolog:384:2: warning: ‘rados_objects_list_next’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3746:20: note: declared here
 CEPH_RADOS_API int rados_objects_list_next(
                    ^
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_objects_list_open’:
cgo-gcc-prolog:403:2: warning: ‘rados_objects_list_open’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3738:20: note: declared here
 CEPH_RADOS_API int rados_objects_list_open(
                    ^
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_objects_list_seek’:
cgo-gcc-prolog:423:2: warning: ‘rados_objects_list_seek’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3743:25: note: declared here
 CEPH_RADOS_API uint32_t rados_objects_list_seek(
                         ^
cgo-gcc-prolog: In function ‘_cgo_c03cef46a91f_Cfunc_rados_read_op_omap_get_vals’:
cgo-gcc-prolog:497:2: warning: ‘rados_read_op_omap_get_vals’ is deprecated [-Wdeprecated-declarations]
In file included from ../../../ceph/go-ceph/rados/ioctx.go:6:0:
/usr/include/rados/librados.h:3271:21: note: declared here
 CEPH_RADOS_API void rados_read_op_omap_get_vals(rados_read_op_t read_op,

My librados is from luminous

[immesys]

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.

[dotnwat]

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.

[immesys]

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.

[dotnwat]

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? :/

[immesys]

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

[immesys]

This is still affecting me BTW

[dswarbrick]

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).

[immesys]

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.

[cloudislife]

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

[immesys]

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

[cloudislife]

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

[lnsyyj]

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

[baimuxiaozi]

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

@lnsyyj Met the same issue, have you solved?

[immesys]

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

[phlogistonjohn]

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).

[immesys]

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