Conversation
…rtual workspace URL of the initws VW instead On-behalf-of: @SAP christoph.mewes@sap.com
|
@xrstf: The label(s) DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
On-behalf-of: @SAP christoph.mewes@sap.com
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SimonTheLeg The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
LGTM label has been added. DetailsGit tree hash: 05952f5c70ac6e9fc230171bf871cf1a77db49dc |
Summary
This PR adds the first e2e tests for the init-agent, ensuring the basic functionality.
I also included a fix for the multicluster code: It was accidentally using the kcp kubeconfig, i.e. it was creating new objects inside new workspaces using the
/clusters/...endpoint directly (which worked in my local testing becaue I used the admin kubeconfig from kcp). Instead the initcontroller has to use the virtual workspace endpoint (/services/initws/clusters/....). Since this URL is not available to the initcontroller (the multicluster provider has no way to pass it down to the controllers), all the controller has ismgr.GetCluster().GetClient().So to solve this, there is no longer a ClusterApplier, and the applier itself is not containing a client at all anymore. Instead it gets it passed in the
Apply()call. This is technically not the abstraction I head in mind for the applier, but alas.What Type of PR Is This?
/kind feature
Release Notes