2021-07-07 07:04:09 +00:00
|
|
|
[package]
|
|
|
|
|
name = "pbs-api-types"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
authors = ["Proxmox Support Team <support@proxmox.com>"]
|
|
|
|
|
edition = "2018"
|
|
|
|
|
description = "general API type helpers for PBS"
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
2021-07-07 07:53:48 +00:00
|
|
|
anyhow = "1.0"
|
2021-11-17 06:07:40 +00:00
|
|
|
hex = "0.4.3"
|
2021-07-07 07:04:09 +00:00
|
|
|
lazy_static = "1.4"
|
2021-11-25 10:48:52 +00:00
|
|
|
percent-encoding = "2.1"
|
2022-03-09 08:55:36 +00:00
|
|
|
regex = "1.5.5"
|
2021-07-07 07:53:48 +00:00
|
|
|
serde = { version = "1.0", features = ["derive"] }
|
api-types: add BackupNamespace type
The idea is to have namespaces in a datastore to allow grouping and
namespacing backups from different (but similar trusted) sources,
e.g., different PVE clusters, geo sites, use-cases or company
service-branches, without separating the underlying
deduplication domain and thus blowing up data and (GC/verify)
resource usage.
To avoid namespace ID clashes with anything existing or future
usecases use a intermediate `ns` level on *each* depth.
The current implementation treats that as internal and thus hides
that fact from the API, iow., the namespace path the users passes
along or gets returned won't include the `ns` level, they do not
matter there at all.
The max-depth of 8 is chosen with the following in mind:
- assume that end-users already are in a deeper level of a hierarchy,
most often they'll start at level one or two, as the higher ones
are used by the seller/admin to namespace different users/groups,
so lower than four would be very limiting for a lot of target use
cases
- all the more, a PBS could be used as huge second level archive in a
big company, so one could imagine a namespace structure like:
/<state>/<intra-state-location>/<datacenter>/<company-branch>/<workload-type>/<service-type>/
e.g.: /us/east-coast/dc12345/financial/report-storage/cassandra/
that's six levels that one can imagine for a reasonable use-case,
leave some room for the ones harder to imagine ;-)
- on the other hand, we do not want to allow unlimited levels as we
have request parameter limits and deep nesting can create other
issues as well (e.g., stack exhaustion), so doubling the minimum
level of 4 (1st point) we got room to breath even for the
more odd (or huge) use cases (2nd point)
- a per-level length of 32 (-1 due to separator) is enough to use
telling names, making lives of users and admin simpler, but not
blowing up parameter total length with the max depth of 8
- 8 * 32 = 256 which is nice buffer size
Much thanks for Wolfgang for all the great work on the type
implementation and assisting greatly with the design.
Co-authored-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2021-04-07 10:28:50 +00:00
|
|
|
serde_plain = "1"
|
2021-07-07 07:04:09 +00:00
|
|
|
|
2021-10-08 09:19:37 +00:00
|
|
|
proxmox-lang = "1.0.0"
|
2022-04-12 05:25:56 +00:00
|
|
|
proxmox-schema = { version = "1.2.1", features = [ "api-macro" ] }
|
2021-11-23 16:57:00 +00:00
|
|
|
proxmox-serde = "0.1"
|
2021-11-30 12:12:09 +00:00
|
|
|
proxmox-time = "1.1.1"
|
2021-10-08 09:19:37 +00:00
|
|
|
proxmox-uuid = { version = "1.0.0", features = [ "serde" ] }
|
