Don't exit at first error but continues and summarizes all the found ones at the end of execution

[N00BEST]

Describe the problem/challenge you have
We want to use kapp to reconcile our e2e tests. We're trying to deploy multiple CRs that don't depend on each other, they can be deployed in parallel. There's no dependency between CRs, so if any of those fails it should not stop the other ones from being reconciled. Currently the kapp command is exiting as soon as it finds an error, with a message like this one:

kapp: Error: waiting on reconcile customresource/resource-name namespace: default:
  Finished unsuccessfully (Encountered failure condition Succeeded == False: Error (message: The job did not complete successfully))

So we're not getting feedback about the success/failure of all the other CRs that were trying to get reconciled.

Describe the solution you'd like
We would like a new CLI argument (e.g.: --ignore-errors or --no-abort) or a new configuration field to indicate to the kapp CLI to wait for all the possible results before exiting, indicating which ones failed in which steps of the reconciliation process.

Output would look like: "Reconciled 10/20. Finished unsuccessfully: 5. Finished successfully: 5. Not deployed: 10."

Anything else you would like to add:
The configuration file we're using to replicate this issue looks something like this:

apiVersion: kapp.k14s.io/v1alpha1
kind: Config

waitRules:
  - supportsObservedGeneration: true
    conditionMatchers:
      - type: Succeeded
        status: "True"
        success: true
      - type: Succeeded
        status: "False"
        failure: true
    resourceMatchers:
      - andMatcher:
          matchers:
            - apiVersionKindMatcher: {apiVersion: my-custom-resource-definition.com/v1beta1, kind: CustomResource}
            - hasAnnotationMatcher: { keys: [kapp-matcher-success] }
  - supportsObservedGeneration: true
    conditionMatchers:
      - type: Succeeded
        status: "False"
        success: true
      - type: Succeeded
        status: "True"
        failure: true
    resourceMatchers:
      - andMatcher:
          matchers:
            - apiVersionKindMatcher: {apiVersion: my-custom-resource-definition.com/v1beta1, kind: CustomResource}
            - hasAnnotationMatcher: { keys: [kapp-matcher-failure] }

---

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.

[rohitagg2020]

@N00BEST, I have a couple of clarifications I needed to ask:

• Is this behavior required during the reconciliation only or lets say If we want to deploy 10 resources, and few of them fails(e.g in case say, CRD for CR doesn't exist on server). Then also we should continue to reconcile or abort like we do today?

[N00BEST]

Hello, @rohitagg2020

It's ok for the behavior to happen just during reconciliation. If the error happens before reconciliation, kapp can abort like it does today.

[cppforlife]

one thing that's been on my mind some time ago... currently kapp aggressively exits on first failure, even though there might be more resources that can be applied to the cluster (because they dont depend on other resources via change rules). i was thinking should we actually change default behaviour to apply as many resources as possible and report all collected failures.

[rohitagg2020]

Thanks @N00BEST and @cppforlife, will incorporate above feedback.