Earlier releases¶

The default audit log output to the console for newly configured servers will no longer include the Event log entries and the Types log entries. Existing servers will continue to log as before. The audit log entries displayed on the console by a server can be changed using the Administration Services.

As the Egeria code base evolved, sets of definitions for the unique identifiers and type names of the open metadata types appeared in multiple modules. There was a set in the open metadata archive helper, the generic handlers, multiple OMASs and the Governance Action Framework. This was in addition to the original definitions in the open metadata type archive itself. In release 5.0, these copies of the open metadata type identifiers have been consolidated into one set found in the Governance Action Framework. There is still work to change the type definitions in the open metadata type archive to use the definitions from the GAF. This change removes the inconsistencies and gaps in the definitions. It also makes it easier to discover where a particular open metadata type is used.

Release 3.15 (February 2023)¶

Release 3.14 (December 2022)¶

Release 3.13 (November 2022)¶

Release 3.12 (October 2022)¶

Release 3.11 (September 2022)¶

extralibs:
- url: https://search.maven.org/remotecontent?filepath=org/odpi/egeria/egeria-connector-xtdb/3.10/egeria-connector-xtdb-3.10-jar-with-dependencies.jar
  filename: egeria-connector-xtdb-3.10-jar-with-dependencies.jar
- url: https://oss.sonatype.org/service/local/repositories/snapshots/content/org/odpi/egeria/egeria-connector-postgres/3.11-SNAPSHOT/egeria-connector-postgres-3.11-20220826.091931-1.jar
  filename: egeria-connector-postgres.jar
- url: https://jdbc.postgresql.org/download/postgresql-42.5.0.jar
  filename: postgresql.jar

helm install base egeria/base -f ~/etc/extra.yaml

➜  main git:(main) kubectl get pods | grep jupyter
lab-odpi-egeria-lab-jupyter-7d9798d75-lwdgb        1/1     Running   1 (3h53m ago)   3h54m
➜  main git:(main) kubectl logs lab-odpi-egeria-lab-jupyter-7d9798d75-lwdgb | grep TOKEN
➜  main git:(main) kubectl logs lab-odpi-egeria-lab-jupyter-7d9798d75-lwdgb | grep -y token
[I 2022-08-31 16:18:30.730 ServerApp] https://lab-odpi-egeria-lab-jupyter-7d9798d75-lwdgb:8888/lab?token=091f2f66a76152b40b7ae2056ace8719bd57faa42fcbb286
[I 2022-08-31 16:18:30.730 ServerApp]  or https://127.0.0.1:8888/lab?token=091f2f66a76152b40b7ae2056ace8719bd57faa42fcbb286
https://lab-odpi-egeria-lab-jupyter-7d9798d75-lwdgb:8888/lab?token=091f2f66a76152b40b7ae2056ace8719bd57faa42fcbb286
or https://127.0.0.1:8888/lab?token=091f2f66a76152b40b7ae2056ace8719bd57faa42fcbb286
➜  main git:(main)

Release 3.10 (July 2022)¶

Release 3.9 (June 2022)¶

Release 3.8 (May 2022)¶

Release 3.7 (April 2022)¶

Release 3.6 (March 2022)¶

Release 3.5 (February 2022)¶

Release 3.4 (December 2021)¶

