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

Support mutability of permissions, topic permissions and bindings #755

Open
Zerpet opened this issue Jan 30, 2024 · 1 comment
Open

Support mutability of permissions, topic permissions and bindings #755

Zerpet opened this issue Jan 30, 2024 · 1 comment
Labels
enhancement New feature or request never-stale

Comments

@Zerpet
Copy link
Contributor

Zerpet commented Jan 30, 2024

Is your feature request related to a problem? Please describe.

It is not possible to update permissions, topic permissions or bindings at the moment. This is due to a limitation in the HTTP API, that does not directly support updates of these objects. However, we can keep a record of the existing permission/topic-permission/binding, and perform an "update" as delete existing, declare new.

Describe the solution you'd like

We can store inside an annotation the last good known state. That is, the last state after a successful API call to rabbit. Upon an update to a permission/topic-permission/binding object, we can infer the previous state from the annotation, delete the previous permission/topic-permission/binding, and create the new updated permission/topic-permission/binding with the information from the new request.

Additional context

We may need to ensure that only one reconcile is running for a given topology object. At the moment, multiple event sources may trigger a reconcile for a given object, resulting in parallel reconciles. Most of the time this has no side-effect, since the result of all the reconciles is the same. However, by deleting an object in rabbit, we would be causing a side-effect, and the previous assumption is not valid anymore.

@Zerpet Zerpet added the enhancement New feature or request label Jan 30, 2024
Copy link

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

@github-actions github-actions bot added the stale label Mar 31, 2024
@Zerpet Zerpet added never-stale and removed stale labels Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request never-stale
Projects
None yet
Development

No branches or pull requests

1 participant