Enable operator to deploy a set of named platforms

[planetf1]

Currently the egeria operator can deploy 'n' platforms, governed by the 'size' attribute in the CRD These use auto-generated names - though the controller does save/know what they are called

When we deploy egeria - such as for a lab - we tend to have some knowledge about the purpose of a particular platform in the infrastructure - ie to support the datalake, or developers.

We should consider allowing specific names (or name prefixes) at least to each running platform pod. Alternative these could be descriptions (annotations) to make them easy to find, but stick with auto generated names

[planetf1]

In egeria, a 'platform' (a java process listening on a port) is a container within which multiple logical servers may run Whilst platforms can be queried, they really exist only to support a server, and are not particularly interesting thing in their own right.

Considering how to map our 'platform' to k8s, we could allow these platforms to be created. However if we do we need to name them, and manage the connections (in the operator) between those platforms and servers.

A reminder on some of the base k8s concepts pod: the most simple deployment unit of computing consisting of a group of containers that are scheduled together, in the same place. Must be explicitly managed replicaset : adds management to pods & multiple copies to be easily created for scaling up/down deployment: builds on replicaset to handling rolling upgrades and other lifecycle aspects statefulset: builds on deployment with unique identify for each copy (seperate hostname) & integrated support for persistent storage

A stateful set would allow us to create platforms like egeria_1 egeria_2 egeria_3 each network addressible and with their own storage

However the 'specification' of each platform would be the same, and then we would need to manage the 'deployment' of the servers outself. Furthermore each of these platforms would not in itself be replicated (for redundancy). Finally there would be a single network service for access to the 'cluster' which is not how egeria is architected

So instead we need each egeria server to have a deployment or stateful set in it's own right. That can have storage and be scaled, but the creation of the named server is managed by the operator

Since the intent of using an environment like k8s is to support many concurrent services, it seems a prudent simplification to focus on the 'server' as the deployable unit that we're dealing with -- and make the assumption that we will have a 1:1 relationship between a server and platform, it seems as if adding the server itself is of little value

[planetf1]

For a specific server, having a stateful set makes sense since a) it has some state and b) we want a specific service endpoint for any of the replicas

Ultimately we should also consider how more state (like what is configured on the platform) could be extracted into static config files passed to the deployment, but moving the amount of state from some->0 is probably easier than the other way around.

So for now, the operator will have a list of servers (not platforms) and will create a stateful set for each

[github-actions[bot]]

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]

The operator is being redesigned. Closing this older issue in lieu of a different work breakdown aligned with the new design