READ BEFORE POST
If you have an application issue, please take a look here first:
Step by step, diagnose your application issues
yes I followed the step by step guide
Relevant information to this issue:
- OS: Linux
- databases: Postgres/TimeScale
- Programming language and version:
- Link to your project on Github/Gitlab:
- Link to your application - starting with Qovery
Though the applications log shows the container/Application starting as it should we keep getting a deployment error with no description other than the following:
Helm release application-z53239df9-z53239df9
during helm UPGRADE has been rollbacked
HOW TO REPRODUCE
Attempt Redeploying an app/container that was already built
I also noticed that this Dev Cluster is still running k8s/eks 1.21. Not sure if that is an issue or not but wanted to add that as context
Some Additional Information:
With in the same project I redeployed this application as a new project and it worked as expected.
The App with the “deployment error” is actually working and connected able at least over internal DNS. The Qovery internal DNS doesn’t seem to work but k8s DNS works as expected.
QOVERY_APPLICATION_Z53239DF9_HOST_INTERNAL is not resolvable from within the environment. However, the value of that environment variable is app-z53239df9.
I’m investigating your issue.
Concerning the k8s version, the 1.21 is still the current version that we’re using. You can check this post to follow the planning of the 1.22 migration: [IMPORTANT] Kubernetes Upgrade - moving to 1.22
The deployment was failing because of a resize on your application storage (from 4Gb to 50Gb). We allow this resize through the console, but it is not supported yet when deploying => we will prevent the resize from the console.
I changed your storage at the creation state to succeed the deployment: 4Gb. For the moment, If you want to increase the disk size of an application, you have to delete then re-create your application.
Sorry for the inconvenience,
Circling back to make sure I understand.
In the UI/Console you can resize attached storage which makes sense because applications may need more storage over time.
However, when you trigger a re/new deployment of that application it fails due to a mismatch between creation state for the disk volume. (Given its all terraform under the hood that all makes sense.
Assuming all of that is correct here is where I think the problem is:
For the moment, If you want to increase the disk size of an application, you have to delete then re-create your application.
Not all applications fit this example, things like elastic search does, in our case we are using TimeScale. In those examples the application is not stateless they are more like a containerized database. They are going to consume more volume over time and thus need more disk space.
Are we able to resize using the Qovery Terraform provider at all?
Actually this issue comes from the way we start the service in Kubernetes: we are using a StatefulSet which doesn’t allow to resize the storage.
We will work on this improvement to deliver it in the following weeks.
I will keep you updated as soon as we have done it.