-
Notifications
You must be signed in to change notification settings - Fork 22
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
Configurable HAP Shared Secrets Plans and Regions #1609
Conversation
Add one of following labels |
Corrected property format to allow wildcards and restrictive plan:region pairs.
Corrected property format to allow wildcards and restrictive plan:region pairs.
I did a code review, and decided to left more high level review, please see: #1520 (comment) We will talk about that tomorrow |
sort.Strings(keys) | ||
|
||
output := "" | ||
for _, item := range keys { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why strings.Join is not appropriate?
Do we need the separator at the end?
"strings" | ||
) | ||
|
||
type Whitelist map[string]struct{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We define some date structure (even kind of ADT) but we use the name not related to its behavior. There is nothing about whitelisting
, just set of strings with contains operation.
<!-- selection algorithm --> | ||
When selecting a Secret for a given hyperscaler, KEB evaluates a set of rules to determine what secret bindings it should query for a given plan and region that SKR is provisioned in. The search looks for a secret bindings with `hyperscaler-type` label only (always used in the search) or additionally with one of or both `euAccess: true` and `shared: true` labels. | ||
|
||
`hyperscaler-type` label is the one that does contain region information in the format `hyperscaler_type: <HYPERSCALER_NAME>[_<PLATFORM_REGION>][_<CLUSTER_REGION>]`, where both `_<PLATFORM_REGION>` and `_<CLUSTER_REGION>` are optional. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we stick to hyperscaler region
(HYPERSCALER_REGION accordingly) as in #1520
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want something shorter. HAP_REGION?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CLUSTER_REGION is a known name in the documentation used in https://github.com/kyma-project/kyma-environment-broker/blob/main/docs/user/05-10-provisioning-kyma-environment.md#steps, https://github.com/kyma-project/kyma-environment-broker/blob/main/docs/user/05-70-manage-kyma-environment-through-cis-provisioning-service.md#steps. I want to hear our the teams' opinion which naming to use. I was familiar with CLUSTER_REGION and PLATFORM_REGIONS abstractions.
POC. I am dividing the PR into smaller chunks. |
Pull request was closed
Description
The following PR implements #1520 feature request. It introduces two configuration lists that allows for specifying which plans or platform regions should be provisioned with shared gardener secrets.
Changes proposed in this pull request: