The operator will now allow the resource limits to be applied below the
recommended minimums. In small clusters, even the recommended minimums
may not be necessary. A warning is still printed to the operator log,
but we allow the configuration to continue.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Added more unit tests scenario for osd on pvc such as:
* block/db/wal
* block encryption
* block/db encryption
* block/db/wal encryption
Signed-off-by: Sébastien Han <seb@redhat.com>
This init container displays the status of the encrypted pvc. This can
be really useful for debugging purpose.
Signed-off-by: Sébastien Han <seb@redhat.com>
We now support the expansion of encrypted osds. We added a new init
container to run "cryptsetup resize".
Signed-off-by: Sébastien Han <seb@redhat.com>
If the deployment spec was updated or restarted, the "encryption-open"
init container would fail to open the device since it was already
opened on the node.
Because they are no reliable post stop hook on Kubernetes, the trick is
to use a small bash init container.
Signed-off-by: Sébastien Han <seb@redhat.com>
The osd prepare resources were only being set on the main container
while the init containers either did not have resources set, or were
inheriting the resource settings from the device set resources for osds.
Now the osd prepare resources will be consistently set based on the
prepareosd resources in the main section of the cluster CR.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
This is simply a code simplification to remove an extra check for
whether the OSDs are encrypted. There is no change in functionality.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The osd prepare jobs and osd daemons may have different placement
requirements. In particular, the topology spread constraints
or pod anti-affinity should only work on either the prepare job or
osd daemon, but does not work effectively on both types at the same
time. Therefore, we split out the osd prepare placement to be separate
from the osd daemon placement. If the osd prepare placement is not set
the operator will fall back to the osd daemon placement for
backward compatibility.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
If a node is gone, we try to remove crash collector deployments so they
don't stay stale or pending. We must ensure the node is gone and not
just return an error even if we successfully deployment the orphan
deployment.
Signed-off-by: Sébastien Han <seb@redhat.com>
Now the metadata pvc will also be encrypted if the storageClassDeviceSet
has the "encrypted" flag turned on.
Signed-off-by: Sébastien Han <seb@redhat.com>
When a mon is failed over, the new mon is started before the old mon
is removed from quorum and purged from the cluster. If the mon has
anti-affinity, in small clusters or specific toplogies where sufficient
nodes are not available, the new mon may be prevented from starting simply
because the dead mon pod still exists. To ensure a clean failover, the
dead mon pod must first be stopped before the new mon is started.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
For external cluster, it is not an issue to have a mon count set to 0
since Rook is not deploying/managing the monitors.
Signed-off-by: Sébastien Han <seb@redhat.com>
Based on the feature of metadata PVC for OSD: #4818, add the wal device.
For this, you need to create a new volumeClaimTemplates, its name must be "wal", if "wal" is
set, "metadata" device will refers specially for block.db device, and "wal" refers for block.wal
device in BlueStore.
A template will look like this:
```
volumeClaimTemplates:
- metadata:
name: data
spec:
resources:
requests:
storage: 10Gi
# IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, gp2)
storageClassName: gp2
volumeMode: Block
accessModes:
- ReadWriteOnce
- metadata:
name: metadata
spec:
resources:
requests:
storage: 6Gi
# IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, io1)
storageClassName: io1
volumeMode: Block
accessModes:
- ReadWriteOnce
- metadata:
name: wal
spec:
resources:
requests:
storage: 6Gi
# IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, io1)
storageClassName: io1
volumeMode: Block
accessModes:
- ReadWriteOnce
```
We now map block, block.db and block.wal directly inside the container instead of
running ceph-volume activate.
Signed-off-by: Chen, Tingjie <tingjie.chen@intel.com>
The cluster CR status needs to be updated with the latest object
instead of a cached copy or else it could fail if there is some
other update. Using the Rook clientset ensures it is the latest
instead of using the cached controller runtime object.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The service selector labels cannot be updated during the upgrade or else the
mon commands will not respond until the mon deployment is also updated.
Since there is a mon command to check for the ceph versions before the
deployment is updated, the operator would remain stuck during the upgrade.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
We can now encrypted OSD device that were provisioned via a storage
class using the PV interface.
The encryption works at the storageClassDeviceSets level, which means we
can have encrypted and non-encrypted sets.
Using the new key `encrypted` we can turn it on.
Signed-off-by: Sébastien Han <seb@redhat.com>
The labels cannot be updated on a deployment match selector.
In v1.4 a new label was added for ceph_daemon_type that is intended
to be on the pod labels, but cannot be applied to the match selectors.
Therefore, we suppress any new labels that are added to the daemons.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Rename PodLabels function to CephDaemonAppLabels for more clarity about
what the function's purpose is.
Signed-off-by: Blaine Gardner <blaine.gardner@suse.com>
this commit handles all the gosec g601
error code (i.e Implicit memory aliasing
of items from a range statement).
Signed-off-by: subhamkrai <subhamkumarrai03@gmail.com>
Instead of setting the Phase of the CR once the reconcile is done, let's
actually set in from the healthcheck so it is more accurate.
Closes: https://github.com/rook/rook/issues/5249
Signed-off-by: Sébastien Han <seb@redhat.com>
At startup there is a race condition between the goroutine checking
for mon health and the first reconcile of the mons. There is a lock
that ensures only one of them will check the mon health at a time.
The issue is that if the wrong one gets there first, it will not
have the desired mon count initialized from the cluster CR as expected
and the healther checker will use a desired mon count of 0.
The desired count of 0 leads the health checker to remove
a mon since there are extra mons. Only one mon is allowed
to be removed at a time, and adjusting to fewer than two mons is
disallowed once there are at least two mons.
After the health checker is completed, the main reconcile of the mons
will proceed with the correct desired mon count of 3 and attempt
to restore to the real desired quorum size.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The mon was starting with a partial spec. There was a race condition
that was causing incorrect initialization in the health check goroutine
that could remove a mon upon operator restart. Now the mon will be
properly initialized with the full spec.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The admin needs to start the toolbox and run a command such as ceph osd tree to see the device classes for each OSD. This PR simplifies it by storing the deviceclass info in the CephCluster CR status
closes: https://github.com/rook/rook/issues/5754
Signed-off-by: kesavan <kvellalo@redhat.com>
This commit:
- adds the pull section on the CephObjectRealm spec
to enables realms to be pulled instead of created.
- creates the system user and generates the access
key and secret key for the user and zones in a realm.
- adds "omitempty" to fields in multisite CRs that
are not required
Signed-off-by: Ali Maredia <amaredia@redhat.com>
Now, we can not only cleanup monitor data, logs and crashes but the
disks too. As part of the cleanupPolicy CR spec, we have a new setting
called sanitizeDisk which holds more details:
* method: indicates if the entire disk should be sanitized or simply ceph's metadata.
Possible choices are 'complete' or 'quick' (default)
* dataSource: indicate where to get random bytes from to write on the disk.
Possible choices are 'zero' (default) or 'random'
Using random sources will consume entropy from the system and will take much more time then the zero source
* iteration: overwrite N times instead of the default (1). Takes an integer value
See the documentation for more details.
Signed-off-by: Sébastien Han <seb@redhat.com>
The user creds should not be passed to the ceph helper methods
since the clusterInfo already has the needed context. Removing
a final reference that was missed in the refactor.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Sébastien Han
Travis Nielsen
Madhu Rajanna
Chen, Tingjie
Blaine Gardner
subhamkrai
kesavan
Ali Maredia