Chapter 5. Service Registry release notes

Red Hat Integration - Service Registry 1.0.1 is provided as a micro release in Red Hat Integration 2020-Q3. Service Registry is a datastore for standard event schemas and API designs that 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 type 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.5

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

Updated features in Service Registry 1.0.1

The Service Registry 1.0.1 micro release updates the Operator metadata that is used to install Service Registry 1.0 from the OpenShift OperatorHub user interface. The Service Registry product images have not changed and remain at version 1.0.

The new Operator metadata includes a new Operator bundle format for release packaging, which is designed for use with OpenShift Container Platform 4.5 or 4.6. For more details, see the Bundle Format in the OpenShift documentation.

Note

You can upgrade to Service Registry 1.0.1 if you are using OpenShift 4.5. However, you must upgrade to Service Registry 1.0.1 before upgrading to OpenShift 4.6. The new Operator bundle format is required for use with OpenShift 4.6.

New features in Service Registry 1.0

Service Registry provides the following new features in the 1.0 General Availabilty release:

Service Registry OpenShift Operator
The Red Hat Integration - Service Registry Operator is available from the OpenShift OperatorHub for installation and upgrade. This replaces the OpenShift template previously available in Technology Preview. Example custom resource definitions are also provided for storage in AMQ Streams, embedded Infinispan, or PostgreSQL database.
Service Registry web console
  • Search and browse for artifacts and versions (based on new Search REST API)
  • View details about an artifact, and view generated documentation (OpenAPI only)

  • Perform artifact actions:

    • Upload to registry
    • Edit metadata
    • Configure rules
    • Download locally
  • Configure global rules
Additional storage options (Technology Preview only)
  • Java Persistence API (JPA) - PostgreSQL 12.x database
  • Embedded Infinispan cache - Infinispan 10.0.1.Final (Community build)
Additional artifact types
  • WSDL - Web Services Description Language
  • XSD - XML Schema Definition
  • XML - Extensible Markup Language
Improved rules for registry content
  • Improved compatibility rule for JSON Schema artifacts
Improved artifact metadata
  • Automatic extraction of metadata defined in artifact content, for example, artifact name and description
  • Labels for searching and browsing
Quarkus version
  • Red Hat build of Quarkus 1.3.2.Final
User documentation

5.3. Service Registry known issues

The following known issues apply to Service Registry 1.0:

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::

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.

Operator-45 - Operator may not delete all resources

The Service Registry Operator may not delete all resources when deleting ApicurioRegistry custom resource definition.