potiuk edited a comment on pull request #9647:
URL: https://github.com/apache/airflow/pull/9647#issuecomment-653646797
> On the flip side changes in the Helm Chart should not affect Airflow's CI.
In this case, the default of disabling API should just be a change in Airflow
and should not be a change in the Helm chart version until a new Airflow
version is released.
*Should*. This is a nice idea, but until we are really stable and have all
the details worked out for helm chart and dockerfile there will be hiden
couplings - even beyond that. IMHO this is the same fallacy as with
micro-services hype. With Micro-services in theory you have decoupled services
that can be developed in isolation but in fact a lot of micro-services have
hidden couplings and what you gain with separation, you loose on coordination.
A lot of teams (especially those not huge ones) withdraw from micro-services
approach (I'd say hype) recently, precisely because it is not full-filing the
promises (i.e. for smaller teams costs of coordination are far bigger than
benefits of isolation). It's never 0-1, it's always cost-gain game.
I believe we are still far to small (both code-wise and people-wise) and
the "chart" and "dockerfile" are not big enough on it's own to get enough
isolation gains to cover the separation cost.
> Btw I am not against the Kubernetes way, I will look into the details and
let you'll know on the thread. But as of now I am still on the "separate repo"
side
Please do. I think it's the "eat cake and have it too" case. We can fulfill
all your expectations (separate releases, issues for users in separate repos)
while keeping much lower complexity of the development process.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
