2023-02-22 Cloud Native Workgroup Minutes

22 Feb 2023

Attendees

Agenda

Discuss potential poc

Discussion

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

Recording

Recording