operator-framework / operator-framework/operator-sdk

Helm operator : Get status of dependent resources

Open
#2,491 23 comments 4 reactions 1 assignee View on GitHub

@joelanford is already working on this.

Since Feb 3, 2020.

kind/feature language/helm lifecycle/frozen needs discussion
Dominant language
Go
Stars
7.7k
Forks
1.8k
PR merge metrics
No merged PRs in 30d

Description

Feature Request

I have recently discovered the helm-operator. I really like the simplicity to maintain the definitions of releases and how the operator watches the parent definition as well as the dependent resources and have started migrating some of our deployments to it.

As a status, the operator returns the status of the deployment itself in status.Conditions as well as the status.deployedRelease name and manifest.

I find missing a way to add to custom columns the status (or any other field) from the dependent resources if watchDependentResources is true.

For example, I was thinking about having an optional field to watches.yaml, such as :

- version: v1alpha2
  group: lp.ml.io
  kind: Service
  chart: helm-charts/lp-service
  statuses:
    - version: v1
      group: ""
      kind: Pod
      name: podReadiness
      jsonPath: ".status.conditions[?(@.type=='Ready')].status"

This indicates to add a field status.podReadiness to CRD, having the value of Ready condition from child Pod.

This would allow the CRD to add columns like :

[...]
  additionalPrinterColumns:
    - JSONPath: .status.podReadiness
      description: status of the deployed Pod
      name: Ready
      type: string
[...]

and therefore have the statuses of the dependent resources in the get operation of the CR.

I can't estimate the complexity of the implementation yet.

As a Watch is already registered on the dependent resources, I guess the feasibility of the change depends on a status change being catchable by DependentPredicateFuncs. Does a status change trigger UpdateEvent ?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.