Question about volume controller behavior

[EpicStep]

Hi! I’m trying to understand one design decision in the project.

I noticed that the Volume controller watches Machine resources and, during reconciliation, removes the related claim if the corresponding Machine has been deleted.
What I don’t quite understand is why the Machine itself doesn’t clean up the claim on deletion, and why this responsibility is placed on the Volume controller instead.

Could you please explain the reasoning behind this approach in a bit more detail?

Thanks.

[lukasfrank]

Hello @EpicStep
thanks for showing interest in the IronCore project.

The volume controller (https://github.com/ironcore-dev/ironcore/blob/main/poollet/volumepoollet/controllers/volume_controller.go) only cares about the Volumes and materialized them. Volumes can be created by the user directly or by a Machine in case it's an ephemeral one.

A Machine is the consumer of a Volume and therefore needs to listen to them and other resources until they are ready.

Does that answer your question?

[EpicStep]

What I mean is that in https://github.com/ironcore-dev/ironcore/blob/main/poollet/machinepoollet/controllers/machine_controller_volume.go#L50
I see the Machine controller patching the Volume in order to adopt it.
After that, the Volume controller starts watching this Machine and deletes the claim when the Machine is deleted:
https://github.com/ironcore-dev/ironcore/blob/main/internal/controllers/storage/volume_release_controller.go#L85
My question is: why does the adoption happen in the Machine controller, while the release logic lives in the Volume controller?

[lukasfrank]

Only the Machine knows and can decide which Volume to use. Therefore the machine controller (consumer) adopts the resource. The Volume is the owner of it own state so this controller becomes responsible for protecting and cleaning up the Volume related state.

We follow here the same mental model you find in kubernetes itself eg. with Pods and PVCs.