nextcloud
Maintenance
Hello together, this project is current not well maintained. There is a lack of maintainer, so that we are not able to review and develop like new major releases (see #673 ) or even other setups e.g. S3.
Therefore the question how is willing to review / maintain and could support this project.
Just to be fair, Next cloud itself do not like to maintain it anymore in favour of https://github.com/nextcloud/all-in-one/blob/main/nextcloud-aio-helm-chart/readme.md So we are all volutiners here.
Nextcloud AIO just doesn't work for me / my use case, i hope this repo sees some more love in the future. I sincerely appreciate any efforts from contributors to this repo and i want to see that continue :)
As I prefer how the current nextcloud chart works. I am interested in helping out.
Also running two private instances for my personal data.
Between the two helm charts, this one allows for much more advanced stuff like pointing to kubernetes secrets for passwords, tokens, etc. Which works great with external-secrets.
The quality is also much higher, templates, helpers, structure, etc. I'm left seriously wondering why the AIO version is preferred?
I can help out if needs be. I both use this chart (https://gitlab.com/deepcypher/dc-kc/-/tree/master/charts/nextcloud?ref_type=heads) and develop my own charts https://gitlab.com/GeorgeRaven/raven-helm-charts and my own library chart to stop repeating logic everywhere https://gitlab.com/GeorgeRaven/raven-helm-charts/-/tree/main/charts/corvid?ref_type=heads
This nextcloud helm chart works out a bit differently to my usual, but im up to help where is reasonable, and I can't say I am a PHP aficionado.
Between the two helm charts, this one allows for much more advanced stuff like pointing to kubernetes secrets for passwords, tokens, etc. Which works great with external-secrets.
The quality is also much higher, templates, helpers, structure, etc. I'm left seriously wondering why the AIO version is preferred?
I agree, also found the naming of the files in the AIO a bit odd.
Generally speaking this chart is awesome.
Also see: https://github.com/nextcloud/all-in-one/discussions/6570
Basically: Do not use kubernetes for Nextcloud?!? That seems .. odd to say the extreme least. Seeing as all of Europe is looking for EU alternatives for US options in this space.
And most will want to use Kubernetes to create a homogeneous environment for themselves.
Also see: nextcloud/all-in-one#6570
Basically: Do not use kubernetes for Nextcloud?!? That seems .. odd to say the extreme least. Seeing as all of Europe is looking for EU alternatives for US options in this space.
And most will want to use Kubernetes to create a homogeneous environment for themselves.
Hi, just to make this clear:
You are misunderstandind my comment.
Also, this is my personal view on the topic.
Additionally, you are of course free to use whatever project you want!
Thanks!
@szaimen Could you maybe explain the reasoning behind that comment a little bit more? I cant think of something that makes docker better suited than kubernetes, since you can do basically the same stuff in k8s that you could do with the container or am i missing something really obvious here?
@szaimen Could you maybe explain the reasoning behind that comment a little bit more? I cant think of something that makes docker better suited than kubernetes, since you can do basically the same stuff in k8s that you could do with the container or am i missing something really obvious here?
Lets continue the discussion here: https://github.com/nextcloud/all-in-one/discussions/6570
Also see: nextcloud/all-in-one#6570 Basically: Do not use kubernetes for Nextcloud?!? That seems .. odd to say the extreme least. Seeing as all of Europe is looking for EU alternatives for US options in this space. And most will want to use Kubernetes to create a homogeneous environment for themselves.
Hi, just to make this clear:
You are misunderstandind my comment.
Ah that is quite possible. I was reacting to: The chart was created for users that rely on k8s and cannot switch platforms Thinking you meant: you should switch to docker if you are able to.
Also, this is my personal view on the topic.
Also: check. I was under the impression you are part of Nextcloud as a whole ;-)
The main subject was: how can somebody from Community, become maintaner and/or able to create PR's and approve PRs in order to keep this project moving?
I've been impressed by the quality and flexibility offered by these charts, and I would love to be able to keep using them. I also understand that Nextcloud has commercial incentives to keep a proprietary chart for their paying customers.
Right now the situation strikes me as odd:
- On one hand, this repo and the charts on artifacthub.io are registered under the official nextcloud namespace.
- On another, Nextcloud is not involved in these charts' maintenance and it is unclear how someone can become a co-maintainer. Because nextcloud is several versions behind, it puts these charts' users at risk, and it puts Nextcloud's reputation at risk.
I can think of several ways forward:
- Nextcloud could ask the community to fork this repository and archive it, so it doesn't look like an official, Nextcloud-maintained chart. Potentially upsetting for some, but at least sets expectations for users.
- Nextcloud could try to make this chart and the helm AIO chart converge (in the sense that this chart would remain free, and the helm AIO one would be for paid customers, potentially with extra features, and with paid support). This would make the charts and Nextcloud easy to adopt, and make it easier for Nextcloud to sell paid support for customers who need it (similarly to what Element does with ESS Community / ESS Pro). I believe this approach has the potential to make everyone happier.
- The community and Nextcloud could agree on a governance process, with commitments from Nextcloud to actually promote maintainers who have been nominated.
@szaimen is there someone at Nextcloud in charge of relationships with the community who'd be open to talk about it?
@varet80 thank you to bring us back to the topic. The idea of this Issue is evaluate if we want still maintain this and how like to help. Like @thibaultamartin described the options, I believe we are at the point of the last Options, that it still is maintained here (what I prefer to be as close as possibility to the original project, so that it is easy to find hopefully a well maintained chart) and the Nextcloud seems to be fine to promote persons here to maintainer (like me and @provokateurin was).
It looks like @varac, @DreamingRaven and @thibaultamartin offer helps.
I do not know how to handle a good Community and onboarding. So at first, please speed some time to write me if i am to complex or unfair to new maintainer.
My first thoughts is that you two start to review and maybe test the existing PRs, i am not sure if you have even make a review here. PS: Beside the Problem of have less time to spend here, I have no S3 setup where some PRs need to be tested.
If we like the way we are working, I will make suggestion to the Talk-Channel like @provokateurin . (personal I do not use Talk, so i had to use a guest account therefore - or we switch to something like Matrix).
PS: This are my thought just because I am already a person how make some things here and got merge-permission for PRs created by others. If somebody else like to organise the Maintained I am even more happy.
@wrenix Thank you for the reply. I am definitelly happy to review PRs and also commit. Working with Helm for more than 5 years now, And in other opensource projects too. I run K8s at home and at a DC (using metal) but also running Clustered Minio as my backend to Nextcloud plus Postgres.
I have migrated 2 times from my Home cluster to my DC and back to my home (moved to another place and had to disable the Nextcloud instance).
Therefore I can also review the S3 setup with multiple buckets. I run around 3TB of S3 (minio) storage of personal data and more.
for me this project is really well maintained till now! and follows the best practices of Helm. The AIO in the other hand is not something I would like to switch too.
In worse case I would start my own fork of this and continue from that point.
I can understand that Nextcloud doesn't want to maintain 2 helm charts. I wonder if both could get merged where you could optionally install all AIO components, but you don''t have to. Personally, I don't have the capacity to help maintain a community chart.
Huge kudos to everyone contributing to the development and maintenance of the Nextcloud Helm Chart – your work is incredibly valuable to the community and very much appreciated! 🎉
The effort and attention to detail that goes into keeping the chart up-to-date, reliable, and feature-rich truly deserves recognition. Helm Charts are critical to simplifying deployments, and I am sure this one has helped countless users and organizations run Nextcloud more effectively.
It would also be great to see some movement on assigning new reviewers to [PR #673]. This would really help keep the momentum going and ensure valuable contributions continue to move forward smoothly.
Thanks again to all involved – your dedication makes a real difference! 🙌
I do not see any reactions from Nextcloud. And that worries me Is nextCloud silently killing it? Either way, for the moment. I forked and created a repo which I will maintain on my org. As I see nobody from Nextcloud noticing this repo.
Anybody wants to help keep the helmchart growing, I am happy to assign maintainer (on my own clone).
I already merged there @wrenix 'es awesome changes for v31 and created a helm repo.
Hello everyone
Thank you for your engagement.
We have created the organisation @nextcloud-community for a Gantt view of the Deck app. We are still in the planning phase there. Maybe you are interested in the fork at @nextcloud-community. I am very happy to add maintainers to this project. Please let me know.
I do not see any reactions from Nextcloud. And that worries me Is nextCloud silently killing it?
I was worried about that, but when you look at their webpage it looks like they consider almost every FOSS implementation, including the base docker image, as "community supported." So, officially it seems like we're in the same place as everybody else. I see the main issue right now as there being nobody in charge of this repo. The forks are an obviously solution, though at some point we'll have to pick one (ideally) and start migrating once it seems serious. I'd suggest not making too many breaking changes at first which will help prevent reluctance to migrate for fear of not being able to move back.
From what I saw in other issues, some of the maintainers were frustrated with complaints/etc, which unfortunately one of those things in FOSS you just have to deal with. I would suggest that if a fork happens, and when somebody says that your fork is terrible because you didn't implement support for FOO, then you just reply PRs welcome, and work on FOO if it interests you personally, and ignore them if not. They'll call you names, but ultimately you need to be doing something like this for your own personal benefit (IMO) and those of us who are leeching just gotta deal with it.
I don't see myself going to AIO unless it becomes a bit more k8s friendly, like support for ingress. No way I'm dealing with another SSL port-forward without cert-manager, and my ingress owns port 443 and that's all there is to it.
I do not see any reactions from Nextcloud. And that worries me Is nextCloud silently killing it?
I was worried about that, but when you look at their webpage it looks like they consider almost every FOSS implementation, including the base docker image, as "community supported." So, officially it seems like we're in the same place as everybody else. I see the main issue right now as there being nobody in charge of this repo. The forks are an obviously solution, though at some point we'll have to pick one (ideally) and start migrating once it seems serious. I'd suggest not making too many breaking changes at first which will help prevent reluctance to migrate for fear of not being able to move back.
From what I saw in other issues, some of the maintainers were frustrated with complaints/etc, which unfortunately one of those things in FOSS you just have to deal with. I would suggest that if a fork happens, and when somebody says that your fork is terrible because you didn't implement support for FOO, then you just reply PRs welcome, and work on FOO if it interests you personally, and ignore them if not. They'll call you names, but ultimately you need to be doing something like this for your own personal benefit (IMO) and those of us who are leeching just gotta deal with it.
I don't see myself going to AIO unless it becomes a bit more k8s friendly, like support for ingress. No way I'm dealing with another SSL port-forward without cert-manager, and my ingress owns port 443 and that's all there is to it.
Probably their own way. Sometimes can be challenging to maintain every aspect your audience needs.
Eitherway, I have forked this repo and also merged @wrenix pr for 31.0 version on @k8sonlab.
If anybody is interested to become maintainer, happy to assign.
As active user of Nextcloud with 2 installations, I am really happy with this repo, and I want to keep the experience the same.
I have make some suggestion which got on the weekend maintainer privilegs here, now.
I am personal against of creating more forks and split it even more up in https://github.com/k8sonlab, https://github.com/wrenix/nextcloud-helm/ and https://github.com/nextcloud-community. Lets try to still etablish here an better maintaince (we will have this problem everywhere and i am sorry, that i am current the blocking person. I hope the new maintainer make his job well and we good a better community here, now.
Hello everyone, I wanted to inquire whether there is still a need for maintenance support?
In my opinion, there is still plenty of work to be done, as the project is not up to date. Some changes with breaking changes are unavoidable and would like to see a new v9 branch for this patches. If the project no longer needs anyone, I would create a fork in the next few days and maintain my fork myself.
Points that I currently see as follows:
-
repository does not follow official helm structure
-
inconsistent support for annotations or labels.
-
no reload when secrets or config maps change.
-
defaulfConfigs are only supported if configs contain an attribute.
-
no helm unit tests
-
no configuration examples for ArgoCD
-
restructuring of values.yaml
-
replace Ingress with GatewayAPI
-
missing networkPolicies
-
anubis integration
Volker
Wow that is for me hard to hear, after a weekend with round about ten merged pull request (also one of yours #806 where i habe to write the changes after review because you have not reacted after that review).
Yes i wish we have here more active person and reviewers but also direct to thread with an fork in statt of ask to become a maintainer (and has not done any review here yet, at your own).
Now to your list, please create issues for it.
- repository does not follow official helm structure
- what is your opinion here? What is against this structure? Where is your Issue vor PR?
- inconsistent support for annotations or labels.
- in my opinion it is consistent, so again where is your issue or PR?
- no reload when secrets or config maps change.
- in which value /configmap/secret it does not work, so again where is your issue or PR?
- defaulfConfigs are only supported if configs contain an attribute.
- do you has taken a look into to container file?
- no helm unit tests
- where is your review at #462
- personal: i do mit care oft helm-unit, we have end-to-end test and more important things are todo
- no helm documentation
- where is your review at #633 or #693
- no configuration examples for ArgoCD
- and where is the example PR for FluxCD ?
- personal: ArgoCD is a really bad tool: additional annotation for hook, unable to parse values with null values correct, helm template lookup does not work out of the box, broken and over engineered UI with another unnecessary layer of authentification
- so I believe helm is the minimal document standard here, if you use other tools, you should take a look in there documention
- restructuring of values.yaml
- what is wrong with it, wo where is your issue or PR?
- replace Ingress with GatewayAPI
- retirement of the NGINX ingress-controller dies not mean retirement of the ingress-controller itself. So if your PR is comming for GatewayAPI please do not drop ingress
- missing networkPolicies
- once again, PRs are welcome
-
anubis integration
- in my opinion a WAF should not be part of the application, it should be part of the Ingress-Controller or GatewayAPI: current anubis just support traefik for it ... PR for Documentation is welcome
Hey,
where I have to write the changes after review because you have not reacted after that review
you're absolutely right, and I think it's great that you took care of it. As a rule, I only get around to improving my deployments and contributing to such projects on weekends or very late at night.
Yes, I wish we had more active people and reviewers here, but also direct to thread with a fork instead of asking to become a maintainer (and has not done any review here yet, on your own).
I don't want to threaten with a fork. I'm very happy when volunteers get together to maintain a piece of software like this.
Now to your list, please create issues for it.
Based on your typos, you probably understand German: Wird gemacht Chef ;)