No persistence ie use connectors for config, cohort registry, secrets/configmaps/k8s docs for other config, only ephemeral storage otherwise immutable - should write down these principles
Containers - custom contents, limit to what is needed. Streamlined, reduce attack service
Strimzi - example
Authentication/security – closely related, and required for cloud native, IAM, access control, tokens, certs, keys -- but keep this discussion thread to other workgroups
Incremental vs full solution -concern over time to deliver. Aim for early results. Build upon what exists, wrappers
Think about pain points with existing design - most important to address
current startup is awkward - rest api calls to start. need init/script or external control (listen to recording for explanation)
needs to be easily specified to container
readiness - all in place, ie server vs kafka avoiding failures
Existing operator (unreleased) -
resource for platform, configmap for config.
But here probably want resource for server, and 1:1 mapping as platform is now k8s managed
config can contain endpoint info. Replace? Or just stick with symbolic names as can setup that up in egeria (as vdc/igc used - cluster dns)
reconciliation an important concept
Possible simple capability ie an integration service
needs the right base container
additional connectors to store data outside k8s (IBM use cloudant, ING tried mongo. Postgres? But k8s simpler?)
cohort registry
k8s is startup managed - not via existing admin services (new application, not chassis? spring? other?)
top level defined by config (k8s ie resource definition), details by existing config carried in k8s docs (ie yaml in configmap)
15 Mar - plan for Emily to talk about microprofile
Image from web recording above
Actions
(All) think about potential poc, and which aspects you could work on over a matter of weeks to then discuss
