Subham-KRLX commented on PR #65758: URL: https://github.com/apache/airflow/pull/65758#issuecomment-4486743786
> I will try to provide a little more perspective, which I have by adding comments to particular parts. > > > the hardcoded "repo" directory breaks existing DAG setups when migrating to the Helm chart teams have to restructure their entire DAG paths just because of this hardcoded name I know git sync is being deprecated but users need this working now It's just one config option that defaults to current behavior. > > I would say, in this case, the PR is not resolving the issue as, natively, all of the Dags code is directly under the `$AIRFLOW_HOME/dags` directory. Making a change so that we can change the `repo`, and not remove it completly, can make the situation a little easier, but it does not resolve the possible compatibility issue between different Airflow platform deployments. > > The issue with migration between one setup to another, with a static `repo` path, can be that, with some scale and multiple different teams across the organisation writing Dags, it can be really time-consuming to change the Dags code itself without some mature governance over them (which can be hard with a distributed platform model). I suppose that teams which want to move forward with platform maturization could benefit from making the platform switch first from more dev env (docker compose I suppose) to more prod env (kubernetes), and after that focus on Dags code itself then making it the other way around (it is really a short description of what I have in my mind, but I think that it is enough to give some context and perspective). > > > Thank you for reviewing my request. The point is that only one additional, longer path is being created for the DAGs, and this path is not actually necessary and can be removed. Although Git Sync is planned to be removed, it is simply an option > > We can't be sure if nobody is relying on the current version. This is why we need backward compatibility within the minor/bug-fix releases. > > > I see the problem is mainly with migrations. While migrating, these can happen. People can update references as Jens suggested. > > It is really a question about the scale. It can be a 10-minute change, or it can be not really feasible to do within a reasonable timebox. > > > Maybe we should better document the migration path rather than trying to add more code > > I agree that adding some documentation on how to migrate from one to the other would be good, but I don't see it as a solution to the issue. Thanks for the support and the great point about migration scale. That is exactly why this change is needed to avoid refactoring references across many teams. -- 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]
