Uploaded image for project: 'Operator Ecosystem'
  1. Operator Ecosystem
  2. OPECO-1893

Hybrid "Helm + Go" SDK as "Helm Operator, Mark II" (Tech Preview)

XMLWordPrintable

    • Hybrid "Helm + Go" SDK is the "Helm Operator, Mark II" (Tech Preview)
    • False
    • False
    • Done
    • OCPPLAN-7775 - Operator-SDK enables hybrid operators
    • OCPPLAN-7775Operator-SDK enables hybrid operators
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined
    • L

      Epic Goal

      Graduate from the “prototype” stage and make this "Helm + Go SDK" as the official "Helm Operator, Mark II", Tech Preview.

      Why is this important?

      • Easy to create an Operator with Helm charts that go beyond just "basic install"/"basic upgrades" (Level I/II) by supporting them to add application-specific/Ops logic in Golang.
      • With Helm Operators, Mark II, users get a lot of higher-level capabilities from Golang Operators for free, e.g. enable Metrics, create/managing webhooks with OLM, etc.
        • e.g. "scaling of clustered Operands" (Level III), "exposing metrics about its health" (Level IV), "exposing performance metrics about the Operand" (Level IV), or "auto-scaling based on exposed metrics (Level V)".
      • Making this hybrid "Helm + Go" SDK as the official "Helm Operator, Mark II" helps our partners using Helm Operators to easier increase/elevate their Operator Capability Level and improve our overall maturity of the Operator ecosystem as a whole.

      Scenarios

      1. Application Developers looking to create Kubernetes Operators with minimal extra work.
      2. Helm Chart maintainers/users want to manage the lifecycle of their applications with an Operator.
      3. Devs/users of stateful apps that are currently delivered using Helm charts that require Day 2 operations (e.g. backup, restore, failover, failback) that would like to build an Operator for supporting full lifecycle of their apps.
      4. Devs who build apps require specific additional orchestration logics for post-installation, upgrading, or reconfiguration.
      5. Users looking to build easy Operators to manage their helm charts.

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...
      • Graduate the hybrid "Helm + Go" SDK from prototype as the de facto "Helm Operator, Mark II".
      • A Helm Operator, Mark II" that supports all Helm Operator use cases + the additional capability that enables through the hybrid "Helm + Go" SDK as "Tech Preview".
      • Use scaffolding to create a sample Operator with reconciliation hook support (in Golang) + from existing Helm charts.
      • Upstream doc that provides tutorials and examples similar to the current Helm Operator.
      • Updated Github repo readme to give overview and intro to the "Helm + Go" value prop and links to the upstream doc for details.

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            fvonfeil@redhat.com Fabian von Feilitzsch
            rhn-coreos-tunwu Tony Wu
            Jia Fan Jia Fan
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: