Hi all, Based on the feedback I have opened a ticket to start merging the config settings on the operator side: https://issues.apache.org/jira/browse/FLINK-27023
This won't allow dynamic configuration yet but it will simplify the operator configuration as a starting point. As a next step we can consider what config options to make dynamic and whether to rename flinkConfiguration to configuration in the CRD. At this point I feel that the flinkConfiguration name is actually not bad given we also have logConfiguration. Cheers, Gyula On Sat, Apr 2, 2022 at 10:00 AM Nicholas Jiang <nicholasji...@apache.org> wrote: > Thanks Gyula for discussing this topic! I also prefer Proposal 2 which > merges *flinkConfiguration* and *operatorConfiguration* for easily > understanding to end Flink users. IMO, from an end-user perspective, the > *flinkConfiguration* and *operatorConfiguration* are the configuration > related to the Flink deployment or job, that there is no need to > distinguish and let users configure separately. > > Best, > Nicholas Jiang > > On 2022/04/01 18:25:14 Gyula Fóra wrote: > > 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 > > >
