Giters

carvel-dev / kapp

kapp is a simple deployment tool focused on the concept of "Kubernetes application" — a set of resources with the same label

Home Page:https://carvel.dev/kapp

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Waiting for an API to exist

scothis opened this issue · comments

commented

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.

commented

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?

commented

@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.

commented

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 🙌🏼

commented

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