Mailu: Merge Helm chart to this repo, remove Kubernetes manifests

[briantopping]

The Kubernetes manifests and documentation on the site here only stands to confuse users who can't decide whether to use the Helm charts or the raw manifests here. The Helm charts are far more stable than the manifests, so I'd like to propose the following:

• [ ] Merge whatever remaining differences there are in manifests here (such as the /overrides folder for IMAP) to the Helm repo.
• [ ] Merge the Helm repo back to here and remove the Kubernetes manifests
• [ ] Update the documentation to include both direct installation via Helm as well as generating the manifests from Helm for manual application as the current manifests are applied.
• [ ] Generate e2e tests that ensure the Helm charts remain viable without Kubernetes expertise.

The last item is intended as a friendly means to break the build if the Helm charts break. This is not to slow down a release, rather to flag that attention is necessary.

[AndrewSav]

A personal opinion here:

... as well as generating the manifests from Helm for manual application as the current manifests are applied.

This one is very important to me, because in some environments I do not want helm to touch clusters for compliance reasons. On the other hand, generated manifests can be put through usual deployment pipeline.

[sbias]

please don't remove the manifests, not everbody is using helm.

[briantopping]

please don't remove the manifests, not everbody is using helm.

That's fair, maybe the build should use Helm and generate them into the doc as a part of the release.

The goal here is that there is a single source of manifests, not to force people to install Helm.

[micw]

There are already generated yamls in the helm chart repository:
https://github.com/Mailu/helm-charts/tree/gh-pages/yaml/0.0.6/mailu/mailu/templates - could you check if that fit your needs?
I'm currently reworking the documentation to make this "official".

[AndrewSav]

To be honest it's trivial generating the manifests from chars with helm. I also thought that it can be a problem, but in the end as a maintainer you end up with solution that you need to maintain and you time is better spent on one, not two different ways of doing things. Helm allows for customisation (values) that is not possible to provide in manifest. And it's not possible to provide a single manifest that fits all. It is possible to manually edit manifests of course, but helm does the same better.

Downloading and running helm will take about 10 minutes the first time, and then less then a minute each subsequent time once you have it. So I personally find "not everybody is using helm" argument not compelling at all. It is trivial.

[briantopping]

@AndrewSav I was being generous, totally agree with you at this point. The first time I used helm, I really hated the experience. Having to install tiller, figure out all the noise, it didn't make a lot of sense. Helm 3 arrived and it seemed like compatibility hell.

Today I'm completely sold on it. It generates the templates just as you say, can write them to local files or push them through your local kubectl instance and the CLI arguments are normalized to large extent to kubectl syntax. Focusing on the values.yaml file for local differences instead of having to check in a huge collection of yaml files saves a ton of time and allows much more reliable future upgrades, which is my big thing. If your old values.yaml isn't compatible with new containers, it's a lot easier to see that right away than hunt down little changes over time.

[AndrewSav]

@briantopping Cannot agree more. I have resisted suggestions to use helm 2 at my workplace due to the tiller security concern, but thankfully this is no longer a concern in heml 3. I was very happy that helm team made this decision.

[Nebukadneza]

Hi There,

The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.

To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.

In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the :smiley: icon to the top-right).

• 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
• 🎉 if you find it a nice bonus, but no deal-breaker
• 🚀 if you want to work on it yourself!
  We want to keep this voting open for 2 weeks from now, so please help out!

[briantopping]

I'd like to work on this, just short on time as well. It's not hard.

@Nebukadneza Would it be accepted if it was good code? Or are we still unsure whether this is a valid FR?

[AndrewSav]

IMO it's not right to close an issue just because currently no one can work on it. It does not become a non-issue because of that and if you close it some one will come and open a new one. There is no benefit is closing issues without fixing just for the sake of closing.

[briantopping]

@Nebukadneza To my point a couple of days ago, if there's going to be debate about completed features after they are implemented, it's a high risk situation for implementers. I assume these votes are all on FRs that would be accepted if implemented, please confirm.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[briantopping]

So I guess we've moved from a lack of response on valid issues to spending time implement stalebot to close issues. As @AndrewSav said in this comment:

it's not right to close an issue just because currently no one can work on it. It does not become a non-issue because of that and if you close it some one will come and open a new one. There is no benefit is closing issues without fixing just for the sake of closing

So if what you're trying to do is somehow make Mailu _look complete_ because there are no open issues, this will be effective. If you want Mailu to be the best mail server out there, don't be so anxious to close issues that people spent good time thinking through and articulating. It's rude and people will start to look elsewhere for solutions.

/lifecycle frozen

[briantopping]

/lifecycle frozen

[briantopping]

And I see that /lifecycle frozen has been disabled. So it's time to comment here, @Nebukadneza. We've asked you questions and you've avoided answers. Is that how you want to run things?

Best thing is to not make things more difficult with the community than they have to be, yeah? ♥️♥️♥️

[AndrewSav]

@Nebukadneza I would appreciate if we could get some answers with regard to the above please. You asked for feedback, we gave it, could you please keep engaging with us about this.

[Nebukadneza]

Hi there,

sorry for the delay, as stated in #1569 the maintainers of Mailu are extremely short on time currently. We are trying to invest the little we have in such a way that allows us to be more active and collaborative towards community and users in the future.

I'd like to work on this, just short on time as well. It's not hard.

That is great news indeed! These kinds of offers are one of the best possible outcome of the voting round we could have (see the big comment).

To keep this protected from stale, I’m going to label this accordingly. Given how little we can currently invest, we’re looking forward to your contributions!

As for the discussion about the stale bot, I’d like to move them to #1642 to keep this issue on-topic. See you there ^_^

[Nebukadneza]

Please move the offtopic discussion to #1642 to keep this open for on-topic discussion.

[Diman0]

This sounds as a good feature. If a PR is created for this it will most likely be accepted. We do need confirmation on this from any other maintainer who uses kubernetes such as @micw. I do not use kubernetes and will not review the PR for this reason.

@Mailu/contributors can any of you who use kubernetes confirm you agree this is a good feature and will review the PR once it is submitted?

[AndrewSav]

Please move the offtopic discussion to #1642 to keep this open for on-topic discussion.

@Nebukadneza, understood. Would you mind answering the on-topic question though, in particular if a PR for this issues is going to be accepted (if it's a good code)?

This is the third time it's being asked, I understand that in a rush it's easy to miss, but hopefully now, when it's pointed out it could be answered?

Diman0 indicated that a maintainer who uses kubernetes would need to review it, and he himself will not do that. Do you think this time pressure you mentioned above could cause this (proposed) PR to fall to the sideways without a chance?