... and increase the number of files that are created so as to
hit the threshold with a high probability.
Fixes: http://tracker.ceph.com/issues/62873
Signed-off-by: Venky Shankar <vshankar@redhat.com>
Improve an ambiguous sentence in doc/architecture.rst.
The problem presented by the original sentence is that the phrasal verb
"to provide with" is implicated in one of its possible readings.
Interpreted in that way, the sentence seems to express the incorrect
idea that RBD furnishes block devices with snapshotting and cloning, as
though snapshotting and cloning are being delivered to the block
devices. In fact, snapshotting and cloning are just features of RBD, and
are features that are described on this page:
https://docs.ceph.com/en/quincy/rbd/rbd-snapshot/.
Signed-off-by: Zac Dover <zac.dover@proton.me>
Edit the English in the section "Peering and Sets" in the file
doc/architecture.rst.
Co-authored-by: Anthony D'Atri <anthony.datri@gmail.com>
Signed-off-by: Zac Dover <zac.dover@proton.me>
doc: remove egg fragment from dev/developer_guide/running-tests-locally
Reviewed-by: John Mulligan <jmulligan@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Anthony D'Atri <anthony.datri@gmail.com>
Reviewed-by: Zac Dover <zac.dover@proton.me>
DEPRECATION: git+https://github.com/ceph/teuthology#egg=teuthology
[test] contains an egg fragment with a non-PEP 508 name pip 25.0 will enforce
this behaviour change. A possible replacement is to use the req @ url syntax,
and remove the egg fragment. Discussion can be found at
https://github.com/pypa/pip/issues/11617
Signed-off-by: Dhairya Parmar <dparmar@redhat.com>
"ip route list" may list default route, and that needs to be excluded
while doing cluster setup
Typical o/p of ip route list:
$ ip route list
default via 10.8.159.254 dev eno1 proto dhcp src 10.8.152.13 metric 100
10.8.152.0/21 dev eno1 proto kernel scope link src 10.8.152.13 metric 100
Signed-off-by: Sachin Punadikar <sachin.punadikar@ibm.com>
The cephadm agent is a bit special in that it will not be converted
to a ContainerDaemonForm (it is not containerized) but we still want
to have it registered as a DeamonForm so that the deamon_type can be
passed to create and have it resolve correctly.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
While there are no ContainerDaemonForms implemented yet, add a function
that uses the ContainerDaemonForm methods to construct a deployment
for the container based daemons.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a supplemental DaemonForm subclass that helps deploy container
based daemons in a standard fashion. Most of these methods are
optional and should have sensible defaults.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The DeploymentType is used by a number of other classes and functions
and has no dependencies beyond enum and is safe to move.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Using the appropriate daemon form we can break the direct dependency
that the sysctl setup function has on particular classes and use
a generic interface.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Introduce the DeamonForm base class to cephadm.py and make various
daemon-type classes into fully fleged deamon form classes.
Some classes already had a semi-standard `init` classmethod for
instantiation. In these cases the new `create` classmethod is a thin
wrapper over the existing method. In cases where the class was not
already being instantiated a minimal set of methods are added.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Create daemon_form.py containing the DaemonForm class and a few
subclasses and utility functions for working with DaemonForms.
In a future commit, DaemonForm will become the base class for
the current assortment of classes named after the daemon or
family of daemon they help manage.
A daemon form, think "form" as in "template" or "mold", assists
in setting up, creating, and managing daemons controlled with
cephadm. Because cephadm supports a variety of services the
DaemonForm is an abstract base class and the module also supports
additional ABCs that may be used by DaemonForms to implement
optional features.
The daemon forms that are expected to be used directly must be
registered using the provided decorator. This is an explicit extra
step so that common bases that inherit from DaemonForm can be
implemented. Plus explicit is better than implicit. :-)
All DeamonForm subclasses are expected to provide a small set
of standard methods so that the types can be chosen, instantiated,
and used a common manner.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Edit doc/rads/troubleshooting.rst to remove some language that sounds
quite close to marketing language.
Signed-off-by: Zac Dover <zac.dover@proton.me>
