Potential Experiments/areas to tackle

Build customized containers with only the content required for a particular usage:

• Start with integration connector
• figure out approach to gathering correct runtime dependencies easily
• figure out parameterization needed to make this a useful starting point for orgs
• Exclude: 

Value: Can help in short term with existing model - already see need for this

Create a streamlined application which can startup a single server (and shutdown cleanly - we have concern here with egeria) when application is launched, based off an existing configuration.

Should be runnable from the command line, and just launch as a process. It can consume files/environment variables (in k8s these can be mapped from config maps, secrets etc). will not update configuration

Figure out how much, if any, of existing platform/admin is needed/can be reused.

Specifically needs to be able to run a server hosting an integration connector

Value: Could be used even in short-medium term as a convenience to start single platform

Create custom resource definition for a 'server' (just 1 per 'platform' aka java process) & create an operator that can deploy/undeploy a pod containing running this server, as well as a service based on a pre-existing configuration:

• probably Java (rather than go) - general team skills?
• use autostart as an initial 'hack'

Value: Allows for active management in k8s environment

Document our design principles ie only use of ephemeral storage (create another wiki page?)

Value: Information sharing, reviews, consensus

Determine how egeria server has no dependency on persistent storage – ie which connectors/mechanisms are needed for storage ie potentially including

• Configuration
• Cohort registry
• audit log
• (metadata repositories)

Consider use of existing kubernetes resources - directly or via mapping -  config maps, secrets, custom resources

Look at read/write, concurrent access from multiple servers or replicas (for example we know config documents get written to during startup)

All must be accessible from a k8s operator in addition to other ways

Develop appropriate connectors and/or techniques to support

Excluded: security connector

Value: Simplification and ultimately critically important in k8s environment

nigel

taylan

Ensure configuration 'makes sense' at runtime. 

Review configuration

For example endpoints may refer to other servers within a k8s cluster, or to 3rd party technologies externally. Late binding is exactly needed.

Consider metadata collection id - may need to assert value

Some information required to be kept secret - auth info, certs. these must be able to be pointed to - ie in a key store, or something like a k8s secret

Develop proposal to handle. For example it may be sufficient to use hostnames which can be easily defined by an org in dns (static environments) or by k8s services

we don't think this is an issue

 - just preconfig the metadata colection id

 - host mapping should work for endpoints

• certs etc point to locations on filesystem - just need to map to mounted volumes from configmaps etc.,

• what benefits?
• interoperable with spring services?