(Release 3.3) Egeria container fails to start about egeria-charts

[planetf1]

This could be similar to an issue experienced by @sarbull & @marius-patrascu at https://lfaifoundation.slack.com/archives/C01F40J2XA8/p1635152393030500

However in that case a) I did not see the issue running the container b) the issue was resolved after a clean build

Need to review again 793a346b69d9373153ebf5b1ecfe288d0d7ebbec . There could be some relationship with jackson versions

It looks as if we may have a dependence on
com.fasterxml.jackson.dataformat
jackson-dataformat-yaml

but are not including it.

[planetf1]

Further update - on closer inspection, my local container image was old -- prior to that commit references above. As such my test re: the slack message would have been invalid (had just moved from docker to podman, and the process is a little different). That doesn't mean the code didn't work. I don't know...

Of note is that our automated tests ran ok, including merge tests? it is unclear why as in a local and container test the failure was immediate and fatal.

I'm not yet going to propose a simple backoff - going to look at if packaging has changed and if we need to include additional library/dependency.

Affects master+release

[planetf1]

This may be the cause

When the elastic search support was added we have a

   <dependency>
446
            <groupId>org.springdoc</groupId>
447
            <artifactId>springdoc-openapi-ui</artifactId>
@marius-patrascu
updated elasticsearch connector to save events to elasticsearch
17 days ago
448
            <exclusions>
449
                <exclusion>
450
                    <groupId>com.fasterxml.jackson.dataformat</groupId>
451
                    <artifactId>jackson-dataformat-yaml</artifactId>
452
                </exclusion>
453
            </exclusions>
@planetf1
odpi/egeria#1124 first pass of springdoc support
2 years ago
454
        </dependency>
        

This was added in 32ed9f248e6294f4b48db42ab65382ae4dec8e6a ( added in odpi/egeria#5733 )and may be causing the issue, as it could cause the required class to be skipped from inclusion in the jar. But it could also be co-incidence

[planetf1]

Removed above exclusion. Noted it wasn't excluded in gradle.

With this done, the assembly fails with:

17:15:04,699 [INFO] --- maven-enforcer-plugin:3.0.0-M3:enforce (enforce-versions) @ open-metadata-assemblies ---
17:15:05,499 [WARNING] Rule 5: org.apache.maven.plugins.enforcer.RequireUpperBoundDeps failed with message:
Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.10.4 paths to dependency are:
+-org.odpi.egeria:open-metadata-assemblies:3.4-SNAPSHOT
  +-org.odpi.egeria:elasticsearch-integration-connector:3.4-SNAPSHOT
    +-org.elasticsearch:elasticsearch-x-content:7.15.0
      +-com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.10.4
and
+-org.odpi.egeria:open-metadata-assemblies:3.4-SNAPSHOT
  +-org.odpi.egeria:server-chassis-spring:3.4-SNAPSHOT
    +-org.springdoc:springdoc-openapi-ui:1.5.12
      +-org.springdoc:springdoc-openapi-webmvc-core:1.5.12
        +-org.springdoc:springdoc-openapi-common:1.5.12
          +-io.swagger.core.v3:swagger-integration:2.1.11
            +-io.swagger.core.v3:swagger-core:2.1.11
              +-com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.12.1
]

This is an inconsistency between the elasticsearch integration connector and swagger.

Crucially we must have a working core egeria platform - so the options are:

• backlevel components - but our policy is to keep up to date as much as we can to reduce security impacts. Jackson in particular has had many exposures in the past
• remove swagger - though it's far from perfect, we know plenty of people are using this
• force a common version between the two usages (our usual approach) . Notably we already have the same approach for many jackson components, and pinning the version here maintains consistency with the broad spectrum of jackson libraries we use
• If this doesn't work, the integration connector could use a shaded library to ensure it is using it's preferred version

3 above is the most desirable, so will create a PR along those lines

cc: @marius-patrascu @lpalashevski - is this ok for you

Since this is a complete breakage of the chassis I will merge this PR if tests pass, and if we need to change the fix we will do so in a subsequent PR. I will then continue with release testing (Including the open lineage notebook)

[planetf1]

After fix:

 chassis                                                                                         [17:41:23]
 Project Egeria - Open Metadata and Governance
    ____   __  ___ ___    ______   _____                                 ____   _         _     ___
   / __ \ /  |/  //   |  / ____/  / ___/ ___   ____ _   __ ___   ____   / _  \ / / __    / /  / _ /__   ____ _  _
  / / / // /|_/ // /| | / / __    \__ \ / _ \ / __/| | / // _ \ / __/  / /_/ // //   |  / _\ / /_ /  | /  _// || |
 / /_/ // /  / // ___ |/ /_/ /   ___/ //  __// /   | |/ //  __// /    /  __ // // /  \ / /_ /  _// / // /  / / / /
 \____//_/  /_//_/  |_|\____/   /____/ \___//_/    |___/ \___//_/    /_/    /_/ \__/\//___//_/   \__//_/  /_/ /_/

 :: Powered by Spring Boot (v2.5.5) ::

2021-10-28 17:41:33.290  INFO 41487 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 9443 (https)
2021-10-28 17:41:40.823  INFO 41487 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 9443 (https) with context path ''

Thu Oct 28 17:41:35 BST 2021 No OMAG servers listed in startup configuration
Thu Oct 28 17:41:40 BST 2021 OMAG server platform ready for more configuration

[planetf1]

With the main builds having rerun

• master - docker container now starts up correctly (podman, docker.io+quay.io)
• 3.3 - docker container starts up (podman - docker.io). quay.io image is missing - will fix in odpi/egeria#4046

[planetf1]

This is still occuring with the latest helm charts ie for 3.3:

  Normal   Started         24s (x2 over 53s)  kubelet            Started container egeria
  Normal   Pulled          24s                kubelet            Successfully pulled image "quay.io/odpi/egeria:3.3-SNAPSHOT" in 1.082747989s

giving the error.

Yet running the containers standalone with podman, for both the 3.3 & latest (3.4-SNAPSHOT) images is now working correctly - prior to the fixes here that too was failing. Updated 'docker-compose' environment is also working!

This means we still have a problem in openshift which must either be

• Caching issues with deployment of the chart (despite the logs reporting the image was pulled)
• Specific environment issue in the k8s configuration

Transferring this issue to the charts repo now that the underlying issue is resolved, and reopening

[planetf1]

Located the issue - the log above reports the image is being pulled from '3.3-SNAPSHOT' (which has the bug) rather than '3.3' (which contains the final fix)

[planetf1]

In the 'values.yaml', though imageDefaults.tag was set to '3.3', egeria.version was set to '3.3-SNAPSHOT', it is this variable that is used for all core egeria images, whilst the image defaults tag is used for non egeria versions

[planetf1]

Fixed in #90