instead of assuming that the function passed to finally() returns an
erroratorized future, in this change:
* s/safe_then/then_wrapped/ to handle the exception thrown by
the finally function.
* specialize for the case where the finally function does not return
a future, and just call it. note, in seastar's implementation of
finally, `finally_body` is used for specializing these two cases.
* rename "future" to "result", for better readability.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Replaced the content of `HACKING.rst` in the dashboard source code
directory with a pointer to the new location in the developer guide.
Updated references in `README.rst` to also point to the online versions
of these files.
Fixes: tracker.ceph.com/issues/47396
Signed-off-by: Lenz Grimmer <lgrimmer@suse.com>
mds_cluster.mds_fail() runs command "mds fail" not "fs fail". The reason
for failure was PR #32581 which accidentally changed the return code
from 0 to EINVAL. Since this was reversed in PR #37159, the change
introduced by 04ed58f is not only incorrect but also redundant.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
mgr/dashboard: Disabling the form inputs for the read_only modals
Reviewed-by: Alfonso Martínez <almartin@redhat.com>
Reviewed-by: Ernesto Puerta <epuertat@redhat.com>
Reviewed-by: Tiago Melo <tmelo@suse.com>
Added a separate endpoint for osd/histogram - api/osd/{svc_id}/histogram
Fixes:https://tracker.ceph.com/issues/46898
Signed-off-by: Aashish Sharma <aasharma@redhat.com>
In filesystem.py, don't set value of reset_obj_attrs to False.
Fixes: https://tracker.ceph.com/issues/47526
Signed-off-by: Rishabh Dave <ridave@redhat.com>
When checking if a certain fs subcommand can and should be executed in
FSCommands.cc, check permissions in "profile_grants" too when the caps
for that entity contains a cap profile.
Fixes: https://tracker.ceph.com/issues/47423
Signed-off-by: Rishabh Dave <ridave@redhat.com>
This allows a specific IOContext to be used regardless of the image's
current read and write snapshot state.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This allows a specific IOContext to be used regardless of the image's
current read and write snapshot state.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Deep-copy will require the ability to issue IOs against arbitrary
IOContexts via the image-extent IO dispatcher.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This was a legacy implementation where it was assigned by the ImageRequestWQ
and therefore needs to be part of the factory methods.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Now that we don't need to worry about read requests issuing a finish
callback, we can use a simple counter to track in-flight writes.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Any dispatch layer can now directly place themselves in the finish
callback handler chain without the use of the generic callback.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This mimics the design from the object dispatcher and will allow
for simplified in-flight IO tracking.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
We can now pass the flush through the exclusive-lock dispatch layer
to ensure all in-flight IOs have been processed.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Only flush requests coming from the refresh state machine or from the
exclusive-lock dispatch layer initializationshould be ignored. This is
because both can be initiated from the refresh state machine and
therefore deadlock.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The exclusive-lock dispatch layer should be locked and flushed to
ensure no IO is waiting for a refresh. Once that is complete, interlock
with the refresh state machine and re-flush one last time w/ the
refresh dispatch layer skipped.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The exclusive-lock dispatch layer will already block IOs as required
so this second layer of blocking just increases the complexity and
the potential for deadlocks when attempting to flush.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
If the exclusive-lock layer is being initialized/shut down at image
open/close, there is no IO flowing so there is no need to flush.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
