Conversation
README.md
Outdated
|
|
||
| #### Example 4 | ||
|
|
||
| The Ratelimit service matches requests to configuration entries with the same depth level. For instance, the following request: |
There was a problem hiding this comment.
It might be nice to define what you mean by depth level.
| @@ -265,7 +265,11 @@ func (this *rateLimitConfigImpl) GetLimit( | |||
|
|
|||
| if nextDescriptor != nil && nextDescriptor.limit != nil { | |||
| logger.Debugf("found rate limit: %s", finalKey) | |||
There was a problem hiding this comment.
should this logger statement be moved into the if below?
There was a problem hiding this comment.
I dont think so. In debug we want to know about all the ratelimits found, the next logger message would let us know if the ratelimit was not chosen.
| &pb.RateLimitDescriptor{[]*pb.RateLimitDescriptor_Entry{{"key2", "value2"}, {"subkey", "subvalue"}}}) | ||
| assert.Nil(rl) | ||
|
|
||
| rl = rlConfig.GetLimit( |
There was a problem hiding this comment.
What are you trying to test here?
There was a problem hiding this comment.
The config did not get pushed in the branch. Just updated. I am testing that RL will not return a limit for two tuples, even though there was a descriptor with less nesting in the config that matched.
|
Once #2 has been merged, please update this pr to use consistent language when referring to depth vs descriptor list level example :https://github.com/lyft/ratelimit/blob/e6eb371b25f2214027f352c80a7ea56d86793cb7/README.md#descriptor-list-definition |
README.md
Outdated
| *attempt the most specific match possible*. This means both the most nested matching descriptor entry, as well as | ||
| the most specific at any descriptor list level. Thus, key/value is always attempted as a match before just key. | ||
| *attempt the most specific match possible*. This means | ||
| the most specific descriptor at the same level as your request. Keep in mind that equally specific descriptors are matched on a first match basis. Thus, key/value is always attempted as a match before just key. |
There was a problem hiding this comment.
Can you rewrite the second sentence Keep in mind... what determines what is first? Order specified in the config?
There was a problem hiding this comment.
I take that sentence back.
README.md
Outdated
| ## Loading Configuration | ||
|
|
||
| The Ratelimit service uses a library written by Lyft called [goruntime](https://github.com/lyft/goruntime) to do configuration loading. Goruntime monitors | ||
| >>>>>>> master |
README.md
Outdated
| ``` | ||
|
|
||
| And the service with rate limit against *all* matching rules and return an aggregate result. | ||
| And the service with rate limit against *all* matching rules and return an aggregate result; a logical OR of all |
| #### Example 4 | ||
|
|
||
| The Ratelimit service matches requests to configuration entries with the same level, i.e | ||
| same number of tuples in the request's descriptor as nested levels of descriptors |
There was a problem hiding this comment.
nit: should this same level description go up higher? I don't know...
There was a problem hiding this comment.
You could argue for or against. Each example explains something about matching, and how this works so it takes all four examples to understand.
README.md
Outdated
| descriptor: ("key", "value"),("subkey", "subvalue") | ||
| ``` | ||
|
|
||
| Would **not** match the following configuration, even though the first descriptor in |
@lyft/network-team
The following request:
Would match the following config:
Arguably the request should not match that config, it should only match a config entry like this:
So in general the ratelimit service should match the most specific rule with the same depth level as the request.