Appreciate it, Jarek Re your last point
5) Or MAYBE we should simply incorporate cncf.kubernetes provider > entirely in the core of Airlfow? Maybe there should be NO > "cncf.kubernetes" provider? My Answer: This is the point which is the real reason for me being > reluctant here. I see it as quite possible scenario, that we will drop > the provider and all kubernetes code will be simply embedded in > Airlfow Core. I think this is a very interesting and probably least > distruptive scenario. Yes it means that bugfixes will only be > releaseable together with whole Airflow, but K8S is so tightly > connected with Airflow Core via K8S executor that it might be the best > choice. And if we do choose this path, this means that likely the core > settings should simply ... stay in core rather than be moved out. My thought is that even if we went this route (as with any other route), it would be desirable for KPO to have its configuration taken in the normal way (init params or airflow connection) like any other operator, and let the core settings apply just to the executor. But I understand your point about limiting the frequency of breaking releases. And yeah I'd be happy too to hop on a call and try and help figure out a path forward.
