Cloudera Docs

Known Issues in Schema Registry

Learn about the known issues in Schema Registry, the impact or changes to the functionality, and the workaround.

Known Issues identified in Cloudera Runtime 7.3.1.400 SP2

There are no new known issues identified in this release.

Known Issues identified in Cloudera Runtime 7.3.1.300 SP1 CHF 1

There are no new known issues identified in this release.

Known Issues identified in Cloudera Runtime 7.3.1.200 SP1

There are no new known issues identified in this release.

Known Issues identified in Cloudera Runtime 7.3.1.100 CHF 1

There are no new known issues identified in this release.

Cloudera Runtime 7.3.1

CDPD-40380: Authorization checking issue when Kerberos is disabled
7.2.17, 7.2.18, 7.3.1, 7.3.1.100, 7.3.1.200, 7.3.1.300, 7.3.1.400
Due to an issue in Ranger, when Kerberos is disabled then it is not possible to check authorization.
  1. Open Schema Registry configuration in Cloudera Manager.
  2. Find the ranger.plugin.schema-registry.service.name field.
  3. Replace GENERATED_RANGER_SERVICE_NAME with the actual name of the service.
  4. Restart the Schema Registry service.
CDPD-49304: AvroConverter does not support composite default values
7.2.17, 7.2.18, 7.3.1, 7.3.1.100, 7.3.1.200, 7.3.1.300, 7.3.1.400
AvroConverter cannot handle schemas containing a STRUCT type default value.
None.
OPSAPS-70971: Schema Registry does not have permissions to use Atlas after an upgrade
7.2.17, 7.2.18, 7.3.1, 7.3.1.100, 7.3.1.200, 7.3.1.300, 7.3.1.400
Following an upgrade, Schema Registry might not have the required permissions in Ranger to access Atlas. As a result, Schema Registry's integration with Atlas might not function in secure clusters where Ranger authorization is enabled.
  1. Access the Ranger Console (Ranger Admin web UI).
  2. Click the cm_atlas resource-based service.
  3. Add the schemaregistry user to the all - * policies.
  4. Click Manage Service > Edit Service.
  5. Add the schemaregistry user to the default.policy.users property.
OPSAPS-69317: Kafka Connect Rolling Restart Check fails if SSL Client authentication is required
7.2.18, 7.3.1, 7.3.1.100, 7.3.1.200, 7.3.1.300
The rolling restart action does not work in Kafka Connect when the ssl.client.auth option is set to required. The health check fails with a timeout which blocks restarting the subsequent Kafka Connect instances.
You can set ssl.client.auth to requested instead of required and initiate a rolling restart again. Alternatively, you can perform the rolling restart manually by restarting the Kafka Connect instances one-by-one and checking periodically whether the service endpoint is available before starting the next one.