-
Notifications
You must be signed in to change notification settings - Fork 74
Add configuration for data residency #1681
Add configuration for data residency #1681
Conversation
This PR and the issue is open to input about if we should keep a config map called "config-data-residency" or make it larger scope to "config-gcp-features" which is what I am using now. |
/assign @yolocs |
8e15fb7
to
0b884c2
Compare
# messagestoragepolicy.allowedpersistenceregions field specifies | ||
# all the allowed regions for data residency. The default or an empty value will | ||
# mean no data residency requirement. | ||
messagestoragepolicy.allowedpersistenceregions: "us-east1,us-west1" |
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.
Since we are essentially dealing with YAML, can this be a list of strings, rather than a csv?
messagestoragepolicy.allowedpersistenceregions: "us-east1,us-west1" | |
messagestoragepolicy.allowedpersistenceregions: | |
- us-east1 | |
- us-west1 |
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.
Agreed. This field is a field used in the topic config, I was thinking to simply pass whatever in the field to the topic config, but I think the topic is also using []string
.
e4b205d
to
4179e22
Compare
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.
Update the release note section in the description with something like "Add data residency configmap placeholder"
name: config-data-residency | ||
namespace: cloud-run-events | ||
data: | ||
_example: | |
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'm fine with creating such a placeholder since it does nothing. But I'm looking for more details on how this will be used.
- How this configmap will be read? Volume mount? Watch?
- Do you allow finer grained control? Like per broker? How it would impact the configmap structure?
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 will add the actual code for this configuration to this PR too. For your question:
-
This is still being discussed, but watch seems better since our system already uses watch for other config maps, also, it provides easier interface for reacting to the change.
-
Personally I think even if we allow per broker configuration, this will still serve as a default and same configuration will be added to per broker and get reconciled by the broker controller instead.
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.
This PR has been extended to have the full implementation, so to answer this original question:
- The configmap is read through watch from
Store
object. - For now, we only support cluster wide, but we can for sure add per namespace or broker in the future. Note that triggers also create new topics, but topics for retry should be same as the main broker topic.
Open for suggestions: I have added a default config to the data residency. However, since the data residency really is optional, I am treating empty or non key as no configuration so that it will allow all region too. The only downside I can think of is that it will not catch typos in keys like
Any suggestions? |
I personally think it is better to make this its own commit, and the logic to propagate to controller etc another one, as it will make the history look cleaner. |
db592fc
to
a61b0d5
Compare
…em, rename config-data-residency.yaml to make it consistent with other files
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.
Thanks @zhongduo!
Looks like we're missing a few tests. All my other comments are optional nits.
|
||
# default-dataresidency-config is the configuration for determining the default | ||
# data residency to apply to all objects that require data residency but, | ||
# do not specify it. This is expected to be Channels and Sources. |
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.
Remove but, do not specify it
. That is already implied by "default data residency".
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.
Fix as suggested.
|
||
# default-dataresidency-config is the configuration for determining the default | ||
# data residency to apply to all objects that require data residency but, | ||
# do not specify it. This is expected to be Channels and Sources. |
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 think it's Channels, Sources, and Brokers
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.
Fixed as suggested.
|
||
const ( | ||
// configName is the name of config map for the default data residency that | ||
// Sources and brokers should use. |
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.
Maybe clearer to say "the default data residency that GCP resources should use"
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.
Fixed as suggested.
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.
Very close. I have one more testing request (test for empty AllowedPersistenceRegions) and one optional suggestion.
pkg/reconciler/broker/broker_test.go
Outdated
messagestoragepolicy.allowedpersistenceregions: | ||
- us-east1`, | ||
}, | ||
}, |
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.
Optional: I recommend moving this declaration to a test helper function so it takes up less space and can be shared across multiple reconcilers. Something like:
"dataResidencyConfigMap": DataResidencyConfigMap("us-east1")
Test helpers are in pkg/reconciler/testing.
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.
Fixed as suggested.
pkg/reconciler/broker/broker_test.go
Outdated
@@ -304,6 +308,63 @@ func TestAllCases(t *testing.T) { | |||
TopicExists("cre-bkr_testnamespace_test-broker_abc123"), |
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 can increase coverage by changing this to TopicExistsWithConfig
so it verifies AllowedPersistenceRegions is empty by default. Would you mind making that change here and in the trigger tests?
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.
Fixed as suggested.
This is fine for now - it's the same behavior for our other configmaps. A future improvement can add validation webhooks to verify configmap structure. |
Oops, I was wrong about this. We do validate the structure of other configmaps, see https://github.com/google/knative-gcp/blob/master/cmd/webhook/main.go#L171. Adding that can be a followup PR. |
The following is the coverage report on the affected files.
|
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.
Thanks @zhongduo!
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: grantr, zhongduo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-google-knative-gcp-wi-tests |
/retest |
1 similar comment
/retest |
The following jobs failed:
Job pull-google-knative-gcp-wi-tests expended all 3 retries without success. |
/test pull-google-knative-gcp-wi-tests |
Fixes #1680
Proposed Changes
Release Note
Docs