Conversation
There is no longer a distinction between application and user limits.
We've moved the data one level deep into the context_info hash.
davidor
reviewed
Nov 22, 2019
| request_info = context_info['request'.freeze] || {} | ||
|
|
||
| transactions = parse_transactions(service_id, raw_transactions, request_info) | ||
| ProcessJob.perform(transactions, context_info) if !transactions.nil? && transactions.size > 0 |
Contributor
There was a problem hiding this comment.
The context info sent here is not used. Actually, ProcessJob.perform receives a hash of options but it only cares about whether it's a report for the master account. Maybe we should change that to simply receive a boolean.
Contributor
Author
There was a problem hiding this comment.
This was done this way because it follows a similar structure to other jobs' .perform methods, and avoids tying us to the specific usage the job makes of the context info. It's not a big deal, the work has to be done either there or here, but doing it here means knowing about what ProcessJob does inside.
unleashed
force-pushed
the
flat-usage-extension
branch
from
8773a33 to
07052ba
Compare
unleashed
force-pushed
the
flat-usage-extension
branch
from
07052ba to
291f0c5
Compare
davidor
reviewed
Jan 7, 2020
unleashed
force-pushed
the
flat-usage-extension
branch
from
291f0c5 to
82a86de
Compare
davidor
approved these changes
Jan 7, 2020
Contributor
|
bors r+ |
bors Bot
added a commit
that referenced
this pull request
Jan 7, 2020
142: Introduce "flat_usage" extension r=davidor a=unleashed This introduces the `flat_usage` extension. It is used to disregard hierarchy information when processing methods/metrics. The assumption is that the client _takes responsibility_, ie. `"I know what I'm doing"`, on computing how metrics have been affected taking the hierarchy in consideration, and Apisonator just processes the given usage data as if metrics had no parents. This is very _useful for caching_, as caches need to report changes in metrics back to Apisonator after some time, but that implies having to undo the work Apisonator will do to add values from children metrics to parent metrics, because such caches already need to compute these relationships to be able to authorize their own clients. Closes #140. We could potentially add different levels for the value taken by this extension so we would run sanity checks and refuse to process the usage data if such checks fail, but the potential benefits are marginal given this is mostly meant to be used with reporting calls (which we don't check at request time, and doing this would mean checking at that time to avoid clients flushing their usage data). PS. we should document the `hierarchy` extension. PS2. the name is not really set on stone, suggestions welcome. Co-authored-by: Alejandro Martinez Ruiz <alex@flawedcode.org>
Contributor
Author
|
Looks like bors has not recovered? :/ |
Contributor
Timed out |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This introduces the
flat_usageextension. It is used to disregard hierarchy information when processing methods/metrics. The assumption is that the client takes responsibility, ie."I know what I'm doing", on computing how metrics have been affected taking the hierarchy in consideration, and Apisonator just processes the given usage data as if metrics had no parents.This is very useful for caching, as caches need to report changes in metrics back to Apisonator after some time, but that implies having to undo the work Apisonator will do to add values from children metrics to parent metrics, because such caches already need to compute these relationships to be able to authorize their own clients.
Closes #140.
We could potentially add different levels for the value taken by this extension so we would run sanity checks and refuse to process the usage data if such checks fail, but the potential benefits are marginal given this is mostly meant to be used with reporting calls (which we don't check at request time, and doing this would mean checking at that time to avoid clients flushing their usage data).
PS. we should document the
hierarchyextension.PS2. the name is not really set on stone, suggestions welcome.