Thanks for the feedback! > > # 1 Flink Native vs Standalone integration > Maybe we should make this more clear in the FLIP but we agreed to do the > first version of the operator based on the native integration. > While this clearly does not cover all use-cases and requirements, it seems > this would lead to a much smaller initial effort and a nicer first version. >
I'm also leaning towards the native integration, as long as it reduces the MVP effort. Ultimately the operator will need to also support the standalone mode. I would like to gain more confidence that native integration reduces the effort. While it cuts the effort to handle the TM pod creation, some mapping code from the CR to the native integration client and config needs to be created. As mentioned in the FLIP, native integration requires the Flink job manager to have access to the k8s API to create pods, which in some scenarios may be seen as unfavorable. > > > # Pod Template > > > Is the pod template in CR same with what Flink has already > supported[4]? > > > Then I am afraid not the arbitrary field(e.g. cpu/memory resources) > could > > > take effect. Yes, pod template would look almost identical. There are a few settings that the operator will control (and that may need to be blacklisted), but in general we would not want to place restrictions. I think a mechanism where a pod template is merged from multiple layers would also be interesting to make this more flexible. Cheers, Thomas
