Hello all. Creating a new thread per <@UNR3C6Y4T>'...
# ask-the-community
p
Hello all. Creating a new thread per @Yee's suggestion since the old one was getting a bit long: https://flyte-org.slack.com/archives/CP2HDHKE1/p1692713851511769 Having some trouble building a helm chart for flyte-binary for SNS notifications: This format does indeed at least attempt to access your queue and topic for `flyte-binary`:
Copy code
configuration:
  inline:
    notifications:
      type: "aws"
      region: "us-east-1"
      publisher:
        topicName: "arn:aws:sns:us-east-1:#########:some-name"
      processor:
        queueName: "some-name"
        accountId: "#########"
      emailer:
        sender: "<mailto:email@address.com|email@address.com>"
        subject: "hi this is the email subject"
        body: "hi this is the email body"
Unfortunately if we switch to the more complex syntax (with `{{ workflow }}`or any of the other template literal variables) (as seen in the docs: https://docs.flyte.org/en/latest/deployment/configuration/notifications.html#config), we still see
function "workflow" not defined
errors (
parse error at (flyte-binary/templates/deployment.yaml:4): function "workflow" not defined
).
y
oh this thing
where is the error coming from?
this is a
helm template
command right?
p
We’re using helmfile but yeah it’s essentially equivalent, when we run helmfile sync or helmfile apply we see this error
y
i think this is just escaping the braces correctly right?
try doubling them up?
p
Awesome, this worked! Posting this so it can help others:
Copy code
emailer:
  sender: "<mailto:email@address.com|email@address.com>"
  subject: 'Notice: Execution "{{ "{{" }} workflow.name {{ "}}" }}" has {{ "{{" }} phase {{ "}}" }} in "{{ "{{" }} domain {{ "}}" }}".'
  body: >
    Execution "{{ "{{" }} workflow.name {{ "}}" }} [{{ "{{" }} name {{ "}}" }}]" has {{ "{{" }} phase {{ "}}" }} in "{{ "{{" }} domain {{ "}}" }}". View details at
    <a href=<http://localhost:8088/console/projects/{{> "{{" }} project {{ "}}" }}/domains/{{ "{{" }} domain {{ "}}" }}/executions/{{ "{{" }} name {{ "}}" }}>
    <http://localhost:8088/console/projects/{{> "{{" }} project {{ "}}" }}/domains/{{ "{{" }} domain {{ "}}" }}/executions/{{ "{{" }} name {{ "}}" }}</a>. {{ "{{" }} error {{ "}}" }}
(They're still arriving base64 encoded and not with the right subject but if I put everything in the body and set up some decoding this will be good enough for now!)
y
please follow up if you ever figure out the b64 stuff. i am super confused esp given the debugging output we saw
p
I certainly will. I still don’t understand why test messages aren’t coming in base64 encoded but the ones from Flyte do, tentatively hopeful that a simple Lambda function can decode it before passing it along
@Yee Do you know if typical AWS usage includes simply setting up SES, SQS and SNS, with just a regular Email (not Email-JSON) to send to a specified address? Or are users using Lambda functions to decode from Base64 and the Lambda function itself sends the email? The docs (https://docs.flyte.org/projects/cookbook/en/latest/auto_examples/productionizing/lp_notifications.html#for-aws) seem to intone that a Lambda function should not be necessary, correct?
y
not really sure what you mean by lambda functions.
that was never part of the email cycle
as far as i know
p
Gotcha, that's what I thought but just wanted to confirm. (You can use Lambda to run code snippets when events occur like an email entering a queue for example.) Glad my assumption there was correct.
Any idea why the webhooks PR was closed? I’m still only getting base64 over here, was tentatively looking forward to using webhooks instead: https://github.com/flyteorg/flyte/pull/4147
y
@Eduardo Apolinario (eapolinario) or @Kevin Su any ideas?
i’m not sure. but feels like a pretty hefty pr, will need a fair amount of testing on our part before we feel comfortable shipping it.