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

feature: issue events on the source objects #17

Open
1 task
xrstf opened this issue Feb 3, 2025 · 2 comments
Open
1 task

feature: issue events on the source objects #17

xrstf opened this issue Feb 3, 2025 · 2 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@xrstf
Copy link
Contributor

xrstf commented Feb 3, 2025

Feature Description

The agent should, especially if a sync is unsucessful, issue an event on the source object in kcp to inform the user.

Ideally in a perfect world, the agent would also patch-in a new subresource, like "syncStatus", onto each CRD it turns into an APIResourceSchema. The agent could then use this new subresource to store additional information like conditions, which could then also be easily digested and used by a kcp UI.

Proposed Solution

Issue events or extend the schema as outlined above.

Alternative Solutions

No response

Want to contribute?

  • I would like to work on this issue.

Additional Context

No response

@xrstf xrstf added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 3, 2025
@xrstf xrstf self-assigned this Feb 4, 2025
@xrstf
Copy link
Contributor Author

xrstf commented Feb 6, 2025

The agent should, especially if a sync is unsucessful, issue an event on the source object in kcp to inform the user.

Actually, thinking more about this, I think this isn't true. The endusers have no influence over the syncing process and the events would be of little help to them. Additionally, events that contain error messages would leak details about the service cluster.

If anything, the event should be on the service cluster side, where the responsible entity can deal with it.

@xrstf
Copy link
Contributor Author

xrstf commented Feb 10, 2025

After talking with The Marvin, we have decided to try to issue events after all, but only if the syncagent encounters an "Invalid" error (i.e. HTTP 422 Unprocessable Entity).

However that's currently not possible because client-go's EventRecorder interface does not take a context, so it cannot switch workspaces based on the context, plus it does some internal batching. To fix that the batching would need to remember the workspace for each event. Alternatively we would need to manually create the event, circumventing the whole Broadcaster/EventRecorder logic in client-go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

1 participant