Found by running the following command:
codespell -S .git,*.png,*.jpg -L \
aks,keyserver,atleast,dne,ser,ist,files\',ba,dum,iam,te -f -H
Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
cephfs csi driver still uses the ceph CLI for all the
ceph fs operations, when cephcsi gets a request from
the kubernetes it will internally starts threads for
each call. in cephcsi we are setting the pids
limit to max, to set this value the container has
to be running as the privileged one.
if we go with default pid limit we will face core dump
due to resource crunch.
without privileged access we will see Failed to set new
PID limit to -1: open /sys/fs/cgroup/pids/kubepods.slice/
kubepods-besteffort.slice/kubepods-besteffort-pod1029ed37_bebc_466d_9e53_79e7323a67ed.slice/crio-9ef6768d027916f414bf30b54ef13eebad8efd0aa4741d97618affa838d7b4c0.scope/pids.max: permission denied
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
These are a collection of unstable ceph release that are not recommended
for production. It is recommended to rollback to the previous or
upgrading to the next one if possible.
Signed-off-by: Sébastien Han <seb@redhat.com>
Currently, Rook does not support a prometheus exporter port different
than 9283 so let's fail and force the user to set it to the default.
Signed-off-by: Sébastien Han <seb@redhat.com>
as we are approaching the rook 1.5 release, we
are making a required RBAC changes for cephcsi ahead
of cephcsi release to provide smooth upgrade experience
for the users without any RBAC changes in rook minor release.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The ceph v14.2.13 release has breaking changes for the ceph-volume batch
scenario that is preventing non-pvc OSDs from being created. In the short
term we will pin the tests to v14.2.12 and separately we will need to
address the changes needed and/or wait for a fix from ceph.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The osd purge job was not removing the osd prepare job or the
osd pvc due to an invalid label query for the pvc. Now the
prepare job and pvc will be removed as expected from the job.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
We now support VAULT_TLS_SERVER_NAME which represents the name to use as
the SNI host when connecting via TLS.
This is typically needed when a single host has multiple certificates,
same as virtual hosts but for SSL certificates.
Signed-off-by: Sébastien Han <seb@redhat.com>
Fixed an issue where monitoring port, even when set by user, being
overridden by the default value.
Signed-off-by: Arun Kumar Mohan <amohan@redhat.com>
Changes related to Monitoring endpoint
a. for any monitoring endpoint and port (either user given through arguments
or internally found), added code to make sure we convert the endpoint
host_name to a proper IP address.
b. checks added to make sure we have a valid and reachable endpoint
Signed-off-by: Arun Kumar Mohan <amohan@redhat.com>
Golang maps order is not always guaranteed to be identical, which makes
the table driven test to fail. Because of the nature of the maps, it is
hard to predict the exact position of an element in the map. This
makes the table driven test flappy.
Reworked the unit test using a contains statement which achieves the
same validation.
Closes: https://github.com/rook/rook/issues/6522
Signed-off-by: Sébastien Han <seb@redhat.com>
Due to #6492, preservePoolsOnDelete is not useful at all for CephFS;
after the filesystem is deleted, the leftover pools cannot be
reassocaited with a newly created filesystem without wiping all
metadata. The only way we can actually preserve data is keeping around
the entire filesystem.
This commit implements a `preserveFilesystemOnDelete` option which work
similar to the existing pool preservation option but instead keeps the
whole CephFS while taking it down and removing all MDSes.
This commit also changes all documentation to refer to this new option
with the intent of essentially deprecating `preservePoolsOnDelete`. IMO,
keeping around `preservePoolsOnDelete` is actively harmful because it
lulls users into thinking their data will be safe but, in reality,
recovering from this situation is highly complex and has large potential
for data loss.
Signed-off-by: Lalit Maganti <lalitm@google.com>
Just like we do for the monitors, we set an ownerref to the OSD PVC so
when the cluster is deleted we remove the PVC too.
Signed-off-by: Sébastien Han <seb@redhat.com>
Add the following scenario:
* simple osd on pvc
* osd on pvc with db device
* osd on pvc with wal device
* encrypted simple osd on pvc
* encrypted osd on pvc with db device
* encrypted osd on pvc with wal device
Signed-off-by: Sébastien Han <seb@redhat.com>
When the Ceph cluster runs on PVC and the OSDs are encrypted we can
store LUKS's Key Encryption Key inside a Key Management System. Today,
Rook only supports HashiCorp Vault: https://www.vaultproject.io/
The CephCluster has now a new "security" field which will plug onto the
KMS. Here is an example:
security:
kms:
tokenSecretName: <name of the secret containing a Vault token, used
to authenticate>
connectionDetails: < a map of strings containing connection
information>
Refer to the ceph-cluster-crd documentation to lear more.
Closes: https://github.com/rook/rook/issues/6105
Signed-off-by: Sébastien Han <seb@redhat.com>
To clarify the spec of ApplyToObjectMeta This also fixes the misleading
comments on the method.
Signed-off-by: Yusei Nishiyama <yusei.nishiyama@soundcloud.com>
Travis Nielsen
Satoru Takeuchi
Mateusz Gozdek
Madhu Rajanna
Sébastien Han
subhamkrai
Arun Kumar Mohan
Jared Watts
Lalit Maganti
Yusei Nishiyama