potiuk commented on issue #10523: URL: https://github.com/apache/airflow/issues/10523#issuecomment-687166003
> @potiuk, can you confirm if you plan to have the official helm chart releases tagged to airflow releases? Not exactly. We will use the same "repo" to release the helm chart but we can (and most likely will) release them with completely different cadence and separate tag scheme. During our CI process, we will make sure that the same helm chart will work with different versions of Airflow PR in progress for that is here: #9663. We discussed it in detail in the [Separate Repo vs MonoRepo for Dockerfile & Helm Chart](https://lists.apache.org/thread.html/r0a2c68b07775f2401a397ebdc5826ec89a51a4ea4acfadd96e4b7d46%40%3Cdev.airflow.apache.org%3E) discussion and I think together with @dimberman and other committers we reached the conclusion that in our testing and development process keeping monorepo is the way to go. And - as discussed there - where the chart is developed has nothing to do wiht the cadence of releasing it. For sure the conclusion is that we do not want to keep a separate repo for helm chart. Even if many projects are doing it, I think this is not necessarily the best way of doing it for us, and we are trying to work-out the best process for that also on the ASF level. My proposal in the discussion started in ASF > Almost every other project I am aware of has their helm chart releases completely independent of the app itself, and stored in a seperate repo. (Otherwise it would be impossible to push a critical fix for some helm specific issue without an app release) That is not necessarily correct (the "Otherwise" statement). We already release different packages (Backport packages) on a completely different cadence - from master. You can see it here: https://downloads.apache.org/airflow/ - as you will see there "Airflow" is released with "1.10.12" version and backport packages are released with different versioning scheme (CALVER based) - the last release is "2020.6.24". I am just going to release new set of backport packages (in a few days) and it is completely independent from the Airflow releases. They even use different branches (backports are released from `master` where Airflow is released from `v1-10-stable`. The release process produces different packages (both sources and binaries). We have to follow the same process when we release the helm chart of ours. The package we are going to release will likely contain only helm chart sources packages in src.tar.gz that will need to be signed, checksummed, and voted on as required by the [ASF Release Policy](http://www.apache.org/legal/release-policy.html). And we will likely do it from master rather than from 1.10 branch. Just to comment (again) - for Apache projects, those are the only official releases we can have and the only ones that we can advertise to our users. As a PMC member I am (together with others) legally responsible for doing it this way and ASF indemnifies me and other PMC members for any legal consequences but only if we are following the ASF policies. There is no way around it, really - we cannot violate those policies. > Therefore, I think the [discussion about apache/charts ](https://lists.apache.org/thread.html/rcb608739206d788785081073a0deb417ffa9981634975fc5525dc769%40%3Cdev.community.apache.org%3E) is important, because I expect we will have to move the offical chart out of this repo before we can properly release it. I agree it is important (and I already explained the currrent state of Airflow Chart and took part in the discussion by proposing how it could look like and I even offered a lot of my own time to make it happen in a consistent way for all ASF projects (I think it is super important to have good policies and mechanism for all ASF projects to release their charts). But I totally disagree with "we will have to move the official chart out". There is nothing in this discussion that tells about moving where the charts are **developed**. The discussion is only how the charts are going to be **released** for use by the users. Those two things might be (and will likely be in my opninion) two different things if we want to follow the ASF rules. Similarly as the "airflow" source is developed in GitHub and released via Apache SVN. In fact a proposal (not ny me - by Bertrand, another ASF member) is that we use the current SVN infrastructure (available via downloads.apache.org) to also expose the officially released helm charts. I very strongly agree with it. As long as we make the chart sources exposed by the webserver in the way that helm expects (including metadata) that sounds like the best solution. We'd only keep the "snapshots" there (we can do it automatically from the tags in GitHub) and users will only have acceess to the "officially released and voted"). We can even use existing mirroring infrastructure of the ASF to make it available to everone all over the world with unlimited scalability. > If we did move to an apache/charts style repo, then we could easily have both the old stable/airflow and the new one in from this repo until they reach feature parity, after which we would drop support for stable/airflow, and help users with a migration guide. (This is important, because stable/airflow will have to go somewhere before the November deadline, as it is widely used, and there is not currently an alternative) If you think the discussion in ASF ends by November., then I think you do not realise how the ASF work. The discussion just started yesterday - it will take at least several weeks until everyone interested will have an opportunity to state their opinion, argue etc. then we will have to make a consistent proposal, then we will have to vote on it, and then it will take weeks by the ASF infrastructure to implement what's needed. This is a marathon, not a sprint and the discussion is not aimed to solve "current" problems but provide a long-term sustainable solution that will satisfy the needs of potentially 300+ ASF projects. Those decisions need time to discuss, weigh pros and cons and do very conscious and deliberate decision. If we have such a Chart repo by the end of the year, I would say this will be record-breaking speed. And BTW. We might *NEVER* reach the parity of the current "helm/stable" chart. As a community we might simply decide that our chart is going to be simpler, and will not handle all the cases you implemented. All that at the expense of easier maintainability and handling say 90% of the cases, your chart handles. This has not yet been decided and discussed - and again - we are here for the marathon, not the sprint - we do not have to release the chart quickky and we will likely only release it around the 2.0 release timeline (which is by the enf of the year). We might even decide that we wait with the release until the ASF-wide solution is in place since the discussion started (that actually would be my vote now). So, since as @scottrigby proposed and negotiated - going the "Bitnami route" for the current "stable" helm chart is the best course of action IMHO. As a member of the Airflow community, I have completely no problem if someone else maintains the chart of Airflow (as long as it is done well and it helps Airflow to grow - this is fantastic for the community). And since Bitnami already agreed to do it, I think you should focus your efforts on making sure this is happenning I think. Just to reiterate that - for us, the Helm Chart is not the main focus. This is a bit of an aftertthought. Airflow Sources are the main "product" the community works on. It is important to have it at some point in time, but I think it is more important to have it released properly, according to ASF rules, tested well, including integration testing and long-term maintainable by the community - rather than to have it fast. Especially that there is no the grreat route proposed by @scottrigby where Bitnami takes your chart over (which I am very happy about). ---------------------------------------------------------------- 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: [email protected]
