-
Notifications
You must be signed in to change notification settings - Fork 86
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
Comments
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? |
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? |
Please take a look at #335, let me know if you have any feedback. |
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
andlatestVersion
.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
storingtargeted nodes
,latestHash
andlatestVersion
.Additional context
None, but i'm happy to share more context if needed.
The text was updated successfully, but these errors were encountered: