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

kctrl dev reconciler does not report an Error back #1482

Open
jorgemoralespou opened this issue Feb 13, 2024 · 0 comments
Open

kctrl dev reconciler does not report an Error back #1482

jorgemoralespou opened this issue Feb 13, 2024 · 0 comments
Assignees
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed

Comments

@jorgemoralespou
Copy link

jorgemoralespou commented Feb 13, 2024

What steps did you take:
We're using this code as library in our project (educates)[https://github.com/vmware-tanzu-labs/educates-training-platform] for deploying the platform as an Application reusing the capabilities of the dev command, as we only need to deploy our bits in the cluster but we don't need further reconciliation.

What happened:
When using this code as library , appReconciler.Reconcile ignores reconcile.Result as it's not giving any valuable information about the reconciliation status or errors if they happened at any of the internal phases (fetch, template, deploy).

What did you expect:
We expected that appReconciler.Reconcile would return a meaningful reconcile.Result with internal information of the reconciliation status, so that we could know if it failed or was successful and if it failed, on which phase (fetch, template, deploy) failed, and potentially the reason of failure. Currently there's only possible by looking at the logs printed on output.
As the real implementation of appReconciler is supposed to run in the cluster, this information is somehow added to the App status that lives in the cluster, but for dev mode where there's no App living in the cluster it'll be ideal to have this information reported back somehow to the consumer/client.

Anything else you would like to add:
Some conversation about this on Kubernetes slack

Environment:

  • kapp Controller version (execute kubectl get deployment -n kapp-controller kapp-controller -o yaml and the annotation is kbld.k14s.io/images): v0.50.0
  • Kubernetes version (use kubectl version): Irrelevant

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.

@jorgemoralespou jorgemoralespou added bug This issue describes a defect or unexpected behavior carvel-triage This issue has not yet been reviewed for validity labels Feb 13, 2024
@renuy renuy added carvel-accepted This issue should be considered for future work and that the triage process has been completed and removed carvel-triage This issue has not yet been reviewed for validity labels Mar 5, 2024
@renuy renuy moved this to Prioritized Backlog in Carvel Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed
Projects
Status: Prioritized Backlog
Development

No branches or pull requests

3 participants