ceph / ceph-rust Goto Github PK

I hate to do this, but is this project still alive? There's a few PRs that seem good and haven't been accepted (or commented on), and I'm now finding that CephClient.osd_metadata() crashes against a Pacific install.

Could we get an honest assessment of how this project is maintained?

attn: @cholcombe973

Please bump the version of ceph-rust on crates.io, the changes are getting fairly drastic at this point: a7a10ee...master . I want ti publish my ceph-client crate but can't because I use features that are not yet on crates.io

At the moment there are two exported structures for read/write operations:

pub struct ReadOperation {
    pub object_name: String,
    /// flags are set by calling LIBRADOS_OPERATION_NOFLAG |
    /// LIBRADOS_OPERATION_BALANCE_READS
    /// all the other flags are documented in rados.rs
    pub flags: u32,
    read_op_handle: rados_read_op_t,
}

pub struct WriteOperation {
    pub object_name: String,
    /// flags are set by calling LIBRADOS_OPERATION_NOFLAG |
    /// LIBRADOS_OPERATION_ORDER_READS_WRITES
    /// all the other flags are documented in rados.rs
    pub flags: u32,
    pub mtime: time_t,
    write_op_handle: rados_write_op_t,
}

read_op_handle and write_op_handle are, however, private and there aren't any methods to create the structs in the crate itself. So how are read/write operations supposed to be used, or this is something like a work in progress and they are not usable yet?

Thank you.

Hi there,

I was having trouble including this crate in a project that uses some other crates, because the other crates required a newer byteorder version, and cargo doesn't allow two different minor versions:

error: failed to select a version for `byteorder`.
    ... required by package `ceph v2.0.0`
    ... which is depended on by `testing v0.1.0 (/code/rust/testing)`
versions that meet the requirements `~1.2` are: 1.2.7, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0

all possible versions conflict with previously selected packages.

  previously selected package `byteorder v1.3.2`

For crates above 1.0.0., minor version increases should not be introducing breaking changes, so perhaps the dependency should be written as "^1.2" or even "1" instead of "~1.2". Making this change in a local copy has allowed me to use the crate. Nom and serde could probably be updated as well.

Thank you for making this crate available!

Hi, when I invoked disconnect_from_ceph() statement, crashed with below error:
/build/ceph-bPjZn9/ceph-15.2.17/src/common/config_proxy.h: In function 'void ceph::common::ConfigProxy::call_gate_close(ceph::common::ConfigProxy::md_config_obs_t*)' thread 7fe45e543700 time 2023-04-27T17:20:13.539000+0800 /build/ceph-bPjZn9/ceph-15.2.17/src/common/config_proxy.h: 71: FAILED ceph_assert(p != obs_call_gate.end()) ceph version 15.2.17 (8a82819d84cf884bd39c17e3236e0632ac146dc4) octopus (stable) 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x155) [0x7fe45fea608f] 2: (()+0x268297) [0x7fe45fea6297] .......... 85: (clone()+0x43) [0x7fe4689f9133] Aborted (core dumped)
I also tried to use unsafe{ rados_shutdown(cluster) }, but got same error.

I am getting this error intermittently, not sure where to debug this.

The code(taken from examples and https://github.com/cholcombe973/ceph_usage/blob/master/src/lib.rs) is here:

https://github.com/SachinMaharana/ceph-op/blob/449ab8ac38dc737919f68ef77e4aa2579bf84581/src/main.rs

cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/ceph-op`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error { valid_up_to: 10, error_len: Some(1) }', /home/centos/.cargo/registry/src/github.com-1ecc6299db9ec823/ceph-3.0.0/src/ceph.rs:1988:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

does ceph-rust work on windows?

I've added bindings for libradosstriper. Is there any interest to add this to upstream project? It could be added as an optional feature.

bancek@dfee5ad

Hello, I am newbie on the language rust.

I am searching for some languages which should I use. Our team is now using C++ for Ceph controller now but, we are trying to find a new area. (and also solving some memory issues.) (I already watched that go-ceph is maintained well now.)

I can see that the last commit was 2 years ago on your repository master branch. (Sadly, too old to be support recent ceph version like 18, reef)

Is this repository managed now? (Or can this repository support 18.2.0 version now?)

To reproduce:

• Create a Rados by connecting
• Create an IoCtx with rados.get_rados_ioctx(pool_name)
• Drop the Rados
• Use the IoCtx -> segfaults

=> API is unsound.

rados.get_rados_ioctx(pool_name) should either have a lifetime bound on the Rados it takes as parameter (which is bothersome for some use-cases) or take self: &Arc<Rados> and store an Arc<Rados> inside (which considering how heavy ioctx is anyway wouldn't have a significant cost, so is probably the better option).

It looks like the workspace test --all command has expanded to include doc tests so this line is causing beta to fail tests, it should either be correct code (with a comment of the variable nature), be replaced with Vec::new(), or be explicitly excluded from being built

get_error() in ceph.rs tries to convert the error into a string:

    unsafe {
        strerror_r(n, buf.as_mut_ptr() as *mut c_char, buf.len());
    }

Because ceph.rs is returning negative error codes for things like ENOENT, this means operations like trying to delete a missing object end up returning "Unknown error: -2". If n is changed to -n, a more helpful "No such file or directory" is returned instead. I haven't tested this works across all the API surface, as I'm only using rados_object_remove() at the moment.

While it's not something you can change in 2.x without breaking things, it would be great if a future release returned an error that is more easily inspected by code - at the moment fragile string comparisons are required to distinguish between an idempotent delete and something going wrong.