GitHub user potiuk added a comment to the discussion: override simple auth manager for `airflow standalone` to use provided config
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 something you **should** expect to work. Every time someone 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 documentation 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 all 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 something 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 should 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 implementation of all that done by someone (you?) - documenting the intention, usage and tests. That would be my proposall how you should proceed @bennage GitHub link: https://github.com/apache/airflow/discussions/53225#discussioncomment-13737702 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
