filter out pod in eviction using pod ownerreference kind

[dbenque]

Fix issue #98

It is now possible to define eviction exclusion based on the pod ownerReference type. This open the door for more control on pods that are controlled by CRD.

example:

        --do-not-evict-pod-controlled-by=StatefulSet
        --do-not-evict-pod-controlled-by=DaemonSet
        --do-not-evict-pod-controlled-by=ExtendedDaemonSet
        --do-not-evict-pod-controlled-by=

This set of flags replace previous flag:

       --evict-daemonset-pods=false
       --evict-statefulset-pods=false
       --evict-unreplicated-pods=false

and adds an exclusion on kind=ExtendedDaemonSet

The default values have been set to match historical behavior.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request head (david.benque/issue98-do-not-evict-pod-controlled-by@df8c0d9). Click here to learn what that means.
The diff coverage is n/a.

[dbenque]

@jacobstr , I cannot get access to the code coverage report. Codecov is complaining that the project is not public (looks like it is... ). Is there any settings you can change so that we can read the report?

Also I am going to add some test to the util.go in the meantime.

[jacobstr]

@dbenque there seem to be no permissions related to view access outside of making in a collaborator - which I can't do unilaterally. Perhaps there's some workaround e.g. setting it up for your fork?

I realize it's not a great story for contributors if you have to guess and and check to pass the CI flow in an MR.

[dbenque]

@jacobstr I don't know if you did something, but now I have access to the report.
It is going to be difficult to add more relevant test.
What is the policy here? are you going to block progress/merge under a given threshold ?

[jacobstr]

Tests look great, mostly wording nits. The one implementation suggestion would be to deprecate the old style instead of removing it for the time being.

[jacobstr]

I've asked folks to preserve these flags in the past. It looks like it could be done here - we've got one in the case of --node-label already.

Given we no longer publish draino:latest, I'm less slightly less concerned about breaking compatibility at the moment.

This does largely make me feel like a changelog, semantic versioning scheme, and deprecation policy for the project would be helpful.

[dbenque]

If we can remove the flags that would help to keep a simple code base.
If you prefer I can reintroduce them, they can exist next to the new flags, but that may confuse the users. If we keep them we may add a deprecation notice.
If ok for you I prefer to remove the old flags.