Usage license #205
Usage license #205
Conversation
| * header: This is a JSON object with two properties: | ||
| * typ: should be "Harper-License" | ||
| * alg: should be "EdDSA" |
There was a problem hiding this comment.
Not sure how this will eventually be rendered, but maybe the properties should be code?
| * header: This is a JSON object with two properties: | |
| * typ: should be "Harper-License" | |
| * alg: should be "EdDSA" | |
| * `header`: This is a JSON object with two properties: | |
| * `typ`: should be "Harper-License" | |
| * `alg`: should be "EdDSA" |
| "realTimeBytes": 40000000000000, | ||
| "cpuTime": 108000, | ||
| "storage": 400000000000000, | ||
| "expiration":"2025-07-25T21:17:21.248Z" |
There was a problem hiding this comment.
| "expiration":"2025-07-25T21:17:21.248Z" | |
| "expiration": "2025-07-25T21:17:21.248Z" |
| The three base64 blocks are combined to form the `license` property value in the operation. | ||
|
|
||
| - operation _(required)_ - must always be `install_usage_license` | ||
| - license _(required)_ - This is the combination of the three blocks in the form header.payload.signature |
There was a problem hiding this comment.
Elsewhere the value is rendered as inline code.
| - license _(required)_ - This is the combination of the three blocks in the form header.payload.signature | |
| - license _(required)_ - This is the combination of the three blocks in the form `header.payload.signature` |
| "cpuTime": 108000, | ||
| "usedCpuTime": 41000, | ||
| "storage": 400000000000000, | ||
| "expiration":"2025-07-25T21:17:21.248Z" |
There was a problem hiding this comment.
| "expiration":"2025-07-25T21:17:21.248Z" | |
| "expiration": "2025-07-25T21:17:21.248Z" |
| "cpuTime": 108000, | ||
| "usedCpuTime": 0, | ||
| "storage": 400000000000000, | ||
| "expiration":"2025-09-25T21:17:21.248Z" |
There was a problem hiding this comment.
| "expiration":"2025-09-25T21:17:21.248Z" | |
| "expiration": "2025-09-25T21:17:21.248Z" |
| ] | ||
| ``` | ||
|
|
||
| --- |
There was a problem hiding this comment.
Not sure what's going on here. Past merge conflict?
|
|
||
| Install a Harper license for a block of usage. Multiple usage blocks may be installed, and they will be used up sequentially, with the earliest installed blocks used first. A license is installed | ||
| by creating a string that consists of three base64 encoded blocks, separated by dots. The three blocks consist of: | ||
| * header: This is a JSON object with two properties: |
There was a problem hiding this comment.
It seems else where in this page and on other page we are using - for lists, not *. We should be consistent.
| * realTimeBytes _(required)_ - The number of allowed real-time message bytes | ||
| * cpuTime _(optional)_ - The allowed amount of CPU time consumed by application code | ||
| * storage _(optional)_ - Maximum of storage that may be used | ||
| * expiration _(required_) - The date when this block expires, as an ISO date |
There was a problem hiding this comment.
s/required_)/required)_/
| * storage _(optional)_ - Maximum of storage that may be used | ||
| * expiration _(required_) - The date when this block expires, as an ISO date | ||
|
|
||
| This JSON object should be converted to base64 (conversion from utf-8 to base64) and is the second base64 block. |
There was a problem hiding this comment.
This makes me wonder if we need any JSON normalization in here... Otherwise differences that a JSON parser would ignore might result in different base64 encodings.
There was a problem hiding this comment.
Isn't the signing of the JSON based on the generated licenses stringification? It seems like the signer can dictate all of that itself without coordination? But if coordination is needed, maybe we can just say without any extra/unnecessary spacing? (the default for JSON.stringify).
| * typ: should be "Harper-License" | ||
| * alg: should be "EdDSA" | ||
|
|
||
| This JSON object should be converted to base64 (conversion from utf-8 to base64) and is the first base64 block. |
There was a problem hiding this comment.
I used base64url encoding originally (mostly just because it's what JWTs use and it seemed the safer choice overall). So unless you changed that, we should specify that here.
There was a problem hiding this comment.
I did not change the code, so yes, make it base64url if that is the behavior.
|
|
||
| This will retrieve and return all active usage licenses, with counts of how much of the limits have been consumed. | ||
|
|
||
| - operation _(required)_ - must always be `install_usage_license` |
There was a problem hiding this comment.
Should be get_usage_licenses
| { | ||
| "id": "license-717b-4c6c-b69d-b29014054ab7", | ||
| "level": 2, | ||
| "regionId": "us-nw-2", |
There was a problem hiding this comment.
This attribute is just called region currently.
There was a problem hiding this comment.
Region makes sense to me because of the way we have region + latency sort of grouped together in the block pricing
|
|
||
| * license payload: This is a JSON object with properties: | ||
| * id _(required)_ - A unique id for the license | ||
| * level _(required)_ - Usage level number |
There was a problem hiding this comment.
There was no description of this attribute in the original ticket, so the code currently expects it to be a string. I can adjust it to expect a number, but is there any more context about what this value is and any other constraints that should be placed on it?
There was a problem hiding this comment.
This corresponds to the different levels from https://harperdb.atlassian.net/wiki/spaces/SD/pages/34209804/HarperDB+Usage+Pricing+and+Tracking. I don't think we have any functional behavior that depends on this (right now), so it is just informational. We could make this optional (and any type of if that is easier).
|
Closing in favor of #220 |
No description provided.