Replaced `math/rand` with more secure `crypto/rand` which will generate CSPRNG.
Changed the length of dashboard password from 10 to 20 and included more special characters that can strengthen password.
Passwords before this change: QoMmqLkaOf,8tqTyWF1sZ
Passwords after this change: L{QZ@_c'Rl7$uvW:UHU1, fP-OjX`UVw0J0Ka/scS(
Resolves: https://github.com/rook/rook/issues/4571
Signed-off-by: Nizamudeen <nia@redhat.com>
security issues identified by TrailOfBits:
Improperly handled type assertion error could result in invalid
execution state.
If we obtain an error trying to get a Node object is better not
continue executing this function.
Resolves#4567
Signed-off-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>
"ceph-volume activate" on encrypted osds needs a ceph.conf as well as
connectivity to the mons. This commit adds that to that "activate-osd"
init container.
Closes: https://github.com/rook/rook/issues/4558
Signed-off-by: Sébastien Han <seb@redhat.com>
The OSDs on PVCs were changing location in the CRUSH
hierarchy after an operator restart due to the location
property not being re-discovered on the OSD daemon.
Since OSDs on PVCs do not run the prepare pod again
to discover this property, the operator must read it
off the existing osd deployment. The operator was
reading other properties, but now will read the location
as well.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The isUpgrade flag was being set every time the operator
was started. This caused the upgrade checks to be run every
time the operator restarted. Thus, if any mons were down,
you likely would get stuck on the upgrade checks since another
mon could not be stopped. We need to rely on the upgrade being
detected either by a different image name from the cluster CR
update, or from different versions of the daemons running
in case the operator was restarted in the middle of an upgrade.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Reduce from 5 minutes to less than 50 seconds the time needed to restart a
mgr and osds(PVCs based),rgw,mds,rbd,nfs and toolbox pod that was running
in a k8s "NotReady" Node.
A new Rook Operator setting has been added to allow the user to set the
time used in pod's toleration <node.kubernetes.io/unreachable>:
ROOK_UNREACHABLE_NODE_TOLERATION_SECONDS = <5>
New setting added in release notes
Addressed @travisn,@leseb, and @blaineEXE suggestions
Signed-off-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>
When using the "errors" package, using `%+v` (extended format),
each Frame of the error's StackTrace will be printed in detail.
Let's only print `%v` to print the error.
If the error has a Cause it will be printed recursively.
Basically `%+v` has been replaced with `%v` for all `error` type
interfaces, whether the logger is Info, Warning or Error.
Signed-off-by: Sébastien Han <seb@redhat.com>
gp2 devices present themselves as SSDs,
but have much more variable performance.
Ceph attempts to adjust some settings based on the drive type,
HDD/SSD
In this case client I/O can be impacted too much by assuming gp2 devices are like other SSDs
(an example is https://bugzilla.redhat.com/show_bug.cgi?id=1765923#c6)
In order to prevent this, rook can set the following for OSDs
if the new CR setting `tuneSlowDeviceClass` is set to `true`:
```
osd_recovery_sleep = 0.1
osd_snap_trim_sleep = 2
osd_delete_sleep = 2
```
Closes: https://github.com/rook/rook/issues/4298 and https://bugzilla.redhat.com/show_bug.cgi?id=1771047
Signed-off-by: Sébastien Han <seb@redhat.com>
Removing an OSD unintentionally can result in data loss,
which is to be prevented at all costs. Rook's functionality
to remove OSDs automatically when a node was removed from the
cluster CR has led on several occasions to users having OSDs
unintentionally removed from their cluster.
If the admin decides they really need to remove OSDs they should
do it as a one-time action that they intentionally run
rather than the operator attempting to manage the deletion
with desired state. The risk of misinterpreting the desired
state, even with a typo, is too great.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
It's not 100% safe since before Nautilus osd safe-to-destroy command
didn't have any json output. So added a version check.
Signed-off-by: rohan47 <rohgupta@redhat.com>
As of 14.2.5, the crash collector pod will use the client.crash user
instead of the client.admin keyring to post crash dumps.
Closes: https://github.com/rook/rook/issues/4388
Signed-off-by: Sébastien Han <seb@redhat.com>
If editing the cluster CR we must update the spec to reflect its new
content. Now the spec is updated so we can update with an unsupported
image as well as setting allowUnsupported: true.
It was not possible before we had to restart the operator, now we can do
it as an update.
Signed-off-by: Sébastien Han <seb@redhat.com>
We must not default the selectors to the labels since labels can be
changed and selector cannot until the deployment is updated.
This way the deployment was failing with:
2019-12-10 10:48:13.414438 E | ceph-crashcollector-controller: node reconcile failed on op "unchanged": Deployment.apps "rook-ceph-crashcollector-minikube" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"rook-ceph-crashcollector", "ceph-version":"15.0.0", "ceph_daemon_id":"crash", "crashcollector":"crash", "kubernetes.io/hostname":"minikube", "node_name":"minikube", "rook-version":"v1.2.0-3.g8d3b85306.dirty"}: `selector` does not match template `labels`
Signed-off-by: Sébastien Han <seb@redhat.com>
The loop wasn't using seconds for its retry so the crash controller
would simply crash since the version is used later in the pod spec.
Signed-off-by: Sébastien Han <seb@redhat.com>
Just as with the mon, mgr, mds, rgw, and rbd-mirror daemons, do not
generate a ceph.conf in an init container for filestore OSDs.
Instead use the commandline to supply all the needed arguments for
running these OSDs.
Signed-off-by: Blaine Gardner <blaine.gardner@suse.com>
This change adds rook-version and ceph-version tags to crash
collector deployments, in keeping with other Ceph deployments.
Resolves: #4357
Signed-off-by: Elise Gafford <egafford@redhat.com>
ceph client CRD refactoring
Add info about client crd to documentation
Add tests for client controller CRD
Signed-off-by: Mateusz Los <los.mateusz@gmail.com>
When a node has been removed, cordoned, or is otherwise
missing from the filters that rook uses to evaluate deploying
osds on nodes, the orchestration should continue instead
of failing. Otherwise, the orchestration will stay stuck
in a retry loop if any nodes are cordoned or removed in
the middle of an orchestration.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
"OSD on PVC" doesn't work for PV backed by LV. Fixing this problem
by the following changes.
- Rook accepts LVM disk type.
- If a LV-backed device is passed, Rook/Ceph invokes
"ceph-volume lvm prepare" with "--data vg/lv"
instead of "--data /path/to/device".
- If a LV-backed device is passed, Rook/Ceph suppresses
activation/deactivation of VG that owns this LV.
Fixes: https://github.com/rook/rook/issues/4185
Signed-off-by: dulltz <isrgnoe@gmail.com>
Co-authored-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
This patch removes the need of using both tini and rook binary to run
the main osd container.
By removing this, we know can upgrade the operator image without
restarting the OSD since the osd pod does not use the rook image
anymore.
This patch only works when not running OSD on PVC since they are certain
actions that we cannot achieve with an init container.
A new init container has been introduced to do the activation of the
OSD, the activate files are placed in a empty dir mount and shared with
the main osd process.
Now the main osd process runs the ceph-osd daemon binary directly.
This currently has a few limitation:
* only works with bluestore OSDs
* only works when not running OSD on PVC
Closes: https://github.com/rook/rook/issues/4363
Signed-off-by: Sébastien Han <seb@redhat.com>
We shouldn't need to compute the location from the main OSD pod, since
the prepare pod runs on the same node we can populate the crush location
information from that pod and pass it along to the main osd container.
This is an initial commit that aims to eventually remove the need of
using the rook binary when running the main osd container.
Closes: https://github.com/rook/rook/issues/4362
Signed-off-by: Sébastien Han <seb@redhat.com>
During an orchestration if there were failures to update any OSD deployment,
the orchestration would fail and continue trying again. If the OSD(s)
continued failing, the operator would be stuck in a loop and never
respond to other CR updates.
Now the operator will log the OSD errors, if any, and complete the
orchestration. We will rely on K8s to continue to attempt to start
the OSD pods instead of the operator being stuck in the loop.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
We recently discovered a race condition which happens not to update the
child CRDs when CR image changes.
The race happens under the following sequence:
* orchestration onAdd() is called when the operator image restarts
or its image updated
* the orchestration then goes into processing mon/mgr/osd
* during this the cluster CR is updated so onUpdate() is called,
however, onAdd() is not done yet for child CRDs (mds, rgw)
* onUpdate() runs against the cluster CR and updates the cluster images
* by the time the child CRDs reached onUpdate() from their respective
ParentClusterChanged() methods, the image is already up to date
so we were exiting since our check for updating
these resources are based on the cluster image version
To fix this, we changed the comparison, but using isUpgrade instead and
slightly changed the way isUpgrade operates. So now, isUpgrade is true
even if the Ceph version is identical which allows us to verify whether
or not the image changed.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1775624
Signed-off-by: Sébastien Han <seb@redhat.com>
Because of this, the mgr would be restarted if the operator image
change. This must not happen.
Added unit tests for cephMgrOrchestratorModuleEnvs() as well.
Closes: https://github.com/rook/rook/issues/4361
Signed-off-by: Sébastien Han <seb@redhat.com>
Some log messages indicate when the upgrade checks will be
performed. If the Ceph image hasn't changed, the upgrade checks
are skipped. The messages were confusing if running a Rook
upgrade.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
We create CSI resources when we create the first Ceph cluster.
This change deletes all CSI resources when we delete the last Ceph
cluster.
Partially resolves: #4234
Signed-off-by: Elise Gafford <egafford@redhat.com>
In order to remove Ceph-CSI resources after deletion of the last
Ceph cluster, the operator must be able to perform post-processing
actions on cluster deletion. This change creates a hook for the
addition of post-deletion operator callback functions.
Partially resolves: #4234
Signed-off-by: Elise Gafford <egafford@redhat.com>
With DM_DISABLE_UDEV, LVM will avoid interaction with udev.
LVM will manage the relevant nodes in /dev directly.
Signed-off-by: Sébastien Han <seb@redhat.com>
Nizamudeen
Sébastien Han
Juan Miguel Olmo Martínez
Travis Nielsen
rohan47
Blaine Gardner
Elise Gafford
Mateusz Los
Mateusz Gozdek
dulltzandSatoru Takeuchi
Kazuhito MATSUDA
d-luu
Rohan CJ