Events are cleaned up if the resource is deleted

[gauravgahlot]

Description

Going forward if a resource (template, hardware, workflow, ...) is deleted, all the events for that particular resource will also be cleaned up (irrespective of configured TTL).

Why is this needed

Fixes: #396

How Has This Been Tested?

• Manually over vagrant setup
• Unit Tests

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

[codecov]

Codecov Report

Merging #407 (4d7b2b2) into master (ad5c929) will increase coverage by 0.02%.
The diff coverage is 20.00%.

@@            Coverage Diff             @@
##           master     #407      +/-   ##
==========================================
+ Coverage   21.38%   21.40%   +0.02%     
==========================================
  Files          24       24              
  Lines        2170     2191      +21     
==========================================
+ Hits          464      469       +5     
- Misses       1664     1679      +15     
- Partials       42       43       +1     

Impacted Files	Coverage Δ
db/hardware.go	0.00% <0.00%> (ø)
db/workflow.go	0.20% <0.00%> (-0.01%)	⬇️
db/template.go	36.49% <62.50%> (+1.88%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ad5c929...4d7b2b2. Read the comment docs.

[gianarb]

I am still not 100% sure that this is a valuable solution. Or the solution we want. And I want to ask @invidian to help me with this.

@gauravgahlot this solution as it is today has at least 1 issue. it is deleting all the events for a particular resource when it gets deleted. It also deletes the event that notifies that a resource is deleted I presume, it means that users and applications that rely on events to synchronize an external system or to build automation will have a hard time dealing with a deletion.

Excluding the event kind DELETED will be enough? Probably no.

Scenario: A user wrote an "audit logger" that tracks all the actions made via Tinkerbell with the default TTL of 1h. The extension for some reason stays offline for 30 minutes and in that hour the hardware gets created, updated, and deleted it will be impossible to reconstruct that part of the history. IMPOSSIBLE because events are not stored anywhere anymore.

I still think events should be immutable with the only exception of the garbage collector having the power of removing them. How Kubernetes handle this problem for example? Do we know?

Thanks

[gauravgahlot]

AFAIK, if we delete a resource in Kubernetes we can still get its events using kubectl get event(including DELETED event). And after a TTL (default is 1hr I think) those events are gone.

I'm glad most of the work in the PR is around tests and not the fix itself. 😄
I was anyway going to extract the test commits to a separate PR (#409).

[gianarb]

well done @gauravgahlot but now that you said how Kubernetes works I will take it as a confirmation that this is a feature we should not implement 👍

[invidian]

IMO Documenting the TTL for Tinkerbell events (whatever it is or whatever is planned) should be sufficient to resolve #396 👍

[gianarb]

Great, I will close this for now, about doc, atm I don't know where to write about it! I have to figure it out