Requirements & Constraints

  • Security/secrets not directly addressed - scope of other discussions, but relevant here - especially exposed via environment/files
  • Beyond config/repositories (stored externally via connectors/standard k8s objects), Only ephemeral storage - otherwise immutable. Declarative
  • One egeria server per pod
  • Aim for early results, build on what exists
  • top level server definition/type in k8s object, but most config remains in json document(s)
  • Integration use-case
  • Multiple stages: assembling a container (capabilities) vs deploying


  • Education on eclipse microprofile
  • Identified list of experiments/investigations
  • Example application which runs only a single server (no platform configuration). See PR . Addresses biggest pain point of having to run rest API calls to configure egeria server after container started
  • Repo created for experiments

Other recent achievements in k8s charts/containers

  • More connectors have an associated docker container, built using the same version of Egeria as that the connector pre-reqs
  • As part of Java 17/Egeria 4 work, containers are now using a Java 17 UBI-9 containers, which also now contains more tools (sdk, not just runtime) to facilitate monitoring/debugging - BUT we need to understand more around sizing (memory, limits, k8s...)
  • Atruvia's contributions to helm charts are merged which provides more configurability on the base chart (such as Kafka endpoints), and provision of a new lineage chart (which still needs some fixes)
  • For lab charts, storage class now configurable
  • 'snippet' samples for helm charts

Other work in progress/to be done

  • Memory footprint - currently JVMs may grow until container environment kills them. Support added to limit resources, but default remains unlimited as unable to get a stable environment

Next Steps

  • No labels