Add support for rbd_create4 into ceph-go's rbd library about go-ceph

[dotnwat]

Adding this should not be a problem at all. The fastest approach is to submit a pull request. But I'll put this on the todo list.

[ffledgling]

@noahdesu Can do. I do have a question though, there are a few ways of doing this, would it be preferred if somehow the existing Create call on the go side understood how to call out to create4 based on the arguments passed and/or the function signature, or would it be preferred to introduce an entirely new Create4 call on the go side that calls out to rbd_create4 ?

I could try taking cues from how librbdpy does it and submit a PR, but it'd be nice to know if there's a convention/style being followed here.

[dotnwat]

I think that adding something like Create4 would be just fine (or using some other descriptive name). IIRC Go doesn't have default parameters, so trying to create some generic interface may be more trouble than it's worth.

[dswarbrick]

If the goal is to maintain a go-ceph repo that can build against any installed librados, perhaps consider setting build tags via Makefile shell commands. For example, to handle the deprecation warnings mentioned in #42, a readelf could be executed to check for the newer, namespace-aware rados_nobjects_list_* functions (which were available in Jewel anyway):

$ readelf -s $(ldconfig -p | grep librados | awk '{print $NF}') | grep rados_nobjects_list_open
   699: 0000000000050160   614 FUNC    GLOBAL DEFAULT   12 rados_nobjects_list_open

Conditionally set go build tags, and split out the two variants of the rados_objects_list_* and rados_nobjects_list_* cgo wrappers into separate files containing build tags such as the following:

// +build HAVE_RADOS_NOBJECTS

and for older libraries:

// +build !HAVE_RADOS_NOBJECTS

This would work so long as something (i.e., the Makefile) would set the build tag. It may not be so convenient if the go-ceph library was simply being slurped in by go get; go build of a client app. Perhaps it would be better to assume that the latest and greatest library was present on the system, and rely on errors being thrown by the linker, forcing the user to explicitly set a build tag.

Alternatively, just git branch and maintain a different branch for older (LTS) releases of librados. Since the Ceph client libraries are generally backwards compatible, I don't see any harm in primarily / only supporting the latest Ceph client C library.

[phlogistonjohn]

Hello, I'm automatically closing all issues filed prior to 2018 that have not been commented on recently. If this issue is still relevant to you please reopen the issue and restart the discussion. Thank you for your understanding.