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

Waiting for an API to exist #816

Open
scothis opened this issue Sep 7, 2023 · 4 comments
Open

Waiting for an API to exist #816

scothis opened this issue Sep 7, 2023 · 4 comments
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome.

Comments

@scothis
Copy link
Contributor

scothis commented Sep 7, 2023

Describe the problem/challenge you have

When a CRD and a CR exist within the same app, kapp will create the CRD, wait for the new API to become available and then create the CR using that API. If the CRD is created indirectly (like as the result of some other resource being reconciled) kapp has no direct way to indicate that it should wait for the new API to exist. It will currently bail out before applying any changes with an error the the CRs GVK is unknown.

It's possible to hint to kapp that the API will exist via the exists annotation on a CRD, as documented in this blog post. While this approach can work for CRD defined resources, there are other ways to define an API that are not covered, like an aggregated API.

How an API is defined should be opaque to users. What's important is that an API is defined. Expecting users to know that an API is defined as a CRD violates the encapsulation of the resources that created it.

Describe the solution you'd like

I'd like a way to indicate that kapp should wait for an API to exist for a resource rather than fail fast, without needing to know any detail about how that API is defined. On deploy, kapp will not fail for a resource for this API that doesn't exist on the API server, the resource will be created once that API becomes available.

As an annotation this can look like:

apiVersion: example/v1
kind: MyResource
metadata:
  annotations:
    kapp.k14s.io/wait-for-api-to-exist: ""

In the kapp config this can look like:

waitForAPIsToExist:
- apiVersion: example/v1
  kind: MyResource

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@scothis scothis added carvel triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Sep 7, 2023
@100mik
Copy link
Contributor

100mik commented Sep 7, 2023

It seems like you might be able to use kapp.k14s.io/exists to achieve this.
I think the issue at hand is pretty similar to what we had here #52.

Does this resolve your use case as well?

@100mik 100mik added helping with an issue Debugging happening to identify the problem and removed enhancement This issue is a feature request carvel triage This issue has not yet been reviewed for validity labels Sep 7, 2023
@scothis
Copy link
Contributor Author

scothis commented Sep 7, 2023

@100mik yes, I'm aware of the exists annotation. Please read the issue. I'm trying to point out a deficiency in the current behavior as designed, not looking for a work around.

@100mik
Copy link
Contributor

100mik commented Sep 7, 2023

Ah, apologies! I missed that bit.
It does indeed not cover cases where the API resource is not introduced by a CRD. I think we could pull this into our backlog and then prioritise it.

Is this something that is blocking you right now? if so we could definitely bump this up the list 🙌🏼

@100mik 100mik added carvel accepted This issue should be considered for future work and that the triage process has been completed priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome. and removed helping with an issue Debugging happening to identify the problem labels Sep 7, 2023
@scothis
Copy link
Contributor Author

scothis commented Sep 8, 2023

Not blocking anything, I can get by with the exists annotation on a CRD. Just calling out the design gap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome.
Projects
Status: No status
Development

No branches or pull requests

2 participants