rgw: document and label mstart.sh and related scripts
Reviewed-by: Patrick Donnelly <pdonnell@ibm.com>
Reviewed-by: Shilpa Jagannath <smanjara@redhat.com>
qa/cephfs: ignore when specific OSD is reported down during upgrade
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
cephadm: Added cephadm command to list all the default images
Reviewed-by: Adam King <adking@redhat.com>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
mgr/cephadm: add ok_to_stop func for smb service
Reviewed-by: Adam King <adking@redhat.com>
Reviewed-by: Anoop C S <anoopcs@cryptolab.net>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
This introduces a new `ceph orch device replace` command in order to
improve the user experience when it comes to replacing the underlying
device of an OSD.
Fixes: https://tracker.ceph.com/issues/68456
Signed-off-by: Guillaume Abrioux <gabrioux@ibm.com>
typical error:
```
ceph_volume/util/disk.py:1374: error: Incompatible types in assignment (expression has type "Optional[str]", variable has type "str") [assignment]
```
This commits addresses it.
Signed-off-by: Guillaume Abrioux <gabrioux@ibm.com>
This mocks the call to `luks_close()`, otherwise this test
fails when run on a system where `cryptsetup` isn't available.
Signed-off-by: Guillaume Abrioux <gabrioux@ibm.com>
mgr/dashboard: The subvolumes are missing from the dropdown menu on the "Create NFS export" page
Reviewed-by: Ankush Behl <cloudbehl@gmail.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
cephadm: pull container images from quay.io
Reviewed-by: Adam King <adking@redhat.com>
Reviewed-by: Ernesto Puerta <epuertat@redhat.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
mgr/dashboard: sync policy's in Object >> Multi-site >> Sync-policy does not show the zonegroup to which policy belongs to
Reviewed-by: Afreen Misbah <afreen@ibm.com>
- Added gateway group param in namespace request - GET, POST, PATCH, DELETE
- Added gateway group param in Listeners request - GET
- Added gateway group param in Initiators - GET, POST, DELETE
Fixes https://tracker.ceph.com/issues/68510
Signed-off-by: Afreen Misbah <afreen@ibm.com>
The Google coding guide opposes to forward declarations, but I
disagree with that opinion. In my opinion, forward declarations are
useful. Ceph build times are miserable due to header dependency bloat
and template bloat, both of which can be reduced using forward
declarations.
All cons listed in https://google.github.io/styleguide/cppguide.html
> Forward declarations can hide a dependency, allowing user code to
> skip necessary recompilation when headers change.
That is a pro, not a con. Skipping (unnecessary) recompilation is a
good thing, it's the goal of forward declarations.
> A forward declaration as opposed to an #include statement makes it
> difficult for automatic tooling to discover the module defining the
> symbol.
That certainly depends on the tools one uses, but I cannot imagine
today's IDEs are limited to one compilation unit.
> A forward declaration may be broken by subsequent changes to the
> library.
True, and that will lead to a compiler error.
> Forward declarations of functions and templates can prevent the
> header owners from making otherwise-compatible changes to their
> APIs, such as widening a parameter type, adding a template parameter
> with a default value, or migrating to a new namespace.
Forward declarations do not prevent any of that. But if you change
the "real" declaration, all incompatible forward declarations will
cause a compiler error.
> Forward declaring symbols from namespace std:: yields undefined
> behavior.
Sad, but true. But that is not an argument against forward
declarations for Ceph's own types.
> It can be difficult to determine whether a forward declaration or a
> full #include is needed.
If it compiles without the `#include`, then the forward declaration is
fine. (Or the primary header happened to be already included by
somebody else.)
> Replacing an #include with a forward declaration can silently change
> the meaning of code: [...] If the #include was replaced with forward
> decls for B and D, test() would call f(void*).
True, but this is a contrived example, and is bad coding style because
it is error prone. Casts to `void*` can and should be avoided. There
are rare examples where such casts are necessary (boundary to C APIs),
and then it's very unusual to pass derived incomplete types.
> Forward declaring multiple symbols from a header can be more verbose
> than simply #includeing the header.
True, but that misses the point of forward declarations.
> Structuring code to enable forward declarations (e.g., using pointer
> members instead of object members) can make the code slower and more
> complex.
True, but that is not a property of forward declarations. I don't
suggest doing such a thing.
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
