馃摉 Document how storage keys are computed for workspaces #1905
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign @stevekuznetsov @sttts |
|
I think as far as user-facing docs, #1086 is likely going to answer more questions than this one, so at the least we should get both in. |
| Everything else, like a workspace name, is added dynamically. | ||
| For example, a request with a URL of `/clusters/acme/core/secrets` finds a storage responsible | ||
| for `core/secrets` resources and adds `acme` to the `ResourcePrefix`. | ||
| The new string becomes a key that is passed to etcd to find only resources for `acme` cluster. |
There was a problem hiding this comment.
if there is anything, in particular, we would like to see documented, let me know, I could expand this doc.
There was a problem hiding this comment.
I was also thinking about documenting PartialObjectMetadata requests and their relation to the generic storage.
| @@ -0,0 +1,74 @@ | |||
| ### workspaces | |||
|
|
|||
| kcp promises to support 1 mln of workspaces. | |||
There was a problem hiding this comment.
| kcp promises to support 1 mln of workspaces. | |
| kcp's goal is to support 1 million of workspaces. |
| ### etcd | ||
|
|
||
| etcd is the primary datastore used by kcp. | ||
| It stores data in a key-value store. |
There was a problem hiding this comment.
| It stores data in a key-value store. | |
| It stores data as key-value. |
One "store" less.
| The store鈥檚 logical view is a flat binary key space. | ||
| The key space has a lexically sorted index on byte string keys. | ||
|
|
||
| In order to create a logical hierarchy, keys are usually mixed with `/` e.g. `/company/branch/location` |
There was a problem hiding this comment.
| In order to create a logical hierarchy, keys are usually mixed with `/` e.g. `/company/branch/location` | |
| In order to create a logical hierarchy, keys are usually structured with `/` e.g. `/company/branch/location` |
| foo | ||
| ``` | ||
|
|
||
| Note that those queries are based on byte comparisons. |
There was a problem hiding this comment.
| Note that those queries are based on byte comparisons. | |
| Note, that those queries are based on byte comparisons. |
| For example, `secrets` resources in the `core` API group gets their own storage. | ||
|
|
||
| From the perspective of this document, we can assume that the most important feature of generic storage | ||
| is to compute the key that is passed to the database to find the data the user wants. |
|
|
||
|  | ||
|
|
||
| When the server starts it precomputes the `ResourcePrefix` with a group and a resource name. |
There was a problem hiding this comment.
| When the server starts it precomputes the `ResourcePrefix` with a group and a resource name. | |
| When the server starts, it precomputes the `ResourcePrefix` with a group and a resource name. |
ncdc
changed the title
ncdc
changed the title
|
@p0lyn0mial: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@p0lyn0mial I've moved what was in 1086 to #2867. Would you be interested in adding to that doc? Or do you want to close this? |
sure, I would like to move it to https://github.com/kcp-dev/kcp/tree/main/docs/content/developers. Also please let me know when you you think it doesn't bring any value. |
|
@kcp-dev/kcp-contributors lets pick this up? |
|
/lgtm We can iterate. Just docs. |
|
LGTM label has been added. Git tree hash: 20a00fe8326fb70474cf9d74bee29afa098baf7e
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sttts 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 |
kcp-ci-bot
added
the
approved
|
/retest |
kcp-ci-bot
added
the
dco-signoff: yes
kcp-ci-bot
added
the
size/M
Summary
Initially, I wanted to document the mapping of a URL to a storage prefix. However, there seems to be an open PR addressing that.
Instead, I've decided to describe how a storage key is computed and why it matters.
It could complement #1086, we don't have to merge it if it doesn't add any value.
Related issue(s)
Fixes #