The forthcoming RBD compare_and_write operation needs to
support this operation when blocks are stored on an EC
pool.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The COPY_FROM operation has a custom data path for restarting
itself after the read has completed. The CMPEXT operation will
need similar restart handling when running on EC pools so that
it can guard ops after an async read completes.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
...in places that the return code was not being checked.
This fixes cases where an error in the config schema or the
value being passed in would cause weird failures beacuse the
set_val had not taken effect.
Signed-off-by: John Spray <john.spray@redhat.com>
This was only partially updated in previous commits
for --num-clients, --num-open-files.
Also update int validation test to reflect that values
are now 64 bit internally.
Signed-off-by: John Spray <john.spray@redhat.com>
The code in common_preinit is still there to override
these settings as appropriate.
The set_daemon_default stuff was breaking ceph-conf tests (because
you would get the client-side defaults when asking about an OSD's
settings), and md_config_t isn't properly identifying daemons
using code_env yet.
Ticket to add it back in:
http://tracker.ceph.com/issues/20627
Signed-off-by: John Spray <john.spray@redhat.com>
This was a string in the old schema, and tests
depended on that -- if we want to change its type
let's do that separately to the infrastructure changes.
Signed-off-by: John Spray <john.spray@redhat.com>
These were awkward for typing of the '1' literal vs.
the int64_t settings. The whole max() thing is also
unnecessary now, if we set proper bounds on the option
definitions.
Signed-off-by: John Spray <john.spray@redhat.com>
This is only there so that a variant<> containing
a uuid (amongst other types) can have operator< acting on it.
Signed-off-by: John Spray <john.spray@redhat.com>
In the new world, all int config values are 64 bit. When
doing a min() like this, need both sides in the same type.
Signed-off-by: John Spray <john.spray@redhat.com>
As long as some options are being consumed
via md_config_t:: members, various users
of (unsigned) int values will get compile warnings
when they e.g. compare them with other unsigned values.
Signed-off-by: John Spray <john.spray@redhat.com>
The C++ class member fields continue to exist for
settings defined in common/legacy_config_opts.h, but
all the schema information is coming from common/options.cc
now.
The values in md_config_t::values are automatically
copied into the C++ class member fields for legacy config
options as needed.
Signed-off-by: John Spray <john.spray@redhat.com>
We should not proceed if setting this fails. Also
the meta=false setting is not what you want when
calling into set_val after initialization, I'm not sure
how that ever worked!
Signed-off-by: John Spray <john.spray@redhat.com>
Previously these were all in one header and inclusions of it
got really verbose from everyone having to define SUBSYS and OPTION
macros even though they only wanted to pick out one or the other.
Also, this separates the subsys.h stuff (staying) from the legacy
config opt definitions (transitional, will go).
Signed-off-by: John Spray <john.spray@redhat.com>
These will be replaced by validate methods
on Option subclasses that need them. The code
that was in these files moved to options.[h|cc]
Signed-off-by: John Spray <john.spray@redhat.com>
It's a poor substitute for real a concurrency solution
but for the moment carry it forward so that the options
structure can replace the list of config_option
in md_config_t.
Signed-off-by: John Spray <john.spray@redhat.com>
We can have a legacy (static field) config object
that includes fields from config_opts.h, and
then switch to using dynamic get() for newly
added options, so that we don't need to do
code generation for the new config infrastructure.
Signed-off-by: John Spray <john.spray@redhat.com>
