Release 2.8 (April 2021)

Release 2.8 adds:

Details of these and other changes are in the sections that follow.

Description of Changes

Updates to the Open Metadata Security Connector

Before this release, the repository services support 3 filtering points for managing events for the OMRS Cohort Topic.

These filtering points are set up in the configuration document of the server. It is possible to specify rules to determine which types of events and which types of metadata elements are filtered out. However this configuration provides no control to allow filtering of events for specific instances.

This release extends the metadata server security connector so it can be called at these same filter points. This will be through optional interfaces that the security connector can choose to implement.

If the current rules are set up, they will still be executed. This change complements the existing filtering.

The server security connector also implements the repository security interface called when metadata is being added/updated/deleted/retrieved through the APIs. Extending the security connector for event filtering means that it can make consistent decisions on the sharing of metadata through the cohorts and through the APIs.

Configuring the server security connector

Configuring the server security connector will not change with this feature. If the connector needs custom attributes to select rule sets etc, these can be specified in the configuration properties.


Implementing the server security connector

The security server connector will have two new interfaces that it can implement: one for the cohort events and one for saving events to the local repository.

There is a single instance of the connector in the server so it is able to maintain counts and cache rules etc. It can also be implemented as a facade to a proprietary service.

More information on the security connector can be found on this page:

Metadata Types

Performance workbench

The performance workbench intends to test the response time of all repository (metadata collection) methods for the technology under test. The volume of the test can be easily configured to also test scalability.

More information is available in the workbench’s documentation.

Instance history interface

Two new (optional) methods have been introduced to the metadata collection interface:

Both methods take the GUID of the instance for which to retrieve history, an optional range of times between which to retrieve the historical versions (or if both are null to retrieve all historical versions), and a set of paging parameters.

If not implemented by a repository, these will simply throw FunctionNotSupported exceptions by default to indicate that they are not implemented.

CTS results output

Up to this release, the detailed results of a CTS run could only be be retrieved by pulling a huge (100’s of MB) file across the REST interface for the CTS. Aside from not typically working with most REST clients (like Postman), this had the additional impact of a sudden huge hit on the JVM heap to serialize such a large JSON structure (immediately grabbing ~1GB of the heap).

While this old interface still exists for backwards compatibility, the new default interface provided in this release allows users to pull down just an overall summary of the results separately from the full detailed results, and the detailed results are now broken down into separate files by profile and test case: each of which can therefore be retrieved individually.

(So, for example, if you see from the summary that only 1-2 profiles are not conformant, you can retrieve just the details for those profiles rather than all details.)

Changes to deployment of the Polymer based UI

In previous releases, a zuul router component was used within the UI server chassis to route requests for static content to a separate server.

In this release any routing needs to be setup externally, for example by placing a nginx proxy in front of both the ui chassis and static content server. This is now done by our docker-compose environment & helm charts so to access the UI you need to go to the nginx proxy. Further summary information can be found in the documentation for those assets.

Bug fixes and other updates

For details on both see the commit history in GitHub.

Known Issues

Egeria Implementation Status at Release 2.8

Egeria Implementation Status

Link to Egeria’s Roadmap for more details about the Open Metadata and Governance vision, strategy and content.

Further Help and Support

As part of the Linux AI & Data Foundation, our slack channels have moved to the LF AI & Data Slack workspace, and our mailing lists can now be found at

Continue to use these resources, along with GitHub to report bugs or ask questions.

License: CC BY 4.0, Copyright Contributors to the ODPi Egeria project.