Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to wait for CRD Resources to be ready #47

Open
rmb938 opened this issue Apr 24, 2020 · 5 comments
Open

Ability to wait for CRD Resources to be ready #47

rmb938 opened this issue Apr 24, 2020 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@rmb938
Copy link

rmb938 commented Apr 24, 2020

Describe the solution you'd like to see

The ability to give a json path (or something similar) to wait for a certain value before the resource is considered ready.

Describe alternatives you've considered

Local exec to use kubectl and make a dependency chain somehow?

Additional context

Some CRDs have things in their status to determine if they are ready or not. So for example a cert-manager certificate.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: my-cert
spec:
  dnsNames:
  - example.com
  issuerRef:
    kind: ClusterIssuer
    name: aws-pca
  secretName: cert-thanos
status:
  conditions:
  - lastTransitionTime: "2019-11-26T17:22:36Z"
    message: Certificate is up to date and has not expired
    reason: Ready
    status: "True"
    type: Ready
  notAfter: "2020-06-23T17:22:41Z"

Having some sort of way to select the Ready condition and waiting for it to be true.

Making something universal to work with any crd may be a bit difficult.

@mcristina422
Copy link

Some CRDs don't have simple status attributes that can be checked with a single JSONPath ( Like Conditions on Cert-manager Certificates ). A higher level language may be needed to parse the correct status. Argo (a k8s CI/CD tool) uses lua https://argoproj.github.io/argo-cd/operator-manual/health/

@bonifaido bonifaido self-assigned this Apr 27, 2020
@bonifaido
Copy link
Member

bonifaido commented Apr 27, 2020

I'm really open to integrate something like this into the provider, I have faced the issue several times, and we have built-in "wait for status" for the most common standard resources only.

What about using https://github.com/google/cel-go instead of Lua, it is much more embeddable and we won't need a full-blown VM here in a terraform provider :)

@bonifaido bonifaido added the enhancement New feature or request label Apr 27, 2020
@rmb938
Copy link
Author

rmb938 commented Apr 27, 2020

I never personally used CEL but it looks like it could work.

@mcristina422
Copy link

Hopefully the community can converge on some common status like kubernetes/enhancements#1624

@mh013370
Copy link

Why not mimic the behavior in the kubernetes provider?

https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/manifest#wait_for

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants