Configmap support?

[openstacker]

Before I put much effort into this, I'd like to get comments if it's reasonable. For our case, at least in testing, I'd like to enable draino with dry-run mode, then I'd like to remove the dry-run when I'm confident the testing, but I don't want to restart draino. Same for other parameters. Does that make sense for you? @negz

[negz]

@openstacker What's the motivation for not wanting to restart Draino? It's mostly stateless, so the only impact a restart would have that I can think of would be resetting the queue of nodes to be drained.

[openstacker]

Because restart is not a favorite action from an ops perspective(maybe not the case in container world), generally admin would like to see the configuration is effected without "hard" restart.

[negz]

restart is not a favorite action from an ops perspective

That's true for many services - for example web servers that may drop requests - but I don't think it's true for Draino. I'm hesitant to introduce the complexity of hot reloading configuration from a ConfigMap unless we can identify how we would be negatively affected by simply restarting Draino in order to load a new configuration.

[openstacker]

Sure, I don't have a strong option to argue, but I think it would be nice if we can keep this one open to collect other's interest. Thanks.

[negz]

Sure - that sound good to me.

[blakebarnett]

I could see a reason for this with these options:

      --max-grace-period=8m0s    Maximum time evicted pods will be given to terminate gracefully.
      --eviction-headroom=30s    Additional time to wait after a pod's termination grace period for it to have been deleted.
      --drain-buffer=10m0s

Since the timers on these would reset, and in a very active cluster that could lead to some bad behavior.