Chapter 5. Service Registry release notes

Red Hat Integration - Service Registry 1.1 is provided as a General Availability release in Red Hat Integration 2020-Q4. Service Registry is a datastore for standard event schemas and API designs, which is based on the Apicurio Registry open source community project.

You can use Service Registry to manage and share the structure of your data using a REST interface. For example, client applications can dynamically push or pull the latest updates to or from Service Registry without needing to redeploy. You can also use Service Registry to create optional rules to govern how registry content evolves over time. For example, this includes rules for content validation or backwards and forwards compatibility of schema or API versions.

5.1. Service Registry installation options

You can install Service Registry with the following storage options:

Table 5.1. Service Registry storage options

Storage optionRelease

Kafka Streams-based storage in AMQ Streams 1.6

General Availability

Cache-based storage in embedded Infinispan 10

Technology Preview only

Java Persistence API-based storage in PostgreSQL 12 database

Technology Preview only

Important

Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend implementing any Technology Preview features in production environments.

This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope.

5.2. Service Registry new features

Service Registry 1.1 includes the following updates:

Service Registry REST client
  • Replaced the generated REST client with a new client based on Retrofit. This has fewer dependencies and is easier to package and use.
  • REST client now supports TLS authentication.
  • HTTP basic authentication credentials can be encoded in the registry URL or configured in REST client properties.
Service Registry serializers/deserializers (serdes)
  • Avro serdes now supports JSON encoding - previously supported binary encoding only.
  • Avro serdes updated with option to use message headers to pass GlobalId information instead of magic byte payload approach.
  • Serdes layer now includes convenience wrapper classes for Kafka Streams applications, for example, wraps the serializer/deserializer pair in AvroSerde wrapper class.
  • You can now configure custom HTTP request headers as properties when using serdes.
Service Registry configuration

  • New environment variables to configure:

    • URLs for Service Registry web console and REST API - also improved the logic that generates these URLs when not set as variables.
    • Kafka topics for Kafka Streams storage.
    • Default global content rules - you can still override these using the /rules API.
  • New properties field for artifact and version metadata to configure arbitrary key/value metadata on artifacts.
Service Registry management
  • Registry Maven plug-in now chooses a default file extension based on the artifact type rather than defaulting to the Avro (.avsc) extension.
  • Loosened restrictions on state changes, for example, Deprecated artifacts can now be undeprecated by transitioning back to Enabled state.
  • Added metrics for HTTP Response status codes.
Service Registry web console
  • Added a Format button to the Content tab for users to format JSON-encoded artifact content for easier readability.
  • Added a tag to visually distinguish Deprecated and Disabled artifacts.
Service Registry Operator
  • Operator now creates ServiceMonitor for Operator metrics.
  • Operator metadata image is now available.
  • Added x-descriptors to describe fields in OpenShift web console.
  • Improved Operator label management.
Service Registry user documentation and examples

5.3. Service Registry resolved issues

The following issues were resolved in Service Registry 1.1:

5.3.1. Service Registry core resolved issues

Registry-703 - Quarkus HTTP port configuration

Fixed error in HTTP port configuration for Quarkus Java runtime.

Registry-717 Registry allows empty artifact content

Registry no longer allows empty artifact content, which is now rejected at the API level.

Registry-737 - USE_SPECIFIC_AVRO_READER parameter

The USE_SPECIFIC_AVRO_READER configuration parameter now works as designed and no longer requires another parameter to also be set.

Registry-820 Cannot disable Compatibility rule

Added NONE option to the compatibility level configuration to allow explicit disabling of Compatibility rules at the artifact granularity.

Registry-853 Deprecated and Disabled artifacts in the web console

Various fixes related to handling of Deprecated and Disabled artifacts in the web console.

IBM compatibility REST API

Various fixes to the IBM compatibility REST API have been contributed by IBM.

5.3.2. Service Registry Operator resolved issues

Operator-26 - Error running Operator locally

Fixed client issue when running the Service Registry Operator locally. See also Operator-29

Operator-45 - Operator might not delete all resources

The Service Registry Operator now cleans up all resources when deleting the ApicurioRegistry custom resource definition. See also Operator-43

IPT-177 - Service Registry failed Kafka authentication

Service Registry no longer fails Kafka authentication if Salted Challenge Response Authentication Mechanism (SCRAM) password contains a @ character.

5.4. Service Registry known issues

The following known issues apply to Service Registry 1.1:

Operator-32 - Operator should support SCRAM authorization without TLS, not only SCRAM+TLS

The Service Registry Operator should support Salted Challenge Response Authentication Mechanism (SCRAM) authorization without Transport Layer Security (TLS), not only SCRAM+TLS.

Operator-41 - Example CRD should not be empty

The provided example ApicurioRegistry custom resource definition should not be empty.

Operator-42 - Auto-generation of OpenShift route may use wrong base host value

The auto-generation of the Service Registry OpenShift route may use a wrong base host value if there are multiple routerCanonicalHostname values.

5.5. Service Registry future changes

We plan to make changes in an upcoming Service Registry release in response to user feedback about required functionality. Some breaking API changes will be required in the next Service Registry release to deliver the requested changes.

Because of these API changes, we will designate the next Service Registry release as version 2.0 instead of a standard version 1.x minor release. Both the current version 1.1 and the future version 2.0 will be supported in parallel for some time to give users a reasonable amount of time to migrate to version 2.0.