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