Hello All,
We have a speck installation on Azure Kubernetes and have tried to set up the email notification service unfortunately it doesn’t appear to be working. I’m getting the error in the server pod
{“level”:“warn”,“time”:“2023-06-13T07:49:14.212Z”,“msg”:“No email transport present. Cannot send emails.”}
The values.yaml email configuration is shown below. We are using sendgrid and the password credentials are setup in the server variables.
Also redis is external to kubernetes.
The one thing that is missing from the values.yaml which I would have expected is the from email address however it was not in the template provided.
I’m wondering what can I do to investigate this further and also where I’m going wrong? Thank you for your time
email:
## @param server.email.enabled If enabled, Speckle can send email to users - for example, email verification for account registration.
##
enabled: true
## @param server.email.host The domain name or IP address of the server hosting the email service.
##
host: 'smtp.sendgrid.net'
## @param server.email.port The port on the server for the email service.
##
port: '465'
## @param server.email.username The username with which Speckle will authenticate with the email service.
## Note that the `email_password` is expected to be provided in the Kubernetes Secret with the name provided in the `secretName` parameter.
##
username: 'apikey'
password:
## @param server.email.password.secretName The name of the Kubernetes Secret containing the email password. This is expected to be provided within the Kubernetes cluster as an opaque Kubernetes Secret. Ref: https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
##
secretName: 'server-vars'
## @param server.email.password.secretKey The key within the Kubernetes Secret holding the email password as its value.
##
secretKey: 'email_password'
## @extra server.email.networkPolicy If networkPolicy is enabled for Speckle server, this provides the Network Policy with the necessary details to allow egress connections to the email server
##
networkPolicy:
## @extra server.email.networkPolicy.externalToCluster Only required if the Redis store is not hosted within the Kubernetes cluster in which Speckle will be deployed.
##
externalToCluster:
## @param server.email.networkPolicy.externalToCluster.enabled If enabled, indicates that the email server is hosted externally to the Kubernetes cluster
## Only one of externalToCluster or inCluster should be enabled. If both are enabled then inCluster takes precedence and is the only one deployed
##
enabled: true
## @extra server.email.networkPolicy.inCluster is only required if the email server is hosted within the Kubernetes cluster in which Speckle will be deployed.
##
inCluster:
## @param server.email.networkPolicy.inCluster.enabled If enabled, indicates that the email server is hosted withing the same Kubernetes cluster in which Speckle will be deployed
## Only one of externalToCluster or inCluster should be enabled. If both are enabled then inCluster takes precedence and is the only set of egress network policy rules deployed.
##
enabled: false
kubernetes:
As for debugging the email, I’ve a few suggestions:
Have you confirmed that your credentials and account with SendGrid are working? Perhaps by following SendGrid’s tutorial from your local machine? This may identify account or misconfiguration errors.
If that works, try doing the same but from a pod (such as busybox) running from within your cluster. This may identify firewall or other networking issues.
If that works, try outputting the configuration of the running speckle-server pod e.g. kubectl get pod speckle-server-my-pod-id --namespace my-namespace -o yaml, and inspecting to see if the Environment Variables assigned to the pod are as expected. This may identify misconfiguration of the helm values, or a bug in the helm chart.
To inspect the secret, you can exec into the running pod and run the env command, which should list all the available environment variables including the secret. This may identify misconfiguration of the secret.
What is the value of server.networkPolicy.enabled in your helm values file? If it is enabled, could you try disabling and see if you get a similar result? This may identify a bug in the helm chart, or a misconfiguration of the network policy.
If everything appears ok, and you’ve been able to follow SendGrid’s tutorial from a pod within the cluster - you can try running the server at debug log level (server.logLevel in your values.yaml file should be set to debug) to see if there is more output which may help diagnose this issue.
Hi @iainsproat thank you for the detailed steps. I followed the sendgrid tutorial and authentication and sending email worked perfectly. The k8s secret holding the encoded pw match. If I didn’t use a from email address field this would error. What would have been the assumption from speckle without this? The server.networkPolicy.enabled is set to false. I will set the loglevel to debug and see if anything else appears that will help
My hypothesis as to the cause is that because you are unable to configure the FROM email address in the Helm Chart, speckle server defaults to sending the email FROM no-reply@speckle.systems.
As no-reply@speckle.systems is not a verified sender identity for your SendGrid account (and shouldn’t be!), SendGrid correctly refuses to send the email. This, I believe, results in the error we see in Speckle Server.
If my hypothesis is correct, the change I made yesterday to allow the FROM email address to be configured via the Helm Chart should allow you to solve this. You can deploy this Helm Chart by using version 2.14.8-alpha.39345 or later. If you would rather not using an alpha version of Speckle Server, you will have to wait until we release the next version (either 2.14.8 or 2.15.0) at some point in the near future.
Once you have the updated Helm Chart, you should be able to configure the server.email.from field in your Helm Chart values file. This should be set to an email address that is registered with your SendGrid account as a Sender Identity.
You probably would want to wait until we release a new stable version rather than use the (potentially unstable) alpha version. In the meantime you will have to disable emails to avoid the error.
the debug log output below