CORE-12937 schema_registry: core import mode support#27010
CORE-12937 schema_registry: core import mode support#27010pgellert merged 7 commits intoredpanda-data:devfrom
Conversation
BenPope
left a comment
There was a problem hiding this comment.
Looks great.
I didn't see tests that our fake IMPORT in READ_WRITE mode has changed at all? I seem to recall that the reference implementation has some restrictions on specifying id/version during READ_WRITE.
Does this PR completely replace #23750?
I seem to recall an error code being produced from the reference implementation about version needing to be sequential? Perhaps about preventing version gaps? There was a specific error code for it, if I recall.
| assert result_raw.status_code == requests.codes.ok | ||
|
|
||
| self.logger.debug("Set global mode to IMPORT") | ||
| self.logger.debug("Set global mode to FORWARD") |
There was a problem hiding this comment.
nit: This confused me a bit, since FORWARD is a supported config for compatibility. I'd be tempted to name it something like UNSUPPORTED.
| result_raw = self.sr_client.get_schemas_ids_id_versions(id=1) | ||
| assert result_raw.status_code == 200 | ||
|
|
||
| @cluster(num_nodes=3) |
There was a problem hiding this comment.
Is it worth adding a check that with global IMPORT, subject READ_WRITE behaves as intended (override?)?
There was a problem hiding this comment.
I'm planning to have a follow up PR that removes our pseudo-import-mode behaviour in READ_WRITE mode. Let me defer adding testing for that to the follow up PR as well. I think it makes sense to test that behaviour both in global and subject-level READ_WRITE mode (with global IMPORT perhaps).
Retry command for Build#69746please wait until all jobs are finished before running the slash command |
CI test resultstest results on build#69746
test results on build#69925
|
|
rpk bits lgtm, we need to change this though: https://github.com/redpanda-data/redpanda/blob/dev/tests/rptest/tests/rpk_registry_test.py#L654-L657 😅 We wanted to test this because rpk was the one who made the check because the underlying library already accepted the |
Don't reject IMPORT mode when parsing a request, instead, allow enabling it. The preconditions to enable import mode are: - globally: the schema registry must be empty - subject-level: the subject must be empty Soft-deleted schema versions are also considered. The reference implementation has a feature where it allows moving to import mode even if there are soft-deleted schemas, and it hard-deletes these schemas while moving into import mode. We can consider implementing this later on (left as a TODO).
Test that the preconditions of enabling import mode are correctly
checked by the `PUT /mode` and `PUT /mode/{subject}` endpoints.
The error "Overwrite new schema with id 3 is not permitted." should use error code 42205 to match the reference implementation.
Extract for later reuse.
Support IMPORT mode when handling `POST /subjects/{subject}/versions`
requests, that is, when registering schemas.
The expected behaviour is that in import mode:
* users can specify the id and version of the schema
* re-inserting a schema definition with a different schema id is allowed
* no compatibility checks are performed
Test the behaviour of `POST /subjects/{subject}/versions` in import
mode.
66fedfb to
43c01e7
Compare
|
I have a separate ticket for changing the
Yes. Thanks for linking to it, now I noticed that we should change the error code from 42207 to 42205 when returning an error on overwriting a schema, so I've included that in this PR as well (6bd36ae).
In IMPORT mode the version can be arbitrary, the requirement on the version is only a requirement in READ_WRITE mode. The error you're thinking of is |
| // TODO: relax the above restrictions to | ||
| // 1. Allow soft-deleted schemas to exist, but | ||
| // 2. Hard delete them before moving to import mode |
There was a problem hiding this comment.
I guess this would be conditional on force?
There was a problem hiding this comment.
The code would come here where the todo is, so it would be skipped if force=true.
| co_await check_mutable(sub); | ||
|
|
||
| const auto mode = co_await _store.get_mode(sub, default_to_global::yes); | ||
| if (schema.id < 0 && mode != mode::read_write) { |
There was a problem hiding this comment.
Is there any significance of the id being negative but not invalid_schema_id?
There was a problem hiding this comment.
No, any negative number is treated the same as invalid_schema_id / not specified.
Support enabling import mode in the Schema Registry.
In import mode, users can register schemas with the following differences from read write mode:
Fixes https://redpandadata.atlassian.net/browse/CORE-12937
Backports Required
Release Notes