Khaliq opened 11 months ago
|
|||||
@kha7iq thanks for the suggestions, and your contribution is very welcomed. Please keep in mind that OneDev should work out of box for simple situations. For complicated situations, we can support that with extra settings. The documentation for k8s deployment also organizes this way: getting users start quickly, with optional settings for complicated usage scenarios: |
|||||
Khaliq referenced from pull request 11 months ago
|
|||||
OneDev changed state to 'Closed' 10 months ago
|
|||||
State changed as code fixing the issue is committed (a8b1ecb1) |
|||||
Hello everyone. I just wanted to say that I sincerely appreciate the work you are doing on this project and I'm anxious to give it a shot. However, the Helm chart definitely ignores the external database configuration and still spins up MySQL. Are there plans to update the Helm chart to resolve this? Thanks in advance. |
|||||
Hi @danieleagle the helm chart has been reworked completely thanks to @kha7iq . I have merged the work into helm branch and is doing some housekeeping works . The new helm chart will be much flexible and can work with external database without spawning its own mysql. This should be available in the end of this month. And there will be a migration path from current chart to the new chart. |
|||||
Awesome. Glad to hear it. Thanks for everything you do. 😀 |
|||||
OneDev changed state to 'Released' 10 months ago
|
|||||
State changed as build #3841 is successful |
|||||
Hello how are you? Thanks for all the work you are doing, I think it is really excellent and mainly what I was looking for. I am testing the installation in kubernetes of the **helm chart v8.5.6 ** according to the documentation and in the 3rd step
After adding the repo to Helm and updating it, I get the following error
I`m doing something wrong? I deployed OneDev without any issue by defining it in values.yaml
and deploying the service with this new value.
I don't know if it's a chart error or if the documentation should be updated. I'm going to try to continue with the installation activating ingress and TLS to see if I find any other errors. Thank`s again for the work you are doing, it is really excellent. |
|||||
I can not reproduce this. What is your helm version and k8s version? |
|||||
Issue can be reproduced with latest version, one of 2 solutions here.
Either update the docs to include the OR Define the default password in values.yaml file Issue came from these changes : https://code.onedev.io/onedev/server/~commits/17cfef9a9db2eb520219c4c54b961d21e829200a Actual problem is coming from the following line, its looking for a password and when none is defined it errors out.
|
|||||
@robin I leave you the info
|
|||||
I tested with both latest helm version and 3.11.2 and it always works. Strange... |
|||||
I did a fresh install, it has no secrets or values ​​set. it can be that? Tomorrow I will install it again and test if it is throwing the error. |
|||||
Yes, I even created a brand new cluster |
|||||
To reproduce
|
|||||
Still no vail. I guess this has something to do with my started k8s cluster (using GKE). Nevertheless, I removed the password secret to avoid this error when password is not specified. The change is delivered in build #3892 |
Type |
Improvement
|
Priority |
Normal
|
Assignee |
First of all thank you for creating this amazing service, i quite recently come across it and found it to be great.
I've observed various issues with Kubernetes deployment via Helm, and I would say that it requires significant improvements, possibly even a complete rewrite. Specifically in terms of configuratibility for quite a few things, i.e when deploying in production with an existing supported database like MySQL etc, it still deploys MySQL within the cluster.
To address these issues, the following improvements are necessary:
During my testing, I successfully ran the server in Kubernetes using the embedded database without encountering any issues. This is an excellent option for deploying in Kubernetes solely for testing or development purposes.
However, for production deployments, it would be beneficial to have options in the chart to configure an existing database or include an external database chart as a dependency. This would allow you to focus solely on deploying the server without worrying about the other dependencies.
And lastly i am happy to send a PR to fix these issues, let me know if that is something you are interested in