I also like the proposal 2. Maybe it could be named with *KubernetesOperatorConfigOptions*, which just looks like all other ConfigOption(e.g. *KubernetesConfigOptions, YarnConfigOptions*) in Flink. The proposal 2 is more natural and easy to use for Flink users.
Best, Yang Gyula Fóra <gyf...@apache.org> 于2022年4月2日周六 02:25写道： > 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 >
