Rename the $noerr param to $no_result_catch while changing the method
name, as it was a bit confusing because we only ever adhere to it for
the actual command result, not other die's.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
can be pretty confusing because if we ever would add a subclass
basing on this module it would get the parent as class and thus the
method calls would not be overridable
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In some situations we do not want to abort if the Ceph API returns an
error. For example if we run the 'osd ok-to-stop' or similar calls, we
are interested in the status message in the error case.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
By passing back all return values from the Ceph API (RADOS.xs) to Perl
we are more flexible to make more than just the data available further
up the stack. These values are:
* return code
* status message (can contain useful information)
* data
The Ceph API interaction happens in a child process. We need to en- and
decode the returned hash in JSON to pass it between the child and parent
process.
RADOS.pm::mon_command now returns not just the data, but all information
as a hash ref. Therefore dependent packages (pve-manager, pve-storage)
need to adapt.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
If there is no symlink between '/etc/ceph/ceph.conf -> /etc/pve/ceph.conf',
executing a RADOS command results in an exception.
For example on a cluster node where no monitor is configured and no
'pveceph init' was performed, this leads to unexpected conditions. On such a
node, if you check the monitor tab in GUI the monitors are correctly displayed,
but they seem to have no quorum, because actually the RADOS command didn't return.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
To be able to connect through librados2 without a config file, the
method pve_rados_connect is split up into pve_rados_connect and
pve_rados_conf_read_file.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
