This message was deleted.

Hi Matthias, the service has to be an helm chart. The values is used to populate the values of the corresponding chart, so what you're trying to do is not going to work

Thanks for the prompt reply! Is there a specific reason that the service has to always refer to a helm chart? A use case for a service without it's own helm chart would be that you want to create some kind of "wrapper" for an existing service in your env, e.g. define a different set of secrets.

Epinio services are just a convenient way to deploy helm charts, and have a limited and verified catalog. The values are used to provide values to the charts. By the way I'm not sure I've understood correctly your use case. If you can provide us a practical example we can maybe find an interesting use case to implement/integrate. Keep in mind that actual services are missing the implementation of providing values during the deployment phase, so they're a bit limited at the moment. Maybe this is what you're missing

Thanks. One of the use cases we are looking into is that we are using aws postgresql rds service. We first try to spin up a new db instance with every service create, but we ran into timeout issues, because the setup took to long. We are now connecting to an already running rds service and the service create actually only creates a new database for the developer to work in.

I see! I think that the possibility of providing values during the service provisioning is something that will fix or improve this behaviour. If you are using rds you can have a look at Crossplane. I wrote an article about the integration with Epinio and it's probably perfect for you

thanks!

You could also just use the configuration command to skip provisioning of a service and pass in known values: https://docs.epinio.io/references/commands/cli/configuration/epinio_configuration_create and https://docs.epinio.io/references/commands/cli/configuration/epinio_configuration_bind Since configurations are stored as annotationed secrets, you could preload them in to the cluster as well

thanks. If I'm not wrong there is no way of running some kind of initialization/cleanup tasks with a configuration (e.g. creating a new DB per instance), so what would be nice to have something in between configuration and service.

The service (especially when combined with crossplane) is the right choice for that.

thanks, I'll look into that.

Helm just happens to be the mechanism for defining the initialization/cleanup

The only problem with the services is that at the moment there is not yet an easy way to provide values and customize the deployment (coming soon). You can probably tweak the template to fetch at runtime some values from some configmap probably, but still a bit hacky

FWIW, I think it would feel less hacky with a few examples to start from