• Discuss potential poc


  • 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


  • (All) think about potential poc, and which aspects you could work on over a matter of weeks to then discuss


  • No labels