o-nikolas commented on issue #28276: URL: https://github.com/apache/airflow/issues/28276#issuecomment-1371553409
> I think if we split is_local flag to those three values, we should be able to determine the right set of properties that each executor should have. Hey @potiuk thanks for weighing in! The original thread/discussion here was actually more around what to do about executors which do not implement the BaseExecutor class (either the composite executors we have or external 3rd party ones folks may have written), which causes issues because the base executor provides all the defaults for the new flags we're adding and if an executor does not implement the base class it will fail to run with the core Airflow code since that code expects all executors to know about all these new compatibility flags. [This comment](https://github.com/apache/airflow/issues/28276#issuecomment-1344899475) summarizes that issue pretty well and I think @pierrejeambrun and I are fairly comfortable with going with option one. But as for your suggestion for more granular executor compatibility flags/properties I think this is a super interesting discussion! I originally made the flags to be as general as possible but still be compatible with the current core code behaviours ("current' as it was before the AIP-51 project), since I expected people to balk at the idea of having tens of these properties. But if you and others are in support of it, I'm actually more than happy to go with more granular flags. It will decrease the likelihood of future changes to the API. I'll cut a new ticket to break apart `is_local` into multiple individual flags and add it to the project board :+1: -- 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]
