When setting dashboard.ssl: false the value is left out of the CRD and the MGR is setup with ssl as true for the dashboard
#13577
Assignees
Labels
Comments
|
Please share your cluster CR (cluster.yaml) and the rook operator log. If you change this setting to false, it's not expected that the dashboard will be configured for ssl. |
|
cluster.yaml in file cluster.yaml in K8s |
|
logs from MGR |
|
I tried a fresh install with Rook at version |
|
I'm troubleshooting a different issue unrelated, but I did notice this issue as well when reviewing Ceph dashboard docs, was surprised to see this mismatch. In my cluster Yet, when I check with Ceph: Regardless, my dashboard is up and available. |
|
So it was noted that the Operator is setting the |
|
Note that the pg_autoscaler cannot be disabled anymore, so you can remove it from your config to avoid this error: |
If the Back to the original issue, so you're not seeing the correct |
Still listed in Rook values.yaml example, should probably be removed if no longer optional: |
I did some testing on my local cluster and was not able to reproduce the issue you are describing: dashboard is configured according to what the user states in cluster YAML file (either true or false): Besides, I think you was experimenting a mismatch because you was not consulting the correct mgr instance configuration. Internally the configuration is stored for each mgr instance. At any moment the dashboard picks the configuration from the active mgr. For example, if you active mgr is In summary: to avoid confusion please try to adjust the value in the |
|
@rkachach I was checking the cluster wide setting not any specific mgr, what's the benefit of setting it on the active manager and not the cluster wide setting? If you fail over Rook then had to apply all settings to the new mgr instead of it just having all of the config. |
@ADustyOldMuffin I need to look into it in more detail, but that would take some time. |
|
👍🏻 I checked and Rook detected the fail over fast enough that I didn't notice anything, but it does have to re-apply all settings. I can keep this open for looking into possibly applying it at a higher level than the individual daemons or I think we can close this. |
Ah yes, that's an old example we need to remove. Now the autoscale configuration is a per-pool ceph config. |
|
You should set a port. After hours I found out that the configuration for Values file that result in correct cephClusterSpec:
dashboard:
enabled: true
port: 8080
ssl: falseResults:
Values file that resulted in missconfiguration in the mgr. cephClusterSpec:
dashboard:
enabled: true
ssl: falseResults:
Expected results:
|
|
I encountered the same issue on version 1.13.2. Regardless of how I modify the |
|
I believe this issue may be related to #10110. After creating and applying |
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 22, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 22, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 22, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 22, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
6 tasks
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 22, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
@ADustyOldMuffin Your findings were key to narrow down the issue. In fact, the issue has to do with the way Rook was handling dashboard configuration by using per-daemon conf which is different from the behavior of the dashboard on cephadm deployments where global mgr conf section is used. This also explains some old weird BUGs related to the dashboard configuration inconsistencies. I've opened a PR with a candidate fix 👍 |
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 23, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
rkachach
added a commit
to rkachach/rook
that referenced
this issue
Jan 25, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: rook#13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com>
mergify bot
pushed a commit
that referenced
this issue
Jan 26, 2024
previously, the dashboard parameters supported by Rook were stored in the daemon configuration section (mgr.X, for example). This differs from Cephadm-based deployments, where all configurations are stored in the global mgr configuration section. This variance could result in configuration mismatches between the active and standby dashboards. Furthermore, all Ceph dashboard documentation exclusively points to the global mgr configuration section and makes no use of individual daemons sections. Fixes: #13577 Signed-off-by: Redouane Kachach <rkachach@redhat.com> (cherry picked from commit 57e3937)
|
Something is still not working here. I am making a fresh rook-ceph install using rook-ceph-cluster helm chart version v1.13.4 (which the above PR should be in AFAICT) My mgrs are complaining: My helm chart values has: However the |
|
@Ramblurr I'll try to reproduce the issue using your yaml values |
|
@Ramblurr was this a temporal circumstance or dashboard didn't manage to be configured correctly? I tried to simulate the same setup on my env and I can see that in the first startup the certificates are not yet there but then it get fixed in the following mg restart and the dashboard is eventually correctly configured: Logs from my mgr: I also tested switching off SSL on the cluster by setting |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a bug report or feature request?
Deviation from expected behavior:
When I set the
dashboard.ssl: falsevalue but enable the dashboard in the cluster CRD the MGR is still looking for SSL and when inspecting ceph config the ssl value for the dashboard is set to true.Expected behavior:
SSL to not be configured and set to false in the config.
How to reproduce it (minimal and precise):
Create a new CephCluster and set the
dashboard.ssl: falsefield in the CRD. Load the cluster, and check logs of the MGR and see it complaining, you can also runceph config get mgr mgr/dashboard/ssland view that it resolves totrue.If you output the yaml for the ceph-cluster the field
dashboard.sslwill also be missing, but if you edit it and add it back then it will stay.I am also creating the CRD via a custom helm chart.
File(s) to submit:
Cluster CRD can be any values just with the field above set.
Logs to submit:
None
The text was updated successfully, but these errors were encountered: