The install-deps.sh step is the same for Debian and RPM-based systems.
Simplify the two README sections into a single section.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
It may take tens of seconds to restart each time, so 5 in 30s does not stop
the crash on startup respawn loop in many cases. In particular, we'd like
to catch the case where the internal heartbeats fail.
This should be enough for all but the most sluggish of OSDs and capture
many cases of failure shortly after startup.
Fixes: #11798
Signed-off-by: Sage Weil <sage@redhat.com>
Extracted conditionals from SUSE rpm spec file to forward port.
Original work done by Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Owen Synge <osynge@suse.com>
Extracted conditionals from SUSE rpm spec file to forward port.
Original work done by Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Owen Synge <osynge@suse.com>
Extracted conditionals from SUSE rpm spec file to forward port.
Original work done by Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Owen Synge <osynge@suse.com>
Extracted conditionals from SUSE rpm spec file to forward port.
Original work done by Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Owen Synge <osynge@suse.com>
fix "pg ls" with states of "recovering" and/or "repair"
Reviewed-by: Joao Eduardo Luis <joao@suse.de>
Reviewed-by: Greg Farnum <gfarnum@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Setting this option to false reverts librbd to legacy behavior
where AIO operations could potentially block.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The profile stored by the plugin may be different from the one set by
the user: it includes defaults. When the plugin is initialized, the
profile is modified to include the default values. Verify that the
modified profile matches what the get_profile() method returns, to guard
against inconsistencies from the erasure code plugin implementation.
http://tracker.ceph.com/issues/11663Fixes: #11663
Signed-off-by: Loic Dachary <ldachary@redhat.com>
An erasure-code profile set by the user may be modified by the erasure
code plugin, most of the time to add default values for domain failure,
techniques etc.
Whenever the monitor gets an erasure code profile from the user or the
configuration file, it uses it to initialize the corresponding erasure
code plugin and:
* validate the profile and get an error if it is invalid
* get a normalized profile
The normalized profile is stored in the OSDMap. Should the user try
to set the same erasure code profile with the different values that lead
to the same normalized form, the modification will be accepted as a
noop, as if the same values were given. For instance:
ceph osd erasure-code-profile set myprofile k=2
ceph osd erasure-code-profile set myprofile k=2 m=1
are the same because the default value for m is 1 for the default
jerasure plugin.
If the normalized form is not used for storage and comparison, the
second call with m=1 will fail and require --force to override
myprofile, although the user can read from the documentation that it
matches the default value.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The ErasureCode::init function is implemented to store the profile and
is called by the init method of each plugin. The
ErasureCode::get_profile function is implemented to return the profile
that was stored. A specialized ostream<< function is implemented to
facilitate the display of the profile.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Add the get_profile method to the interface and make it a pure virtual.
Each plugin is expected to return the profile currently in use. Although
the profile is also stored in the OSDMap, it provides a convenient
introspection method to validate that the profile being set is indeed
the profile being used.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
RPM spec files summary should not end with a dot.
This was inconsistent across the ceph rpm packages
and creates errors with rpm lint.
Signed-off-by: Owen Synge <osynge@suse.com>
