-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make configs aware of structured data layout #2090
Comments
We need to redesign the configs. Prefix maps make a lot less sense when the objects the user sees are database, table and user. I'd like to see accounting automatically performed at the database, table and user levels and for zones to be configurable at those levels. |
👍 I think zone configs listed by key prefix should be phased out and added instead to database and table descriptors. I think accounting configs can be removed entirely because the database / table structure already properly delimits the key prefixes which we'd want to keep accounting information over. The permission configs are actively being replaced by @mberhault with the SQL privileges. |
@thschroeter: fyi, this is purely about the location of the configs and their layout. Still, there's a decent amount of thought to be put into this, so as of yet I have no idea what this will look like, just vague ideas. The first step of this will most likely be a quick RFC. |
@mberhault: thanks for the explanation. |
Work towards #2090. This creates a new system table storing username/hashed-password that is currently in the users config (removal will come next). The main part of this change is applying custom permissions based on the system table. descriptor and namespace are read-only, but users needs to be modified.
Work towards #2090 Remove accounting config. This includes removing the acct cli command since there is currently nothing in the accounting config.
Work towards #2090 Remove accounting config/keys/endpoints/cli/etc... There is currently nothing in the accounting config, and no exact plans. When this emerges, we'll move it into the system database alongside other configs.
Work towards: #2090 Additional tweaks: * fix all tests that depend on the number of system databases/tables to use dynamic counts. * rework the SystemDBSPan loading a bit. change checksum to sha1 and include keys.
Fixes #2090 (make configs aware of structured layout) Fixes #2179 (sync system DB across nodes) Fixes #2272 (split at table boundaries) This switches all zone configs from the old-school prefix-based one to the system.zones table. Basic summary: * the systemdb span (all system tables) gets gossiped as config.SystemConfig * config.SystemConfig has two basic methods: ComputeSplitKeys(start, end) and GetZoneConfigForKey(range start key) * we split at every user object ID (database or table) below the currently allocated one * if a table does not have a zone config, we use its databases's config. * if a database does not have a zone config, we use the hard-coded default. Some likely changes in the very near future: * pre-build list of actual zones from existing tables (not databases) and only split on those. * allow setting the system span config * allow setting the non-structured span config (probably a reserved ID) Remaining TODOs for this PR: * failing: no idea why: storage/gc_queue_test.go TestGCQueueIntentResolution * need to port: kv/split_test.go TestRangeSplitsWithWritePressure * failing kv and client tests with --race. no clue why. * port cli zones commands * complete tests on config/config and sql/config
Fixes #2090 (make configs aware of structured layout) Fixes #2179 (sync system DB across nodes) Fixes #2272 (split at table boundaries) This switches all zone configs from the old-school prefix-based one to the system.zones table. Basic summary: * the systemdb span (all system tables) gets gossiped as config.SystemConfig * config.SystemConfig has two basic methods: ComputeSplitKeys(start, end) and GetZoneConfigForKey(range start key) * we split at every user object ID (database or table) below the currently allocated one * if a table does not have a zone config, we use its databases's config. * if a database does not have a zone config, we use the hard-coded default. Some likely changes in the very near future: * port cli zones commands * pre-build list of actual zones from existing tables (not databases) and only split on those. * allow setting the system span config * allow setting the non-structured span config (probably a reserved ID)
Fixes #2090 (make configs aware of structured layout) Fixes #2179 (sync system DB across nodes) Fixes #2272 (split at table boundaries) This switches all zone configs from the old-school prefix-based one to the system.zones table. Basic summary: * the systemdb span (all system tables) gets gossiped as config.SystemConfig * config.SystemConfig has two basic methods: ComputeSplitKeys(start, end) and GetZoneConfigForKey(range start key) * we split at every user object ID (database or table) below the currently allocated one * if a table does not have a zone config, we use its databases's config. * if a database does not have a zone config, we use the hard-coded default. Some likely changes in the very near future: * port cli zones commands * pre-build list of actual zones from existing tables (not databases) and only split on those. * allow setting the system span config * allow setting the non-structured span config (probably a reserved ID)
Zone and accounting configs need to be aware of the structured data layout.
At the very least, we need table-level granularity for both.
The text was updated successfully, but these errors were encountered: