Actually I thought about it - just do it Daniel. I think it makes no sense to hold it now. It might take quite a long time to resolve the K8S <> Core dependency and might even lead to breaking changes so even if we do it wrong now, we might simply redo it later.
I have no reservations. J, On Tue, Apr 26, 2022 at 12:55 AM Jarek Potiuk <[email protected]> wrote: > 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. >
