potiuk edited a comment on issue #10523: URL: https://github.com/apache/airflow/issues/10523#issuecomment-683956090
> * donation: the entire `helm/charts` project - this includes each chart there - is already licensed under an Apache License 2.0: https://github.com/helm/charts/blob/master/LICENSE, by The Helm Authors. We've already stated our interest in donating charts(s) sources to distributed repos, with a preference for maintainers of the software a chart is installing. So you're good on that side Licence is fine, this is not about the licence but about the "ownership". So who is the "Licensor". From the Apache 2.0 Licence: > "Licensor" shall mean the copyright owner or entity authorized by > the copyright owner that is granting the License. The donation process is about passing the ownership and it brings in certain responsibilities (including legal ones). We had a similar [discussion with the CWL community](https://lists.apache.org/thread.html/8aab6f537edc929e38a9da15d5fbf30d1dbbc7bbf8c4c8c36e749e0e%40%3Cdev.airflow.apache.org%3E) and we decided not to accept a donation then. Here (since we have our own chart - [donated by Astronomer](https://lists.apache.org/thread.html/r55b09d63a809428c20ca3317801cad5a86ac939478e0dbd8e93f0fee%40%3Cdev.airflow.apache.org%3Ehttps://lists.apache.org/thread.html/r55b09d63a809428c20ca3317801cad5a86ac939478e0dbd8e93f0fee%40%3Cdev.airflow.apache.org%3E)) I personally think it makes very little sense to accept the donation. > * The prometheus-community considered similar questions and decided to make a separate community repo and invite the contributors/maintainers of the stable prometheus charts continue to co-maintain them. Their process required a sponsor and vote - I understand your process is different, but in case this becomes the main sticking point, could that be a potential option for you? I think we have no such process/rules in ASF. We have very clear rules about software owned by the ASF. And I think - again - it makes little sense to support two different charts. > * splicing in the git history: do you mean it doesn't make sense to do so with the current chart in this git repo? If so I agree. The question is do you plan to make versioned packages of that chart available to end-users via a Helm repo? Yes. That is the current plan I believe. @dimberman @schnie? > From experience in a last company, I can tell you end users are already unclear about that. But if so, I agree an easy depreciation notice for the stable chart is for users to use the one you have here. > * when a chart moves helm repos there must always be an upgrade path, but if the initial version in the new location changes only the Readme's install instructions, the upgrade path is usually as simple as adding the new repo and upgrading to the new chart path and version. However if the chart is structured differently, there's usually more burden on the end user for migrating. I believe this is the case -the original chart is very different from the one we plan to release as a community one. It would be fantastic if someone reviews it and provides even a rough way to migrate. Just a starting point, a simple one might be a good idea - then we can point the users to it and ask then to update it. I think it is rather important to give something to the existing helm users, but the question is how to start it. To be constructive - an idea I have for that - we could ask the users of the old chart to help to create it. How about this: when we release our chart, you can make a note about it in the "stable" chart, clear deprecation timeline and we could together ask your users to migrate and provide some migration notes that can later turn into "migration guide" ? This is something we successfully tried before - our community is fantastic and if asked, people will gladly spend their time and help us with it. Having it from the users will be also much more valuable as they will simply do it. Can you help with that @scottrigby ? We can possibly speed up our work on releasing the chart (even not fully tested). I might be able to help after I am back next week @dimberman @schnie - WDYT? > IIRC with Airflow what uses want to migrate are 1. DAGS and maybe 2. Run history? It is not about DAGS/Run history. This is all stored in the DB and this is a matter of exporting/importing the DB (if at all). This should be independent from the chart changes IMHO - and should be case-by-case basis depending on the database used. Likely this might not even need a migration because, besides development setup, the DB should be external from the Kubernetes deployment (the Airflow deployment should be stateless) so in the vast majority of cases it's just a matter of connecting newly deployed Airflow to the existing database. It's more about moving the configuration of the helm chart itself - whether hand-deployed or via terraform or whatever. This might mean different user ids, volumes, sidecars etc. , different values in Chart, different capabilities, potentially some missing features that will need to be added or dropped by the users/replaced with other solutions. > We can also simply say there is no migration path, but still point users here. Alternatively, as mentioned above, the Bitnami team hosts and maintains an Airflow chart, and the depreciation notice from stable could point end users there instead. Do you have a preference? If Bitnami can provide a clear migration path and support for the current 'stable' helm users - I would be all for it, actually. This might be fantastic news for the current 'stable' helm users and great for the community! Then "new" users could focus on the chart from Airflow and "stable" helm users can go to Bitnami. I would be 100% for it. But If their chart is also much different than the previous "stable" one and they could not provide any migration/maintenance, then probably better to follow the "let the users help with building the migration path" approach to the soon-community managed chart that we might release soon. @schnie @dimberman - what are your thoughts about it? ---------------------------------------------------------------- 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]
