This commit adds recording rules to monitor aggregated (requested and used) capacity of the PVCs for block and file type PVCs, via the telemeter.
Signed-off-by: Anmol Sachan <anmol13694@gmail.com>
as we are going to deploy snapshotter by
default we are going to remove the kubernetes
version check.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
To ensure a file handle is closed, we defer the close command
so it is guaranteed to run when the method returns. The closing
of the file handle is not going to fail in our usage since we aren't
using the SetDeadline on the files that would cancel a request
and return an error.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Added a provisioner toleration to the csi version
check job, so that we can schedule the csi version
check on the node where the nodes are tainted.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
If the AllowUnsupported flag is set to true we should
not check the csi version as it will be kind of no-op
as even incase of failure we continue. if we disable
the version check in this case,the deployment will
be little faster as we dont wait for version check
to complete to start CSI pods.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The new CephObjectStore code now has an external property and we won't
require the endpoint to be set manually anymore on the SC. The
lib-bucket code will detect it through the name of the object store.
Signed-off-by: Sébastien Han <seb@redhat.com>
Somehow, the client.Update was not updating the cluster object, using
client.Status().Update actually fixed it.
Signed-off-by: Sébastien Han <seb@redhat.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>
When we run the goroutine, we should run start it immediately instead of
waiting for the configured interval to start. With that we can get the
Status Phase reported much faster in the CRD.
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>