On Mon, Feb 14, 2011 at 3:00 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote:
> There are a few problems with the current librados api (at least the C
> bindings). The main one is that there is an implicit assumption that you
> can only interact with a single cluster from the same process.
> rados_initalize() takes argc/argv, allowing you to pass in configuration
> options and/or a config file location, and it is assume that is the
> cluster that is referenced when you open up a pool.
One idea would be to have a C API like this:
rados_cluster_t ctx;
rados_initialize(&ctx);
rados_read_configuration(ctx, "my_ceph_config.conf");
rados_set_conf("log dir", "/my/log/dir");
[leaving out error handling for brevity]
So essentially, you have this rados_cluster_t which encapsulates the
cluster you're talking to and the configuration options you're using.
It should be fairly easy to create a function like rados_set_conf,
which sets arbitrary configuration options to new values in case
library users want to force particular settings.
The nice thing about doing it like this, rather than adding arguments
to rados_initialize, is that it's open-ended. We won't need to keep
creating more and more versions of rados_initialize as people discover
new options they want to set.
> In order to make it really work the way it looks, though, we need to
> identiy and eliminate as many remaining instances of common static
> variables. Currently, for example, the configuration state is static
> (in this case, shared between clusters). For things like
> debugging/logging, that's fine, but for other options it can be
> problematic.
I think we should bite the bullet and put the configuration into a
ceph_context_t.
Then to cosd.cc, cmon.cc, etc, we add
ceph_context_t *g_ctx;
Then the daemon code can be converted just by doing:
s/g_conf/g_ctx->conf/g
The code that's shared between daemons and libraries would need to add
ceph_context_t as a parameter to certain functions. The linker will
find any "mistakes" since references to g_ctx will not be resolved in
non-daemon code.
So it may be easier than it seems.
cheers,
Colin
--
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
