Possible race condition?

[johscheuer]

Currently there is a possible race condition in the way trovilo is implemented (AFAIK):

Imagine the following flow:

1.) trovilo get's started
2.) add a ConfigMap with the expected labels for trovilo
3.) trovilo add ConfigMap (or correctly the content of the ConfigMap) on "disk"
4.) tovilo crashes
5.) Delete ConfigMap from above
6.) trovilo recovers

--> If a ConfigMap is deleted during a crash of trovilo the ConfigMap will never be clean up, correct? Since this line will never be called https://github.com/inovex/trovilo/blob/master/cmd/trovilo/main.go#L104 or to be precisly trovilo never checks the initial state of the targetDir.

[hikhvar]

I think this race condition exists. However does not need a crash to trigger this. I think this timeline will also not delete the configmap:
1.) trovilo get's started
2.) add a ConfigMap with the expected labels for trovilo
3.) trovilo add ConfigMap (or correctly the content of the ConfigMap) on "disk"
4.) tovilo container is stopped for updates/maintainance/whatever
5.) Delete ConfigMap from above
6.) trovilo starts

However to trigger this in a kubernetes context, trovilo have to write the configmaps content to a persistant volume.

Deleting a key from a configmap results in the same behaviour. trovilo will not delete that file. https://github.com/inovex/trovilo/blob/master/configmap/configmap.go#L125

So we have to find a way to sync the "on Disk" state with the state in the kubernetes API.
The following solutions come to my mind:

1. Managing the relation file <--> configmap in a seperate file in the target dir
2. use the predictable filenames as mapping.

Solution 2 does not allow the user to place own files in the target dir. This might be a problem. E.g. if the user want to place some static/default config files in the target dir.