Replace the use of `viper.BindPFlags` with variables binding about tetragon

[mtardy]

@mtardy

I apologize for leaving the issue unattended for so long. While revisiting this issue recently, I noticed that the code has changed quite a bit since the issue was first published. So I think it's worth checking to see if the issue is still valid.

no worries, yep the option/flags part changed quite a lot recently. I would say it still applies but it's up to you, you can pick up something else and we can close this one. This thing has been causing issues in the past but it's not technically broken at the moment, it's mostly preventive.

[Jack-R-lantern]

Can I be assigned this issue?

[Jack-R-lantern]

@mtardy
For cmd/tetra, I think the change to viper.BindPFlags is valid.
However, in cmd/tetragon, the operator is calling viper.MergeConfigMap via pkg/option's Read*Config function.
Therefore, in both cases, we believe the use of viper.BindPFlags is appropriate.
What are your thoughts on this?

[mtardy]

@mtardy For cmd/tetra, I think the change to viper.BindPFlags is valid. However, in cmd/tetragon, the operator is calling viper.MergeConfigMap via pkg/option's Read*Config function. Therefore, in both cases, we believe the use of viper.BindPFlags is appropriate. What are your thoughts on this?

let's worry only about tetra because tetragon is less subject having multiple flags colliding since it has only one command. I think your PR is great for tetra :)

[Jack-R-lantern]

@mtardy

I apologize for leaving the issue unattended for so long.
While revisiting this issue recently, I noticed that the code has changed quite a bit since the issue was first published.
So I think it's worth checking to see if the issue is still valid.