-
Notifications
You must be signed in to change notification settings - Fork 23
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
Limit
s max_value
and name
field play no role in their identity…
#87
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -52,14 +52,14 @@ impl Storage { | |
self.limits.read().unwrap().keys().cloned().collect() | ||
} | ||
|
||
pub fn add_limit(&self, limit: Limit) { | ||
pub fn add_limit(&self, limit: Limit) -> bool { | ||
let namespace = limit.namespace().clone(); | ||
self.limits | ||
.write() | ||
.unwrap() | ||
.entry(namespace) | ||
.or_default() | ||
.insert(limit); | ||
.insert(limit) | ||
} | ||
|
||
pub fn get_limits(&self, namespace: &Namespace) -> HashSet<Limit> { | ||
|
@@ -140,19 +140,18 @@ impl AsyncStorage { | |
self.limits.read().unwrap().keys().cloned().collect() | ||
} | ||
|
||
pub fn add_limit(&self, limit: Limit) { | ||
pub fn add_limit(&self, limit: Limit) -> bool { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this change is interesting… what does it mean when now a It probably indicates an invalid config file, so in the case of:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, it interesting to account for what it'd mean when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. First, let's confirm that I understand by
I would say so. A CLI tool to validate config files would be nice too.
I would say, do not. I would prefer being fully rejected than accepted only some part. As payback for that constraint, the service should make it very clear if the changes have been accepted or not. Those are my options without taking into account implementation efforts. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I am not sure I follow. You mean add some info in the status of the RLP? FYI, check the schema of the RLP new design, limits:
- conditions: ["admin == yes"]
max_value: 500
seconds: 30
variables: [] no namespace (aka domain) is defined. It is up to the control plane to assign namespace to it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if two people define two "equivalent" What does that mean? Who (the operator, Limitador, ...?) makes what call? How is it then reflected on the individual CRs' status? How does that affect further changes (valid new Ideally, the operator would be able to "ignore" these CRs and compile to an always valid limitador limit file. But is this even possible? Do we need to duplicate logic? Expose some service to test a config before applying it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good questions here. The kuadrant control plane, the owner of the content in the Limitador CR in the kuadrant context, should do the validations. And if any conflict is found, reject the RLP adding the reason in the status field. The limitador operator can also run some validation checks to avoid such invalid limit definitions. I will think about that and add it to the proposal doc. This information should end up in the kuadrant's doc about the behavior of the control plane. |
||
let namespace = limit.namespace().clone(); | ||
|
||
let mut limits_for_namespace = self.limits.write().unwrap(); | ||
|
||
match limits_for_namespace.get_mut(&namespace) { | ||
Some(limits) => { | ||
limits.insert(limit); | ||
} | ||
Some(limits) => limits.insert(limit), | ||
None => { | ||
let mut limits = HashSet::new(); | ||
limits.insert(limit); | ||
limits_for_namespace.insert(namespace, limits); | ||
true | ||
} | ||
} | ||
} | ||
|
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 wonder if it makes sense to get rid of the limit included in the counter. This
update_to_limit
is solely to keep in sync limit objects representing the same. And it is the source of panic's because limits are not equal and should be.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… there are few places where these
Limit
s and/orCounter
s are juggled around with for … no real reason in the end. I do believe that the model should be moreNamespace
is composed ofLimit
s, which in turn may haveCounter
s associated with it… where some of that depends on theLimit
itself (i.e. does it have variables to qualifyCounter
s).There are few way this could be addressed tho and, as discussed in the sync this morning, I'd like to us all to decide on a design forward, one that accounts for the possible futures, e.g. multi-location
Limitador
s sharing counters.