potiuk commented on PR #60074: URL: https://github.com/apache/airflow/pull/60074#issuecomment-3711902451
> (+ follow-up) > I noticed that in a related PR (about edge3 provider), the fallback-based approach was approved. > Given that, would it make sense to proceed with this PR using the same fallback approach for now, and then follow up with > a separate issue/PR to introduce the proper initialization/injection mechanism, after which we could remove those fallbacks > in a single cleanup? I think it was a bit too hasty, and here we will have a lot of fallbacks in a few places if we want to remove it from cncf.kubernetes - I think edge provider had only a few of those, but there are lot more here. And I think that was the main reason why the "default.cfg" was introduced - that it would introduce a LOT of non-DRY duplication across a number of files - the fallbacks would have to be repeated, so puting them together in a single file, was a lot more reasonable and maintainable. I think it's difficult to implement the generic mechanism of this sort without having an implemtnation of it to test it, so I think the best idea is to implement it in this PR - at least to make the tests pass - when they do, we might want to extract the "generic" config part to a separate - prerequisite - part. This is what we often do here - implement a bigger PR so that we know "where we are going and testing it" and then, when succeeding - splitting it up. That seems to be most effective way. So if you are ok with it - and no more comments from others, feel free to proceed this way - this will make this one longer to implement, but then as a follow-up we will apply it to edge as well and see that it's "generic-enough" -- 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]
