Patterned after cephtool/test.sh, with some deeper validation of
output format and contents (because structured output is easier
to validate).
Signed-off-by: Dan Mick <dan.mick@inktank.com>
ceph-rest-api is a Python WSGI module for accessing the Ceph cluster.
It supports most of the commands supported by the ceph CLI,
appropriately translated to HTTP GET/PUT requests. It is not a
truly RESTful interface.
Not supported at this moment: "tell", "pg <pgid>", and "daemon"
commands.
Configuration options are specified in ceph.conf, specified with
-c/--conf or obtained from $CEPH_CONF, /etc/ceph/ceph.conf,
~/.ceph/ceph.conf, or ./ceph.conf.
-n/--name specifies the client name, used for the cluster
authentication key and for the ceph.conf section name (default
is client.restapi).
restapi keyring = <keyring file>
restapi public addr = listenIP:port (default 0.0.0.0:5000)
restapi base url = <base path> (default /api/v0.1)
restapi log level = (error, warning, info, debug)
restapi log file = (default /var/log/ceph/<clientname>.log)
Primitive human-level command discovery is supported; GET from
BASEURL (say, http://localhost:5000/api/v0.1) will show an HTML
table of all commands and arguments, method supported, and help strings.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Move 'osd pool get' handling to preprocess_command()
It's a read operation; there's no need for it to be in prepare_command().
Also, add formatted output.
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Commands such as 'mon_status', 'quorum_status', 'sync_status' and
'sync_force' didn't support other formatter besides json. Regardless of
'--format=foo' being specified, they would always output in json.
This commit changes that behavior, allowing a format to be passed. These
functions do not output in plain-text however. Plain-text will default
to 'json' -- the reason: the information they provide are better outputted
in a structured fashion, and I was too lazy to come up with a plain-text
version that could be at least as good.
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Dan Mick <dan.mick@inktank.com>
auth: KeyRing: encode_formatted() receives a label as first argument
Also, this allows us to standardize formatted output on the AuthMonitor,
so that all output starts with a section 'auth'. Other subsystems using
the KeyRing class, can specify whatever section they prefer.
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
The type validation's valid() method was using a combination of
return code and exception to really indicate the same thing;
simplify by only raising on validation error, and change callers
to cope. validate_one() follows suit.
Also, allow validate() to be called with args that are dicts
(for REST support) rather than bare words. Rules: 'name':'value'
must both match descriptor's name and validate (through valid() for
the value. If value is '', it's assumed to be the same as name,
(one can pass, for example, "detail" as one parameter to
REST, but it will still show up as {'detail':''} here).
Tweak validate()'s algorithm a bit in the process, and make
validate_command() exit the bestcmds loop immediately on first
full validation.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
To help optimize the REST API, we need to know whether the commands
are read (GET) or write (PUT/POST). However, we also could use that
same info for permission/caps checking. Add modulename/perms as
the required caps for each command to drive both needs.
The availability field is to control whether a command is displayed/
advertised through the CLI or REST interfaces; some commands aren't
really useful for REST, and we may want to invent REST-only commands;
also, this gives us a way to deprecate commands quickly and leave the
code, should that be desirable. Make the CLI display only commands
marked with the 'CLI' marker.
Also stop renaming 'help' to 'helptext' in the client.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
On some systems (virtual machines so far) the device-by-path entry
from udevadm is not always in the same spot so instead actually
look for the right output instead of blindy assuming that its a
specific field in the output.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Reviewed-by: Gary Lowell <gary.lowell@inktank.com>
On some systems (virtual machines so far) the device-by-path entry
from udevadm is not always in the same spot so instead actually
look for the right output instead of blindy assuming that its a
specific field in the output.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Reviewed-by: Gary Lowell <gary.lowell@inktank.com>
This reinstates the fix for the ceph_sbindir from commit
352f362567, with corrections
from Danny's review commits pull request #389.
Fixes: #5492
Reported-by: Denis Kaganovich <mahatma@eu.by>
Reviewed-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
It's only present in very recent versions of nose, and doesn't provide
much beyond a simple assert.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
Fixes bug 5528
Since it returns all xattrs, it does not take an xattr_name. Also,
add unit tests for the Object xattrs methods.
Signed-off-by: Johannes Erdfelt <johannes@erdfelt.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
We should not send an unbounded number of inc maps to our peers or clients.
In particular, if a peer is not contacted for a while, we may think they
have a very old map (say, 10000 epochs ago) and send thousands of inc maps
when the distribution shifts and we need to peer.
Note that if we do not send enough maps, the peers will make do by
requesting the map from somewhere else (currently the mon). Regardless
of the source, however, we must limit the amount that we speculatively
share as it usually is not needed.
Backport: cuttlefish, bobtail
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
The field is not used or useful since the monitor does not even look
at it (in Monitor::handle_command()). Avoid populating it and the
subsequent confusion for poor developers.
Signed-off-by: Sage Weil <sage@inktank.com>
The PaxosServiceMessage version field is meant for client-coordinated
ordering of messages when switching between monitors (and is rarely
used). Do not fill it with the osdmap epoch lest it be compared to a
pgmap version, which may cause the mon to (near) indefinitely put it on
a wait queue until the pgmap version catches up.
Backport: cuttlefish
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
