potiuk commented on PR #22253: URL: https://github.com/apache/airflow/pull/22253#issuecomment-1108432770
> @potiuk what you are talking about is code sharing, provider depending on code in core, having deps intermixed with core deps. but just because the operator depends on core doesn't mean that it has to take it's configuration in a non-standard way, in a way that no other operator does, namely from `airflow.cfg`. KPO can depend on core _code_ without taking its _configuration_ from core settings. Indeed every provider depends on core -- that's why we have "min airflow version". But what's different with KPO is that it doesn't use a hook, and my goal is to fix that, and have it be configured like every other operator -- with a connection or params. Yeah. I know that aligning it to be "same as others" is a good goal as long as we know that it is going to be a separate provider in the future. To be honest I do not know - see continuation in https://lists.apache.org/thread/m40ljkgcqsnvbxz6vlgnwflygvr6vznz One of the possible paths for cncf.kubernetes after seeing how disruptive any changes might be and how unforeseen compatibility issues with cncf.kubernetes provider are is to incorporate it BACK into the core. I (and I think we all) have not enough discussion and exploration to understand if this is a possibe or better path - but I think we should take a look at this and make deliberate decision on the future of it before we attempt to make any changes in the settings, because we actually might end up with getting it incorporated into the core if we will not decouple K8S Executor from the core. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
