-
Notifications
You must be signed in to change notification settings - Fork 707
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CI coverage for environment where kubeappsCluster is empty. #4563
Labels
component/ci
Issue related to kubeapps ci system
kind/enhancement
An issue that reports an enhancement for an implemented feature
Milestone
Comments
ppbaena
added
the
kind/feature
An issue that reports a feature (approved) to be implemented
label
Apr 21, 2022
ppbaena
added
kind/enhancement
An issue that reports an enhancement for an implemented feature
and removed
kind/feature
An issue that reports a feature (approved) to be implemented
labels
Sep 5, 2022
castelblanque
added a commit
that referenced
this issue
Oct 26, 2022
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com> ### Description of the change Adapted version of the outdated PR #4591. After removing kubeops, there has been a refactor of places changes by the old PR. It fixes the scenario in which the cluster where Kubeapps is installed is not part of the configured list of clusters. For example: ```yaml clusters: - name: second-cluster domain: ... apiServiceURL: .... certificateAuthorityData: ... serviceToken: eyJhbGciOiJS... ``` For doing so, it uses a token to reference the Kubeapps cluster: `-`. Also empty string `''` is accepted as cluster reference, for allowing payloads in which there is no cluster specified in context. Therefore, if a cluster string is empty or `-`, backend logic assumes that the Kubeapps cluster will be used. ### Benefits User can work in a multicluster setups in which the Kubeapps cluster is not part of the allowed clusters. ### Possible drawbacks N/A ### Applicable issues - fixes #4564 ### Additional information Manual tests have been done with Helm plugin (only one working in multicluster so far). CI E2E test will be done in #4563 Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
castelblanque
added a commit
that referenced
this issue
Nov 3, 2022
…ist (#5573) ### Description of the change This PR adds an E2E test in CI to avoid regression on #5566 and hence to avoid that #4564 happens again. ### Benefits Kubeapps is usable even if Kubeapps cluster is not among the clusters configured. ### Possible drawbacks N/A ### Applicable issues - fixes #4563 Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Repository owner
moved this from 🔎 In Review
to ✅ Done
in Kubeapps
Nov 3, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
component/ci
Issue related to kubeapps ci system
kind/enhancement
An issue that reports an enhancement for an implemented feature
Description:
We had a regression after v2.4.1 for the environment where Kubeapps is installed on one cluster, but configured so that users operate only on other clusters (ie. they can't install or even select the cluster on which Kubeapps is installed). In this scenario, the
kubeappsCluster
config option to the dashboard is empty (and in the past, the kubeappsapis service would assume that if it's empty, it'd use thekubeappsCluster
where as it's now correctly required by the apisserver and we missed a place where the dashboard is not sending it).This is a useful scenario that we've explicitly designed for in the past, so it'd be great to add a CI test for this environment.
Thanks @aanthonyrizzo for debugging and finding a solution. Anthony plans to push his fix for the dashboard itself separately, this issue is just to ensure that longer term we cover that use-case in CI.
The text was updated successfully, but these errors were encountered: