This commit is a large refactor on how the operator starts, stops and
how it starts various sub-components such as the ceph-csi driver. It
also refines the way we cancel orchestrations. We don't use breakpoints
anymore but send our self a SIGUP to reload our controller runtime
manager.
The reload will happen under different circonstances like:
* a new adminission controller secret is created/deleted/changed
* a CephCluster CR is edited
As mentioned earlier, the csi driver now has its own controller, just
like flex. It reacts to change in the operator config map for particular
ROOK_CSI_ fields.
A second new controller for the operator's general config has been
created, it manages:
* the logging level
* the ceph CLI command timeout
* the discovery daemon
The operator reacts much more rapidly to cancellation events by stopping
the manager's context and reloading it.
Signed-off-by: Sébastien Han <seb@redhat.com>
This commit moves SetParams and ValidateCSIParam func
into go routine/lock, since it modifies/reads global CSIParam
variable.
Signed-off-by: Rakshith R <rar@redhat.com>
This commit changes CSI_ENABLE_HOST_NETWORK default value to true
since it was observed that cephfsvolume gets blocked when csi cephfs
nodeplugin is restarted and nodeunpublish call also hangs when
cephfs nodeplugin is using pod networking.
Updates: #8085
Signed-off-by: Rakshith R <rar@redhat.com>
CSI drivers failed to start if rook encountered error
while reading configmap with no retry.
This commit introduces retry for starting CSI driver
if there is a failure in reading configmap upto 3 times.
Fixes: #7950
Signed-off-by: Rakshith R <rar@redhat.com>
As host networking is no longer necessary for CSI driver,
it will be disabled by default.
An option CSI_ENABLE_HOST_NETWORK is added to rook-ceph-operator-config
configmap and enableCSIHostNetwork in helm chart values.yaml to
enable/disable host network in CSI plugin pods.
Closes: #7203
Signed-off-by: Rakshith R <rar@redhat.com>
It's better to validate ownerReferences when setting them. In addition, we should use
controllerrutil.Set{Controller,Owner}Reference, that have such validation, as possible.
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
The GRPC metrics exposed by both the provisioner pod
and the node plugin pod on some port. Provisioner pod
is running on the pod network and the daemonset pods
run on the host network. sometimes starting the GRPC
metrics by default can lead to node plugin pods
crashloopback state this is due to the port conflict.
Moreover, the GRPC metrics are not for the user it's
for the one which will help to debug the time taken
by cephcsi to serve each GRPC call. Enabling it by
default won't be a good idea. So the plan is to
disable it by default, If someone faces any issue it
can be enabled later at some point in time.
closes#7378
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Before this patch, csi detection will run whether or
not rbd and cephfs are all disabled. Run detection only
if it is necessary.
Signed-off-by: shenjiatong <yshxxsjt715@gmail.com>
Support ceph cluster and CSI on multus deployed in diffrent namespace.
Previously csi was looking for multus config from the cluster deployed
in the namespace in which rook-ceph-operator/csi was deployed.
Now it will look for multus configuration from ceph clusters from all
the namespaces.
Signed-off-by: rohan47 <rohgupta@redhat.com>
This adds the functionality to add custom pod labels to the CSI
components through the operator configuration way of env vars or config
map.
Resolves#6593
Signed-off-by: Alexander Trost <galexrt@googlemail.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>
remove csi drivers and delete k8s
services that drivers create,when
the default setting of drivers changed
to false.
Signed-off-by: subhamkrai <subhamkumarrai03@gmail.com>
The csi driver does not need to be started before the cluster
is created. When the csi driver fails to load, neither should
it prevent the cluster from being created. Therefore, we
initialize the basic constructs in the csi driver that are required
for cluster creation, then start the csi driver in a goroutine
so the cluster creation can continue. If the csi driver fails
or takes a long time to load, it will no longer affect cluster
creation.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Sébastien Han
Rakshith R
bipuladh
Satoru Takeuchi
Madhu Rajanna
shenjiatong
Arun Kumar Mohan
rohan47
Alexander Trost
subhamkrai
Travis Nielsen