potiuk commented on issue #53181: URL: https://github.com/apache/airflow/issues/53181#issuecomment-3064914036
Actually. I think maybe that's the right thing to start discussion on the devlist @bennage. I think this is more of e community decision what "standalone" airflow is targetted for. So far, standalone airflow was really used to have "first time user experience" in a an easy way - https://airflow.apache.org/docs/apache-airflow/stable/start.html -> this is the primary (and only) use case for now. However we already had discussions about it - whether we should consider "standalone" to be something more than that. Example here: https://lists.apache.org/thread/cc7wfz9w8d1npopj72nlxnh52dpzbls9 We did not get to final conclusions there, what was really result of that discussion is that we got rid of Sequential Executor in Airflow 3. But.. Maybe it's time to revisit it and discuss what we want to do with `standalone`. Note that for you @bennage you are raising a problem that it "should" work like it worked in Airflow 2, but this was not really an intended use that you **should** rely on and not somethign you **should** expect to work. Every time somene makes such a claim, they add more maintenance / maintainers work - because effectively what we need to do is to not only "fix" the problem (even if this is not a fix - it's just something you relied on implicitly without any promises from our side), but also we would need to document the behaviour you "assume" is intended, make it works in the future - and in order to do that - add test harness that prevents us from breaking it in the future. And actually what we usually do in such case we don't do it just "like that" - ideally we ask the person who has incentive to use the "feature" - to actually turn it into the feature (so in this case we will ask you to make all the necessary changes - document the intention, explain how it works in documenta tion so that people like you would know they can rely on it, fix it, and also add test harness so that it won't get broken in the future. But this - we do only after we agree in the community that we want to do it , and that we want to serve that use case and that we want to maintain it in the future. Which - given the intended usage of standalone - is not at all certain. My suggestion is then @bennage that you start a discussion in the devlist and explain how you can imagine turning standalone into somethign else that it currently is - in the way that it will make it generic enough for others to use it (and you to use it for your case). Ideally, that shoudl be a complete use case - with actors (who is using standalone, goals - what they want to achieve - and proposal of changes - for example adding new flags to standalone or changing the behaviour. Eventually - if the community agreess (either by lazy consensus or vote), there should be an implemtation of all that - documenting the intention, usage and tests. That would be my proposall how you should proceed @bennage -- 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]
