Hi Devs! *Background*: With more and more features and options added to the flink kubernetes operator it would make sense to not expose everything as first class options in the deployment/jobspec (same as we do for flink configuration currently).
Furthermore it would be beneficial if users could control reconciliation specific settings like timeouts, reschedule delays etc on a per deployment basis. *Proposal 1*The more conservative proposal would be to add a new *operatorConfiguration* field to the deployment spec that the operator would use during the controller loop (merged with the default operator config). This makes the operator very extensible with new options and would also allow overrides to the default operator config on a per deployment basis. *Proposal 2*I would actually go one step further and propose that we should merge *flinkConfiguration* and *operatorConfiguration* -as whether something affects the flink job submission/job or the operator behaviour does not really make a difference to the end user. For users the operator is part of flink so having a multiple configuration maps could simply cause confusion. We could simply prefix all operator related configs with `kubernetes.operator` to ensure that we do not accidentally conflict with flink native config options. If we go this route I would even go as far as to naming it simply *configuration* for sake of simplicity. I personally would go with proposal 2 to make this as simple as possible for the users. Please let me know what you think! Gyula
