Interface OdysseyManager

All Superinterfaces:
AutoCloseable, OdysseyReadManager
All Known Implementing Classes:
OdysseyIntegrationManager
public interface OdysseyManager extends OdysseyReadManager
Full Odyssey integration interface used by the controller server.

Extends OdysseyReadManager with write operations (CreateTopics, DeleteTopics). Controller servers depend on this interface; broker servers depend only on OdysseyReadManager.

All methods extract the namespace internally from the principal.

See Also:

  • Method Details

    • handleCreateTopicsWithOdyssey

      CompletableFuture<org.apache.kafka.common.message.CreateTopicsResponseData> handleCreateTopicsWithOdyssey(org.apache.kafka.common.requests.CreateTopicsRequest request, BiFunction<org.apache.kafka.common.message.CreateTopicsRequestData, Set<String>, CompletableFuture<org.apache.kafka.common.message.CreateTopicsResponseData>> topicCreator, org.apache.kafka.common.security.auth.KafkaPrincipal principal)
      Handles CreateTopics requests with Odyssey integration for K1.
      Parameters:
      request - the CreateTopics request, holding only authorized topics
      topicCreator - creates the given topics; its second argument names the subset whose external-schema type the same create operation must set to MAYBE
      principal - the request principal for namespace extraction and token acquisition
      Returns:
      CompletableFuture with the complete response

    • handleDeleteTopicsWithOdyssey

      CompletableFuture<List<DeleteResult>> handleDeleteTopicsWithOdyssey(Map<String, org.apache.kafka.common.Uuid> nameToId, Set<String> topicsWithAssociations, org.apache.kafka.common.security.auth.KafkaPrincipal principal)
      Handles DeleteTopics requests with Odyssey integration for K1. The caller has already authorized each topic and resolved its UUID.

      topicsWithAssociations is the caller's classification of which topics may carry a Schema Registry association; this method does not classify. A superset is safe — those topics just pay a no-op SR call — but a subset orphans associations, since the topic is deleted right afterwards.

      Returns one DeleteResult per input topic, in nameToId iteration order.

    • handleIncrementalAlterConfigsWithOdyssey

      CompletableFuture<Void> handleIncrementalAlterConfigsWithOdyssey(Map<org.apache.kafka.common.config.ConfigResource, Map<String, Map.Entry<org.apache.kafka.clients.admin.AlterConfigOp.OpType, String>>> configChanges, Map<org.apache.kafka.common.config.ConfigResource, OdysseyManager.LargeAssociationPayloads> largePayloads, org.apache.kafka.common.security.auth.KafkaPrincipal principal, boolean validateOnly, ControllerConfigUpdater controllerConfigUpdater, Consumer<Map<org.apache.kafka.common.config.ConfigResource, org.apache.kafka.common.requests.ApiError>> responseDataUpdater, ExternalSchemaUpdater externalSchemaUpdater)
      Handles IncrementalAlterConfigs requests with Odyssey integration for K1.

      SET ops upsert associations to SR; DELETE ops disassociate them. Non-Odyssey resources bypass the SR flow and go directly to the controller. Every per-resource result — illegal rejection, validation failure, SR-resolution failure, controller result, SR-upsert result — is delivered through responseDataUpdater, which is the sole channel for response writes and handles any caller-side translation (e.g. cluster link name mapping).

      When validateOnly is true, SR dry-run validation still runs, the controller call still runs (passed-through validateOnly by the caller's lambda), but the real SR upsert (updateAssociations) is skipped — no schema-association state changes in SR. Mirrors the CreateTopics-with-Odyssey behavior.

      Parameters:
      configChanges - preprocessed config changes per resource, keyed by op type
      largePayloads - association payloads the request delivered as tagged bytes, per resource; resolved into configChanges before classification
      principal - the request principal for namespace extraction and token acquisition
      validateOnly - if true, skip real SR upsert (dry-run validation still runs)
      controllerConfigUpdater - callback to apply config changes via the controller (Odyssey configs stripped); receives validateOnly explicitly so the controller call honours the same flag
      responseDataUpdater - consumer that receives each per-resource result (resource → ApiError) and writes it into the caller's response with any required translation
      externalSchemaUpdater - ExternalSchemaUpdater, invoked between the controller alter and the SR upsert
      Returns:
      CompletableFuture that completes after the final responseDataUpdater invocation; on failure, completes exceptionally with the error

    • notifyDeleteTopicsResult

      void notifyDeleteTopicsResult(Set<org.apache.kafka.common.Uuid> associationDeletedTopicIds, Map<org.apache.kafka.common.Uuid, org.apache.kafka.common.requests.ApiError> idToError)
      Reports per-topic results from the post-Odyssey Kafka delete so SR-committed-but-Kafka-failed topics — the orphan-event boundary — can be observed.
      Parameters:
      associationDeletedTopicIds - topics whose SR association was actually removed this request; the only orphan candidates. Callers must exclude bypass-SR (no-association) topics.
      idToError - per-topic Kafka delete outcomes