2023-05-17 Cloud native workgroup

prototype description

David explained the thinking behind the 

'prototype', i.e. a construction phase followed by a

configuration then deployment phase. The running Egeria would not be dynamically configured.

There would be one image per config. The config is not written to by the running process.

Also mention the server author model to be used as a way to define servers and their capabilities

Dan suggested that there where the configuration may require additional jar files. Also mentioned that native connector XTDB an Janus have many different way to configure

which can impact Kubenetes storage allocations. David suggested a capability approach, some standard configs with particular SLAs could be useful. 

The problem of Egeria process coming up but not being usable is not addressed. We suggest maybe a 

per server type status endpoint could be appropriate. Juergen wanted to be told when the process was ready. Nigel suggested that polling for readiness

was K8S naturally would do this. There was potentially 2 readiness states / one that it could accept rest calls , the second that is was ready to participate in the cohort.    

Dan suggested that there were cases where a running Egeria might require it's

configuration changed. for example for password rotation. May be able to 'hide' this from the config

in the secrets connector.

We talked of needed to define use cases. Juergen mentioned 

• Data scientist:may require a new JDBC implementation without the need to create a full image 
• devops cicd engineer may be able to amend the image