[bugfix]: clean OCI leftovers before the wasp-agent pod is removed

[enp0s3]

Signed-off-by: Igor Bezukh ibezukh@redhat.com

two OCI files are being copied by wasp-agent into the host:
hook configuration and hook script. These files remain on the
filesystem even after wasp-agent is being removed from the node.
This causes redundant execution of the OCI hook.

these changes suggest removing the files before the pod terminates.
The preStop hook is being called before SIGTERM is being sent to the pod.

In case of forcefull deletion the hook will be skipped

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign enp0s3 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[enp0s3]

Addresses #91

[Barakmor1]

Thank you!

[akalenyu]

just few alternative to consider:

• emptydir (tied to pod lifecycle) stop using predicted paths on the host, let cri-o somehow know where it should look
• signal handlers in the go program (roughly equivalent to current suggestion, arguably missing those in general for faster teardown)

[enp0s3]

just few alternative to consider:

• emptydir (tied to pod lifecycle) stop using predicted paths on the host, let cri-o somehow know where it should look
• signal handlers in the go program (roughly equivalent to current suggestion, arguably missing those in general for faster teardown)

@akalenyu Thanks for the feedback!

I was considering using signal handlers, but then realized that I can offload it to k8s, so less code to maintain. Also it seems like in the SIGKILL case both of them are useless :(
Regarding the path I can actually improve the CRI-O configuration parser, then we will only rely on their project defaults.

[akalenyu]

just few alternative to consider:

• emptydir (tied to pod lifecycle) stop using predicted paths on the host, let cri-o somehow know where it should look
• signal handlers in the go program (roughly equivalent to current suggestion, arguably missing those in general for faster teardown)

@akalenyu Thanks for the feedback!

I was considering using signal handlers, but then realized that I can offload it to k8s, so less code to maintain. Also it seems like in the SIGKILL case both of them are useless :( Regarding the path I can actually improve the CRI-O configuration parser, then we will only rely on their project defaults.

sounds good