Sure :) lets discuss on slack; I am just about to cleanup some back-log of tasks and happy to talk about it :).
On Mon, Apr 25, 2022 at 2:32 PM Daniel Standish <[email protected]> wrote: > > 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.