{
"class": "OMAGServerStatusResponse",
"relatedHTTPCode": 200,
"serverStatus": {
    "serverName": "cocoMDS6",
    "serverType": "Metadata Server",
    "serverActiveStatus": "RUNNING",
    "services": [
        {
            "serviceName": "Open Metadata Repository Services (OMRS)",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Community Profile OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Asset Consumer OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Data Science OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "IT Infrastructure OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Asset Owner OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Asset Manager OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Connected Asset Services",
            "serviceStatus": "STARTING"
        },
        {
            "serviceName": "Data Manager OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Project Management OMAS",
            "serviceStatus": "RUNNING"
        },
        {
            "serviceName": "Governance Engine OMAS",
            "serviceStatus": "RUNNING"
        }
    ]
}

{
"class": "OMAGServerStatusResponse",
"relatedHTTPCode": 200,
"serverStatus": {
    "serverName": "cocoMDS2",
    "serverType": "Metadata Server",
    "serverActiveStatus": "STARTING",
    "services": [
        {
            "serviceName": "Open Metadata Repository Services (OMRS)",
            "serviceStatus": "STARTING"
        }
    ]
}

UNKNOWN    The state of the server is unknown. 
STARTING   The server is starting.
RUNNING    The server has completed start up and is running.
STOPPING   The server has received a request to shutdown.
INACTIVE   The server is not running.

Release 3.3 (November 2021)¶

Release 3.2 (October 2021)¶

Release 3.1 (September 2021)¶

Release 3.0 (August 2021)¶

Release 2.11 (July 2021)¶

Release 2.10 (June 2021)¶

Release 2.10 adds: * New and improved open metadata types for governance * New API for Governance Program OMAS

See also an important notice about removal of Java 8 support in a future release.

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

Description of Changes¶

Metadata Types¶

• Correction to the Campaign classification.

The Campaign classification is supposed to connect to a Project entity to indicate the project is a grouping of a series of projects designed to achieve a large goal. Unfortunately it was coded to connect to the Collection entity. In 2.10, the Campaign classification has been changed to attach to Referenceable to allow it to be connected to Project without affecting backward compatibility.

See new type description in model 0130.

• Extension of the UsedInContext relationship.

The UsedInContext relationship linked two GlossaryTerm entities together to show that one glossary term described the context in which the other was valid. This relationship has been updated to allow the end that describes the context to be a Referenceable. This means that the context where glossary terms are valid can be expressed as elements such as projects, business capabilities, parts of an organization, subject areas, zones and many more.

See new type description in model 0360.

• Allowing ownership to be expressed as a PersonRole.

Issue #5104 described the problem that the governance open metadata types allowed owners to be expressed as PersonalProfile or UserIdentity entities. The properties did not identify if the owner was identified as a GUID or as a qualifiedName. In 2.10, a new classification for expressing ownership called, not surprisingly, Ownership, was introduced which allows and type and property name for the owner to be specified with the owner's identifier. The types for entities such as GovernanceActionType and IncidentReport that include ownership properties in them have been updated to deprecate these properties in favor of using the Ownership classification. The AssetOwnership classification is also deprecated.

See new type description in model 0445.

• Update to Certification relationship.

The Certification relationship supports the identification of the people involved in the certification of an element. 2.10 adds new attributes to specify the type and property names of the identifier used to identify these people. This is consistent with the new Ownership classification.

See new type descriptions in model 0482.

• Update to License relationship.

The License relationship supports the identification of the people involved in the licencing of an element. 2.10 adds new attributes to specify the type and property names of the identifier used to identify these people. This is consistent with the new Ownership classification.

See new type descriptions in model 0481.

• Governance role updates.

The GovernanceOfficer entity now inherits from GovernanceRole rather than PersonRole. This means it is just another governance role that can be linked with GovernanceResponsibility definitions. In addition there are new types for different types of owners. These are ComponentOwner and DataItemOwner.

See new type descriptions in model 0445.

• Extend the GovernanceResponsibilityAssignment

The GovernanceResponsibilityAssignment relationship identifies the responsibilities for a particular role. It used to link to a GovernanceRole and in 2.10, it has been updated to link to a PersonRole. This means that governance responsibilities can be added to any role, such as ProjectManager and CommunityMember, rather than just specialized governance roles.

See new type descriptions in model 0445.

• Deprecating the domain attribute in various governance types.

The domain attribute is typed by the GovernanceDomain enum. This provides a fixed list of governance domains. An extensible mechanism for expressing the governance domain was added in release 2.4 using the GovernanceDomainDescription entity and the domainIdentifier attribute. In this release, the use of domain is deprecated in GovernanceDefinition, GovernanceZone, SubjectAreaDefinition, GovernanceMetric, GovernanceRole and GovernanceOfficer.

See new type descriptions in model 0401.

• Extensions to governance drivers.

There are now new subtypes of the GovernanceDriver entity called RegulationArticle and BusinessImperative. It is also possible to link governance drivers using the new GovernanceDriverLink relationship.

See new type descriptions in model 0405.

• Update to AssetOrigin classification.

The AssetOrigin classification supports the identification of the origin of an asset. This can be in terms of the organization, business capability and other values. 2.10 adds new attributes to identify if the organization or business capability is identified by its GUID or qualifiedName.

See new type descriptions in model 0440.

• Improve IncidentClassifiers.

If is possible to define multiple sets of IncidentClassifier values that can be used on IncidentReport entities to help to group and prioritize them. The IncidentClassifier entity now inherits from Referencable and there is a new classification called IncidentClassifierSet to mark a Collection entity as containing IncidentClassifier definitions.

See new type descriptions in model 0470.

• Deprecation of ResponsibilityStaffContact.

The ResponsibilityStaffContact relationship has been deprecated in favor of the GovernanceResponsibilityAssignment relationship.

New Services for Governance Program OMAS¶

The APIs defined for Governance Program OMAS have been updated to reflect the changes to the open metadata types described above. The APIs and client implementations are in place. The server-side is coming in a future release.

Bug fixes and other updates¶

• Additional Bug Fixes

• Cascaded deletes for entities grouped using the Anchors classification are now deleting the correct entities. Prior to this release, some entities were missed and others were deleted incorrectly.

• Dependency Updates

For details on both see the commit history in GitHub.

Known Issues¶

• It is recommended to use a chromium-based browser such as Google Chrome or Microsoft Edge, or Apple Safari for the Egeria React UI. Some parts of the UI experience such as Dino currently experience problems with Firefox. See odpi/egeria-react-ui#96 .
• When running the 'Understanding Platform Services' lab, ensure you run the 'egeria-service-config' notebook first and do not restart the python kernel before running this lab. See #4842 .
• When logging into the react UI for the coco pharma lab demo, ensure to use http://myhost.mydomain/coco/login as otherwise the login will not work. see odpi/egeria#41
• A few further bugs are noted at https://github.com/odpi/egeria/issues/5211#issuecomment-850321243 including for samples and UI.

Removal of Java 8 Support¶

Egeria will drop support for Java 8 in a forthcoming release within the next few months. We have been building and testing with Java 11 for over a year and will move to build all packages with Java 11, and require Java 11. At this point Java 8 will no longer be supported for new releases.

Egeria Implementation Status at Release 2.10¶

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

Release 2.9 (May 2021)¶

Release 2.9 adds:

• Changes to metadata types
• Changes to building Egeria on Windows

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

Description of Changes¶

Metadata Types¶

• The UserProfileManager, UserAccessDirectory and MasterDataManager classification for Referenceables has been added to model 0056 resource Managers.
• A new relationship called ActionTarget to link a To Do to the elements that need work has been added to model 0137 Actions for People.
• A new attribute called filterExpression has been added to the Port entity in model 0217 Ports.
• A new classification called PrimaryCategory has been added to model 0335 Primary Category.
• A new classification called GovernanceMeasurements has been added to model 0450 Governance Rollout.
• The RelationalColumnType entity in model 0534 Relational Schema. only allows for a column to be primitive. It could be a literal, enum or external and so this type has been deprecated and the appropriate schema types should be used directly.

Building Egeria on Windows¶

To build Egeria on Windows you should use Windows Subsystem for Linux Version 2 or above & install an appropriate Linux distribution.

Egeria should then be built & run within this environment.

IDEs such as IntelliJ and VSCode support editing and code management within the Windows GUI alongside build and execution in Linux.

See PR #5084 for more information.

Bug fixes and other updates¶

• Additional Bug Fixes
• Dependency Updates

For details on both see the commit history in GitHub.

Known Issues¶

• It is recommended to use a chromium-based browser such as Google Chrome or Microsoft Edge, or Apple Safari for the Egeria React UI. Some parts of the UI experience such as Dino currently experience problems with Firefox. See odpi/egeria-react-ui#96 .
• When running the 'Understanding Platform Services' lab, ensure you run the 'egeria-service-config' notebook first and do not restart the python kernel before running this lab. See #4842.

Egeria Implementation Status at Release 2.9¶

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

Release 2.8 (April 2021)¶

Release 2.8 adds:

• New support for event and property filtering for the open metadata server security connector
• Changes to metadata types
• New performance workbench for the CTS (technical preview)
• New interface for retrieving the complete history of a single metadata instance
• Splitting of CTS results into multiple smaller files

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.

• Should an event be sent to the cohort
• Should an event be retrieved from the cohort
• Should a received event be stored in the local repository

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.

See Configuring the server security connector .

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.

• The event interface will have two methods, one for sending and one for receiving. The parameters will include the cohort name and the event contents. It can return the event unchanged, return a modified event (eg with sensitive content removed) or return null to say that the event is filtered out.

• The event saving interface will receive the instance header and can return a boolean to indicate if the local repository should store it. If true is returned, the refresh event sequence is initiated. The repository connector then has the ultimate choice when the refreshed instance is returned from the home repository as to whether to store it or not.

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 Open Metadata Security page.

Metadata Types¶

• Updates to the location types in model 0025:
• Add the mapProjection property to the FixedLocation classification
• Change the address property to networkAddress in the CyberLocation classification

• Deprecated HostLocation in favor of the AssetLocation relationship

• Deprecate the RuntimeForProcess relationship since it is superfluous - use ServerAssetUse since Application is a SoftwareServerCapability. See model 0045.

• Replace the deployedImplementationType property with the businessCapabilityType in the BusinessCapability since it is a more descriptive name. See model 0440.

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:

• getEntityDetailHistory
• getRelationshipHistory

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 csonformant, 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 Egeria UI Application 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¶

• Additional Bug Fixes
• Dependency Updates

For details on both see the commit history in GitHub.

Known Issues¶

• It is recommended to use a chromium-based browser such as Google Chrome or Microsoft Edge, or Apple Safari for the Egeria React UI. Some parts of the UI experience such as Dino currently experience problems with Firefox. See odpi/egeria-react-ui#96 .
• Egeria source code currently fails to build on Windows natively. Please use Linux, MacOS, or compile under WSL/WSL2 on Windows. See #4917
• Several Java samples fail (governance, admin) - #4656, #4662, #4056
• The React UI used by the helm charts and compose is based on react UI release 2.7.0 due to layout issues found with 2.8.0. See #5022
• The platform services notebook may fail to query servers correctly. See #5023
• The building a data catalog notebook may fail if run quickly. See #2688
• The data curation notebook is incomplete and still being developed. The final steps may fail to work in a container environment. See #5021

Egeria Implementation Status at Release 2.8¶

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 https://lists.lfaidata.foundation/groups

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

Release 2.7 (March 2021)¶

Release 2.7 adds:

• Performance improvements in the graph repo
• Changes to metadata types
• Changes to the distribution process

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

Description of Changes¶

Build & Release changes¶

• Previously release maven artifacts have been pushed to JCenter (in addition to Maven Central), and snapshots have been pushed to odpi.jfrog.io/odpi/egeria-snapshot. As of 2.7 this no longer occurs and release and snapshots are pushed only to Maven Central.
• Due to the above, maven artifacts may be signed by a different user to previously (and this may change in a future release).

Performance Improvements¶

• Release 2.7 includes performance improvements to the graph repository's search methods, which select an efficient query strategy based on the properties and type filters supplied to the search.

Metadata Types¶

• We have removed overloaded properties that existed at multiple levels in a type definition: for example, length was defined both on SchemaAttribute and again on RelationalColumn (which is a subtype of SchemaAttribute). This change removes them from being defined again the lower level (RelationalColumn in this example); however, the property itself will still be available at the lower level due to inheriting it from the supertype.

Bug fixes and other updates¶

• Additional Bug Fixes
• Dependency Updates

For details on both see the commit history in GitHub.

Known Issues¶

• It is recommended to use a chromium-based browser such as Google Chrome or Microsoft Edge, or Apple Safari for the Egeria React UI. Some parts of the UI experience such as Dino currently experience problems with Firefox. See odpi/egeria-react-ui#96 .
• When running the 'Understanding Platform Services' lab, ensure you run the 'egeria-service-config' notebook first and do not restart the python kernel before running this lab. See #4842 .

Egeria Implementation Status at Release 2.7¶

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 https://lists.lfaidata.foundation/groups

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

Release 2.6 (February 2021)¶

Release 2.6 adds support for:

• New Governance Server called Engine Host with associated Open Metadata Engine Services (OMES). This Governance Server replaces the Discovery Server, Stewardship Server, Virtualizer and Security Officer Server.

• Extensions to Open Metadata Types for lineage, duplicate processing, governance actions, the software development lifecycle and analytics models.

The release also changes the default location of some important files in order to facilitate deployment and separate program files from writeable data.

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

Description of Changes¶

Changes to data files created/used by Egeria¶

Up to and including release 2.5, various data files were created in the current working directory when Egeria was run. This included configuration files, cohort information, graph repositories etc. This made it difficult to manage Egeria in a container environment where we want to manage persistent data explicitly - for example via a docker volume, or a kubernetes persistent volume (claim).

Because of this the default locations of a number of files have changed, so when deploying release 2.6 make sure you copy any existing files you need to preserve over to their new locations. If this is not done server configs and repository data may not be found, or configuration files may not be decryptable.

The result of this is that all the dynamic data created by egeria locally in the filesystem is restricted to the 'data' directory so this can be mapped to a volume easily.

If you have already explicitly configured the relevant connector yourself there will be no change. this updates the defaults only.

Removal of the Discovery Server and Stewardship Server¶

The Discovery Server, Stewardship Server, Virtualizer and Security Officer Server have been consolidated into a new type of server called the Engine Host OMAG Server. The Engine Host runs one-to-many Open Metadata Engine Services (OMES). Each engine services hosts a specific type of governance engine. The first engine service called Asset Analysis OMES will be for discovery engines and others for the different types of governance action engines from the Governance Action Framework (GAF).

The reason for this change is that there is a lot of duplicated code in the original servers and this change simplifies the Governance Server Services and Server Administration. With this change it will also be easier for Egeria to host other types of governance engines such as Palisade and Gaian.

New open metadata types for Governance Actions¶

The following types have been added to support the governance action engines:

• 0461 Governance Action Engines
• 0462 Governance Action Processes
• 0463 Engine Actions

Updates to open metadata types for Lineage Mapping¶

The LineageMapping open metadata relationship type has been updated to link Referenceables rather than SchemaElements. This is to capture lineage between components at different levels of detail since the data field mappings may not always be available. Lineage mapping is described in more detail in lineage management.

New open metadata types for Duplicate Processing¶

Since Egeria is integrating and distributing metadata from many different sources, it is inevitable that there will be multiple metadata instances that represent the same real-world "thing". The 0465 Duplicate Processing types allow these elements to be linked together.

Presentation Server / React UI¶

• The node based User Interface component known as 'Presentation Server' has now fully moved to it's own GitHub Repository.
• The docker image has been renamed to egeria-react-ui
• Dino - Adds display of integration servers’ integration services and engine hosts’ engine services, including display of a dependency on a partnerOMAS.
• Rex - Improved error reporting and geometry management plus more consistent handling of focus objects. Enterprise queries are now the default, but can be over-ridden to perform a local operation.
• At this time 'Server Author' and 'Glossary Author' are still in development.

New Helm Chart¶

In addition to our 'lab' helm chart to support the Coco Pharmaceuticals environment, we have now added an additional helm chart which provides a simpler environment with just a single platform, and a single server, but configured with persistence and auto start. This offers an example of a simple Kubernetes deployment.

Graph Repository¶

• Now implements the findEntities and findRelationships methods of the OMRS MetadataCollection API.
• Added detailed documentation for the graph repository

Conformance Test Suite¶

• CTS now has tests for findEntities and findRelationships methods and search tests have been realigned into profiles so that all search operations are in optional profiles, with basic and advanced profiles for each of entities and relationships.

Other changes¶

Release 2.6 also contains many bug fixes and minor improvements & dependency updates

Removals and Deprecations¶

• Discovery Server, Stewardship Server, Virtualizer and Security Officer Server have been replaced with more extensive capability - see above.
• Information View OMAS has now been removed following earlier deprecation.

Egeria Implementation Status at Release 2.6¶

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 https://lists.lfaidata.foundation/groups

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

Release 2.5 (December 2020)¶

Below are the highlights of the 2.5 release:

• The following improvements to the presentation-server user interface:

• The Type Explorer UI

  • new options to show/hide deprecated types and/or deprecated attributes. Please refer to the Type Explorer help.md for details.
  • preserves the user-selected focus type across reloads of type information from the repository server.

• The Repository Explorer UI

  • has the Enterprise option enabled by default. It can be disabled to perform more specific, localized queries.
  • now indicates whether an instance was returned by an enterprise or local scope operation against its home repository or is a reference copy or proxy.
  • has a user-settable limit on the number of search results (and a warning to the user if it is exceeded)
  • now colors nodes based on their home metadata collection's ID. This previously used metadata collection's name but a metadata collection's name can be changed, whereas the metadata collection's ID is permanent.
  • has improved help information covering search

• The Dino UI

  • displays a server's status history in a separate dialog instead of inline in the server details view.

• The following improvements to the repositories:

• The Graph Repository

  • find methods have reinstated support for core properties, previously temporarily disabled due to property name clashes that are now resolved

• A new type OpenMetadataRoot has been added as the root type for all Open Metadata Types. See the base model

• The admin services guide has some additional information on configuring TLS security

• Improvements to the gradle build scripts, but at this point it remains incomplete and build of egeria still requires maven

• Bug Fixes

• Dependency Updates

Egeria Implementation Status at Release 2.5¶

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

Release 2.4 (November 2020)¶

• The Integration Daemon now makes it simpler to exchange metadata with third party technology such as catalogs and databases.
• The Repository Explorer User Interface ('REX') must now be configured with a list of available platforms and servers to improve security and usability.
• The latest version of Repository Explorer, Type Explorer and Dino, is found in the 'Presentation Server' UI.
• The Repository Explorer User Interface ('REX') must now be configured with a list of available platforms and servers to improve security and usability. See Presentation Server component documentation and Configuring the Presentation Server.
• The UI Server Chassis no longer includes static content. It is now required to deploy the egeria-ui project in addition to the spring application. A docker image is available, and the docker-compose and Kubernetes lab environments include this pre-configured.
• Additional Access Services Functional Verification tests have been added to improve code quality
• Bug fixes
• Dependency updates
• Spring has been updated to 5.2.9
• Spring Security has been updated to 5.4.1
• Spring Boot has been updated to 2.3.3
• For a full list run 'mvn dependency:tree' against top level directory and/or review the top level pom.xml

Known Issues¶

• The docker-compose based lab environment is incorrectly pulling docker images from the wrong repository. To correct this change open-metadata-resources/open-metadata-deployment/compose/tutorials/.env to egeria_repo=odpi. The original repository has however been updated to include 2.4 images, so will now work even if unchanged.

Egeria Implementation Status at Release 2.4¶

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

Release 2.3 (October 2020)¶

New capabilities & Major changes¶

• A new Presentation Server User interface has been added, making use of React & Carbon
• Presentation Server is still in development
• For developers not contributing to Presentation Server, running in a container under Kubernetes or docker-compose is the easiest way to get started
• See the last section of the Presentation Server README for instructions on running Presentation Server
• For contributors, The Presentation Server README also documents 'Configuring the Presentation Server' - this is done automatically in our k8s/compose environment. However if doing this manually note (4th point) that the environment variable is called EGERIA_PRESENTATIONSERVER_SERVER_<ui server name> where the <ui server name> is the tenant's serverName.. The examples in the document are correct.
• The Dino User Interface for presentation server now allows an Egeria operations user to display a graph and details of Egeria resources including platforms, servers, services and cohort memberships.
• Type Explorer & Repository Explorer, previously found in the Polymer based UI, are now available in Presentation Server.
• Raise a github issue or Contact the Egeria team via slack at https://slack.lfaidata.foundation if you experience issues or have questions.
• The Egeria Docker image is now based on Redhat's UBI-8 openjdk-11 image, to improve security & operational support. See issue #3580
• Bug Fixes & ongoing feature work

Known Issues¶

• Several maven artifacts have not been published to maven central/JCenter. See issue #3675 They can be retrieved from JFrog Artifactory at 'https://odpi.jfrog.io/odpi/egeria-release-local' if needed and it is not possible to build locally.
• org.odpi.egeria:presentation-server
• org.odpi.egeria:subject-area-fvt
• org.odpi.egeria:dev-ops-api
• org.odpi.egeria:digital-service-spring

Dependencies¶

• Spring has been updated to 2.3.9
• Spring Security has been updated to 5.4.0
• For a full list run 'mvn dependency:tree' against top level directory and/or review the top level pom.xml

Egeria Implementation Status at Release 2.3¶

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

Release 2.2 (September 2020)¶

Below are the highlights of this release:

• Additional connectors are now placed in our assembly under platform/lib without dependencies. If you need to use a connector that requires additional dependencies that are not already part of the platform's classpath, you will need to add those libraries here.
• The docker image has been updated to use a later openjdk alpine base image due to incompatibilities with our JanusGraph support in the old images for java 8.
• In the VDC chart, 2 new values have been added, 'ibmigc.connectorversion' and 'atlas.connectorversion'. In this release these are set to use the 2.1 connectors, since the connectors run to a different release cycle than the main Egeria code. Once new connectors are released you can update these values to get the latest connectors
• Additional code to support lineage has been added, but in this release it remains in development and is not yet ready for use in production.
• User interface improvements.
• Ongoing bug fixes and refactoring especially in subject-area omas.

Known Issues¶

• In the VDC helm chart, the Apache Atlas initialization job fails to complete. This is due to a problem with the Apache Atlas server and Apache SOLR. See https://github.com/odpi/egeria/issues/3587 for more information.

Dependencies¶

• Spring Boot is updated to 2.3.3.

Egeria Implementation Status at Release 2.2¶

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

Release 2.1 (August 2020)¶

Release 2.1 primarily contains bug fixes and preparatory work for future capabilities.

A full list of changes can be seen by comparing on github.

The highlights include:

• Bug fixes
• Subject Area OMAS has added testing including automated FVTs, code cleanup & bug fixes
• User Interface fixes & usability improvements
• Dependency Updates
• Spring updated to 5.2.8
• additional dependencies to remain current

Egeria Implementation Status at Release 2.1¶

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

Release 2.0 (July 2020)¶

Release 2.0 adds support for:

• Encryption by default (HTTPS/SSL, encrypted configuration file)
• bug fixes
• dependency updates

Below are the highlights:

• The OMAG Server Platform default URL is now https://localhost:9443 - the platform now listens on port 9443 and supports https only. All clients have been updated accordingly. At this point SSL certificate validation is disabled. This will be enabled in a future release.
• Docker containers, docker-compose scripts, kubernetes deployments have all been updated to use https accordingly.
• The Encrypted Configuration File Store Connector is now used by default to ensure security of sensitive configuration details like credentials.

Egeria Implementation Status at Release 2.0¶

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

Release 1.8 (June 2020)¶

Below are the highlights of Release 1.8:

• New tutorial information has been added in the form of the Egeria Dojo
• Usability & Capability improvements to Repository Explorer
• Samples & utilities are now also packaged into jars with dependencies to make them easier to use (java -jar)

• Connections to kafka will now retry to improve availability. See 'Bring up Issues' in the connector documentation\

• New dependencies has been included:

  • Spring Boot Actuator - Provides features to help you monitor and manage your application when you push it to production
  • micrometer-registry-prometheus - Exposes metrics in a format that can be scraped by a Prometheus server

• Many dependencies have been updated. The most relevant include:

  • Spring has been updated to 5.2.6
  • Spring Boot, Spring Security, Spring Security, Spring Data have been updated to 2.3.0

Egeria Implementation Status at Release 1.8¶

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

Release 1.7 (May 2020)¶

Release 1.7 contains many bug fixes & preparatory development work for future new features.

Below are the highlights:

• There is support for loading standard glossaries and design models coded in OWL/JSON-LD into the open metadata ecosystem. The input file is converted to an Open Metadata Archive which can be loaded directly into a metadata server.

• Many dependencies have been updated including:

  • Kafka client upgraded to 2.5
  • Spring security updated to 5.3.1, spring boot,data to 2.2.6, spring to 5.2.5

For a full list refer to the git commit logs.

Known Issues¶

• (https://github.com/odpi/egeria/issues/2935)[2935] - Governance Engine OMAS reports exception when entities added
• (https://github.com/odpi/egeria/issues/3005)[3005] - Occasional failure in 'Building a Data Catalog' notebook

Egeria Implementation Status at Release 1.7¶

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

Release 1.6 (April 2020)¶

Release 1.6 adds support for: * Audit Log Framework (ALF) technical preview * Repository Explorer (REX)

Below are the highlights:

• There is a new framework:

• The Audit Log Framework (ALF) provides interface definitions and classes to enable connectors to support natural language enabled diagnostics such as exception messages and audit log messages.

• There is a new user interface module:

  • The Repository Explorer (Rex) can help you explore and visualize the metadata in a repository. It retrieves entities and relationships from the repository and displays them. A details panel also shows the properties and other information about an object. Each entity or relationship is added to a network diagram, which shows how they are connected.

• The Swagger-based API documentation for the OMAG Server Platform has been reorganized to align with our modules structure and to provide links into our other documentation which also will clarify if the module is released, in Tech Preview, or still in development. The docs can be found at https://<server>:<port>/swagger-ui/index.html. Further enhancements will follow in future releases.

• Many dependencies have been updated including:

  • Kafka client upgraded to 2.4.1
  • Spring updated to 5.2.4, spring boot to 2.2.5 & other spring components accordingly.

For a full list refer to the git commit logs.

Egeria Implementation Status at Release 1.6¶

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

Release 1.5 (March 2020)¶

Release 1.5 delivers the automatic metadata discovery of duplicate assets. Additional, in Tech Preview, Data Engine OMAS, and a data engine proxy server.

Released Components¶

• The first governance server is released:
• The Discovery Server supports the scanning of assets and the notification when duplicate suspects are detected.

This server is supported by: * The Discovery Engine OMAS supports the detection, recording and notification of exceptions and duplicate suspects.

• The Open Discovery Framework (ODF) is now defined and implemented to support the interfaces for automated discovery services. It complements the Open Connector Framework (OCF) delivered in release 1.0.

• There are new tutorials, hands-on labs and samples demonstrating the new de-duplication detection features.

Technical Previews¶

• The Data Engine OMAS supports the processing of notifications from data engines such as ETL platforms in order to catalog information about the data movement, transformation and copying they are engaged in.

• The Data Engine Proxy Server is also included in the technical preview. It supports the polling of data engines such as ETL platforms in order to catalog information about the data movement, transformation and copying they are engaged in. It calls the Data Engine OMAS.

Egeria Implementation Status at Release 1.5¶

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

Release 1.4 (February 2020)¶

Release 1.4 focused on bug fixes and documentation.

Egeria Implementation Status at Release 1.4¶

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

Release 1.3 (January 2020)¶

Release 1.3 focuses on the support for open metadata archives, and formal versioning of open metadata types. It includes much of the groundwork for supporting design lineage and the detection and management of duplicate assets but that function is officially released in 1.4.

Below are the highlights of the 1.3 release:

• The hands-on labs have been updated to provide reusable Python functions for working with Egeria.

• The management of open metadata types includes formal versioning and patching of types. This makes it clearer where additions and updates are being made to the open metadata types. See open metadata types archive.

• There are the following changes to the open metadata types:

• The EmbeddedConnection has a new property called position.
• The OpenDiscoveryAnalysisReport has a new property called discoveryRequestStep.

• There is a new collection of Annotations for recording suspected duplicates and divergent values in acknowledged duplicates. This is to support the asset deduplication work scheduled for the next release.

• There are new open metadata archive utilities for creating your own open metadata archives. See the open connector archives and design model archives.

• The Conformance Suite Repository Workbench is now at Version 1.1, with the following enhancements:

• Tests for relationship searches have moved into a separate, optional RELATIONSHIP_SEARCH profile. A repository connector can be fully conformant with the (mandatory) METADATA_SHARING profile despite not supporting the findRelationshipsByProperty or findRelationshipsByPropertyValue methods.

• The ADVANCED_SEARCH profile is now divided into two profiles: ENTITY_ADVANCED _SEARCH and RELATIONSHIP_ADVANCED_SEARCH. They are both optional profiles. A repository connector can be fully conformant with the ENTITY_ADVANCED _SEARCH profile, despite not supporting either of the RELATIONSHIP_SEARCH or RELATIONSHIP_ADVANCED_SEARCH profiles.

• New test verify the correct handling of mappingProperties in the InstanceAuditHeader.

• The tests for 're-home' of a reference copy now use an instance mastered by a third (virtual) repository rather than the CTS Server's repository.

• Type verification of relationship end types now cater for connectors that do not support all the supertypes of an entity type.

• Search result checking is improved.

• The CTS notebook (under open-metadata-resources/open-metadata-labs) has been enhanced:

  • The Conformance Profile Results cell there is additional reporting for the new profiles

  • A new cell "Polling for Status" shows how to determine whether the repository-workbench has completed its synchronous tests. The new API it demonstrates could be used to support automated testing

  • A new cell "Monitoring Progress" show how progress can be monitored based on workbench results retrieved during a test run.

  • Improvements to HTTP response checking and reporting of errors

Egeria Implementation Status at Release 1.3¶

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

Release 1.2 (December 2019)¶

Release 1.2 provides the ability to build an asset catalog, search for assets and also access the data and function provided by these assets. It is also possible to group Assets into governance zones to control the discoverability and visibility of the Assets.

In addition, we release the Egeria conformance test suite and four conformant repositories.

Below are the highlights:

• A conformance test suite that validates implementations of open metadata repository connectors. In addition, we are highlighting the repositories that are conformant. These are:

  • The JanusGraph metadata repository.
  • The In-memory metadata repository used for testing and demos.
  • The Apache Atlas repository proxy.
  • The IBM Information Governance Catalog repository proxy.

• There are new access services to support the cataloging of assets:

• The Asset Consumer OMAS supports the access to both the data and metadata associated with an asset.
• The Asset Owner OMAS supports the manual cataloging of new Assets.

The assets cataloged by these access services can be scoped by governance zones.

• The metadata servers and future governance servers running on the OMAG Server Platform support metadata-centric security that is controlled by a connector. This connector can validate access to individual servers, services, and assets based on the identity of the caller and the service or asset they wish to access.

• The Open Metadata Repository Services (OMRS) have been enhanced to support dynamic types and type patching. There is also function to load archives of metadata instances.

• There are tutorials, hands-on labs and samples demonstrating the new Asset cataloging capabilities.

Egeria Implementation Status at Release 1.2¶

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

Release 1.1 (November 2019)¶

Release 1.1 focuses on establishing a secure, multi-tenant platform for metadata servers and governance servers. There is also a new JanusGraph based metadata repository.

Below are the highlights:

• A persistent metadata repository based on JanusGraph.

• A multi-tenant OMAG Server Platform that is able to host one to many metadata servers and/or governance servers. This platform supports APIs to administer servers, start and stop servers and query their status. The platform offers a connector to change the store used for configuration documents and to control who can issue platform API calls.

• There are now tutorials and hands-on labs demonstrating the configuring and start up of servers on the OMAG Server Platform. The aim is to help people to get up and running with the Egeria technology. In addition, there are both docker scripts and Kubernetes helm charts to deploy the platforms and related technology used in the tutorials, samples and labs.

• Note that currently we do not push release specific docker containers to dockerhub. If you are using the docker/kubernetes environments it is recommended to work from the 'main' branch instead of this release. This will be addressed in a future release.

• The Open Metadata Repository Services (OMRS) shipped in the first release have been enhanced with REST APIs to query the cohorts that a server is connected to. There are also REST APIs to issue federated queries across the cohorts that a metadata server is connected to.

• There is a new user interface to explore the open metadata types. It is called the Type Explorer.

Release 1.0 (February 2019)¶

Release 1.0 provides the open metadata integration and exchange between metadata repositories:

• The Open Connector Framework (OCF) provides standard interfaces for implementing connectors. These are used to access the data stored in Assets and to plug in platform capabilities into the Open Metadata Repository Services (OMRS).

• The implementation of the Open Metadata Repository Services (OMRS). The repository services provide support for the open metadata types, the interfaces used by a repository technology the wants to support the open metadata protocols, the event management for open metadata replication and the cohort registration and management.

The repository services can be used as embeddable libraries in technologies that wish to participate in an open metadata repository cohort.