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
jsonDataLimit#4055 #4233
jsonDataLimit#4055 #4233
Conversation
b067889
to
fc69dc1
Compare
The following jobs failed:
Automatically retrying due to test flakiness... |
// replicate it here. | ||
|
||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | ||
type PingTemplateSpec 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.
why is this needed?
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.
It generates the deepcopy for store. Model pattern as channel store
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 is quite confusing. For channel it's different because the config and the spec are the same. That's not the case for PingSource. I would remove this and just use PingDefaults
. WDYT?
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'll investigate that. Currently, preoccupied with something else will get back ASAP. Thanks
|
||
// Package config holds the typed objects that define the schemas for | ||
// ConfigMap objects that pertain to our API objects. | ||
package config |
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.
can we move all files in this package into apis/source/config
?
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.
yeah +1 on relocating all of those
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.
What if we have future sources with a config? The thought behind doing this was to allow pkg/apis/sources/config/somenewsource/... ?
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.
flattening does not prevent adding defaults for other sources, does it?
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.
Probably not. And I'll go ahead and do this change. I'm on the record :) that keeping them separate while maybe not necessary would be cleaner IMO
knative.dev/example-checksum: "6eaeecba" | ||
data: | ||
default-ping-config: | | ||
################################ |
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.
Example part should be put under _example: |
, see example here:
_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 think the confusion was I copied the example comment block. I'm now following what was done with default-broker.yaml, default-broker-channel.yaml, and default-channel.yaml
} | ||
|
||
// NewPingDefaultsConfigFromConfigMap creates a PingDefaults from the supplied configMap | ||
func NewPingDefaultsConfigFromConfigMap(config *corev1.ConfigMap) (*PingDefaults, error) { |
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.
Do you need to handle nil
?
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.
no present on a nil map comes back as false.
apiVersion: v1 | ||
kind: ConfigMap | ||
metadata: | ||
name: default-ping-webhook |
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'd rather pick a different name. Almost all CMs in evneting start with config-
- except for default-ch-webhook
, unfortunately
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.
@matzew Ok I followed that. Given the importance of this conformance can you open a issue for this?
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've reconsidered. I think the confusion was I copied the example comment block. I'm now following what was done with default-broker.yaml, default-broker-channel.yaml, and default-channel.yaml
fc69dc1
to
b83317d
Compare
b83317d
to
aa94a97
Compare
Codecov Report
@@ Coverage Diff @@
## master #4233 +/- ##
==========================================
+ Coverage 81.35% 81.39% +0.04%
==========================================
Files 292 292
Lines 8322 8341 +19
==========================================
+ Hits 6770 6789 +19
Misses 1144 1144
Partials 408 408
Continue to review full report at Codecov.
|
This pull request introduces 1 alert when merging aa94a97 into c3e71f5 - view on LGTM.com new alerts:
|
aa94a97
to
faea835
Compare
The following is the coverage report on the affected files.
|
I think I addressed all. |
@cr22rc is there a use case or existing problem that need this? Generally I think it worth bring it up in the eventing meeting (we happened to discuss this week that we should revisit long living PRs in the meeting). Or a discussion in Slack can also be useful. |
if d.DataMaxSize < 1 { | ||
d.DataMaxSize = 4096 | ||
} |
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.
If we reserve the default to be 0, which means unlimited, we can achieve backward compatibility.
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 don't think that's good admins can install this not know that user could dump large amount of data into their etcd .. Better for user to get a good message that it's limited and admin can adjust
Another concern is that I am not sure if a global configmap is a good option for this. IIUC, this can be per source based right? Did you consider adding it as a ping source attribute? This way each one can have a different setting. |
We don't want user to create unlimited sized messages. Just ading that to the pingsource does not stop them. In reality the data is not much used since it just static. 4096 probably far exceeds what most user will every put in. |
faea835
to
3bba87b
Compare
knative.dev/example-checksum: "6eaeecba" | ||
data: | ||
ping-config: | | ||
# dataMaxSize: 4096 # Max number of bytes allowed to be sent for message excluding any base64 decoding. |
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 see an example checksum, but no _example
key in the configmap.
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.
Good point. knative.dev/example-checksum: "6eaeecba"
Is not needed here.
if test.source.Spec.JsonData == "TOBIG" { | ||
var b strings.Builder | ||
b.Grow(5000) | ||
b.WriteString("\"") | ||
for i := 0; i < 4998; i++ { | ||
b.WriteString("a") | ||
} | ||
b.WriteString("\"") | ||
test.source.Spec.JsonData = b.String() | ||
} |
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 just declare a variable with that buffer initialized before the tests?
source: PingSource{ | ||
Spec: PingSourceSpec{ | ||
Schedule: "*/2 * * * *", | ||
JsonData: "TOBIG", |
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.
"Too" takes 2 "O".
That's one possible trade-off, with the advantage that it can be directly be implemented by using k8s quotas. Another trade-off is to limit the CR size, and AFAIK that's not something k8s supports right now, am I right? |
It doesn't indeed, but I still don't understand, why focusing on just the PingSource? It seems to me like a careful Kubernetes admin would limit this globally using either
This issue can apply to literally any Kubernetes object: you could create 1.5 MB of annotations, and a ConfigMap would be helpless in preventing that. Even if it wasn't, I doubt anyone would want to go ahead and create one ConfigMap per Kubernetes type (good luck). Just my 2c, but to me it feels like the wrong place and the wrong way to address such a broad concern and I'm surprised to see this in Knative. |
To be clear: this PR is not about limiting the size of CRs, it is about fairness. It's about making sure a tenant does not allocate all available resources. For PingSource, there is a direct link between CR size and fairness, thus this PR. As for the implementation, I agree it could be generalized but for now it's really only applicable to PingSource. (and please keep discussing) |
Default is unbounded. Signed-off-by: rickr <cr22rc@users.noreply.github.com>
3bba87b
to
9244b69
Compare
/approve /hold to address comments. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cr22rc, lionelvillard 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 |
Changed so the default for data length is not checked. |
/unhold |
/lgtm |
this change seems to be breaking downstream for us. Particularly having an empty
Why is the intermediate field |
@cr22rc Do you think this is a problem for migrations? |
I'd vote to revert this, before we cut the release - since it does have issues |
This reverts commit 84b99db.
I think the fix is just to set limit |
I'm still not sure how the scenario is that this fails. I doesn't fail locally nor did it on the e2e tests. |
@matzew I'd vote for this as well. Besides, not all PR comments were addressed, including some important ones regarding the ConfigMap itself: |
I would vote we revert this as well. We're getting the same errors as posted by @lberk |
Signed-off-by: rickr cr22rc@users.noreply.github.com
Fixes #
see #4055
Proposed Changes
Provide configmap with jsonData max bytes enforce in validating webhook.
By default jsonData max bytes is 4096 bytes.