Closed planetf1 closed 3 years ago
github-actions[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.
planetf1
commented
3 years ago The operator is being redesigned.
Configuration will use k8s resources (crd for the platform definition, secret for the config)
Persistent storage will be associated with a platform (which can be replicated), and the server-platform assignment will be static, as managed by the Egeria configuration file. However this will be replica-specific - so for example will assist with logs, cohort store, caching - but cannot be used to manage a metadata repository. For that a repository such as crux will be required
However the operator, in only consuming an Egeria config file, will not have any direct knowledge of crux (or any other storage). It will simply faithfully record & deploy the requested config of Egeria. Therefore this testing/setupof crux will need to be managed manually, via a crux operator, or a crux enabled helm chart
Closing and will open up a specific issue to provide a crux enabled demo chart
When an egeria pod is started by the operator, currently no persistant storage is added
We need to consider what persistance is needed by an individual platform.
If configuration is driven by the k8s operator, then the cohort registry/config need not be persistent If any persistant metadata store is external (janus, cassandra) then again, it may be no persistanec is needed. Indeed this may then make scaling easier.
However the flexibility to do this has quite a few pieces of work needed to make it happen - ie sourcing a janus or cassandra store, and having enough capability in the operator to deploy a full configuration . So in the interim a per-pod PVC (persistant volume claim) may be the simplest, quickest way to get started
Refer to #2 for linking up on naming strategies