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

No history of a updated plan #238

Closed
siredmar opened this issue May 3, 2023 · 3 comments
Closed

No history of a updated plan #238

siredmar opened this issue May 3, 2023 · 3 comments

Comments

@siredmar
Copy link

siredmar commented May 3, 2023

Is your feature request related to a problem? Please describe.
The problem is, that i can not possibly know which plan was applied to the node in the past. I know, that nodes get labeled with the latestHash of succeeded plans. However, if i simply update the same plan, i'm losing this kind of history information.

Describe the solution you'd like
Maybe the controller can create events for that plan resource that state the targeted nodes, latestHash and latestVersion.

Describe alternatives you've considered
Another possible solution would be to introduce a new CRD that keeps track of revisions of succeeded plans, e.g. planRevisions storing targeted nodes, latestHash and latestVersion.

Additional context
None, but i'm happy to share more context if needed.

@dweomer
Copy link
Contributor

dweomer commented May 6, 2023

Original author here (but not employed with SUSE):

I've always thought that an event should be sufficient but never dug into how to make the wrangler library emit them. I imagine it wouldn't be too difficult and I have some time on my hands, I may take a stab at such.

As for a CRD, an idea complimentary with events that I've also thought about, it seems a bit too meta for the aims of this project, I think. I am open to being convinced otherwise, however, can you share more detail of your use case that has made evident this need from SUC?

@brandond
Copy link
Member

brandond commented Aug 24, 2023

Events generally roll off after a couple hours so they're not great from an audit perspective, but I guess they can at least be audited and logged somewhere.

Helm charts handle this by storing information about old releases in the chart secret, but I'm not sure I like that for plans. What specific information about an old plan would you want to have stored? If you want the entire plan snapshotted, maybe you just need to move towards a GitOps approach, and keep the plans checked into a repo somwhere?

@brandond
Copy link
Member

brandond commented Nov 2, 2024

Please take a look at #335, let me know if you have any feedback.

@brandond brandond closed this as completed Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants