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

feat: Set status Git/BucketStateStores #247

Open
aclevername opened this issue Oct 2, 2024 · 3 comments
Open

feat: Set status Git/BucketStateStores #247

aclevername opened this issue Oct 2, 2024 · 3 comments

Comments

@aclevername
Copy link
Member

aclevername commented Oct 2, 2024

Context

Users would like to have feedback after they set up their State Store.

Update Git/BucketStateStores status, logs, and publish events to indicate wether it can successfully authenticate, and give reasonable errors back.

@aclevername aclevername self-assigned this Oct 2, 2024
@ChunyiLyu ChunyiLyu changed the title feat: Set status on Destinations and Git/BucketStateStores feat: Set status Git/BucketStateStores Jan 22, 2025
@ChunyiLyu
Copy link
Member

Update the issue to include publishing events, and only for State store.

Similar issue for Destination #330

@ChunyiLyu
Copy link
Member

Closing this one because:

  1. our set up requires people to create a StateStore and a Destination referencing that StateStore at the same time
  2. Destination at creation writes canary files to the StateStore while as StateStore creation does not connect to the StateStore

So we believe setting status in Destination will provide enough feedback to our users. Therefore picking up #330 and closing this issue.

@kirederik
Copy link
Member

In #330 we introduced Destination status. I think we should still implement State Store status for the following scenario:

  1. A secret is created
  2. A state store is created referencing the secret
  3. A destination is created referencing the state store. At this stage, the destination status is correctly set to Ready.
  4. User updates the secret; it's now wrong

Ideally that should trigger a reconciliation of the state store, and its status should now be "not ready". That, in turn, is already set to trigger a reconciliation of the destination -- which would update the destination status accordingly.

i suggest we reopen and implement this

@ChunyiLyu @catmo-syntasso wdyt?

@kirederik kirederik reopened this Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants