Cannot set rasaXToken, rasaToken and JWT_SECRET from custom secret

[nyejon]

Hi,

The helm chart doesn't seem to allow setting custom secrets for these values outside of the values file like the Rasa X Helm chart allows.

It would also help to have the naming between the different charts aligned, as it is very confusing dealing with multiple names referring to the same thing, across the charts.

Thanks,
Jonathan

[sara-tagger]

Thanks for the issue, @kedz will get back to you about it soon!

You may find help in the docs and the forum, too 🤗

[nyejon]

This could be updated to allow referencing a custom secret provider:
https://github.com/RasaHQ/helm-charts/blob/main/charts/rasa/templates/_containers-env.yaml

[nyejon]

See https://github.com/RasaHQ/rasa-x-helm/blob/68b36820918c26074fe662491150e821baf64d20/charts/rasa-x/templates/rasa-deployments.yaml#L115 for an example.

[nyejon]

https://github.com/RasaHQ/helm-charts/blob/main/examples/rasa/README.md this example doesn't work because of the broken secrets.

This chart requires so many hacks and poor practices to get working.

Come on Rasa, all we want to do is put the best chatbot software into use.
These poor-quality charts make this process much harder than it needs to be and sour the great user experience generated by the chatbot development.

[nyejon]

You can avoid this by adding the following envs to your pods manually:

extraEnv:
      - name: "RASA_MODEL_SERVER"
        value: MODEL_SERVER_URL
      # See: https://github.com/RasaHQ/helm-charts/issues/71 for the tokens being made available with custom secret
      - name: RASA_X_TOKEN
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: "rasaXToken"
      - name: RASA_TOKEN
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: "rasaToken"
      - name: JWT_SECRET
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: "jwtSecret"
      - name: "DB_PASSWORD"
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: RASAX_POSTGRES_PASSWORD
      - name: "DB_DATABASE"
        value: "rasa"
      - name: "REDIS_PASSWORD"
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: "REDIS_PASSWORD"
      - name: "RABBITMQ_QUEUE"
        value: rasa_production_events
      - name: "RABBITMQ_PASSWORD"
        valueFrom:
          secretKeyRef:
            name: rasa-secret
            key: rabbitmq-password
      # This needs to be added here because of this issue: https://github.com/RasaHQ/helm-charts/issues/76
      - name: “RASA_DUCKLING_HTTP_URL”
        value: “http://rasa-x-duckling.mal-development:8000”

It still results in double the ENV's being created for some of them, one of the values being UNSET, but for now it seems to work.

[RASADSA]

Hello @nyejon
due to current restructuring internally - all development on the RASA helm charts are on hold.
( and yes paying customers is a different scenario )

We will come back to this ticket when we will refactor the RASA helmcharts.

some advice i gave your colleague

This chart requires so many hacks and poor practices to get working.

Come on Rasa, all we want to do is put the best chatbot software into use.
These poor-quality charts make this process much harder than it needs to be and sour the great user experience generated by the chatbot development.

this kind of comments are neither fruitful or helping - offensive is more like it.
please try to watch your ground tone in the future - thanks !

perfect moment to mention We accept PR's and always did - interesting
https://github.com/RasaHQ/helm-charts#how-to-contribute

[nyejon]

Hi @RASADSA

I didn't mean to come off offensive, I'm sorry if it came across that way.

It was just disappointing to see such a well build product, with an amazing developer experience, have quite a weakness.
This should not be seen as offensive, but what can be improved upon to make the product better.
It's all well that we can build a great assistant, but we need to be able to deploy their assistants to get people to use them.

If we have this problem, you can be sure others do. Some will just go elsewhere and accept a better support experience at the cost of a worse bot.

The numerous issues, my colleague and myself opened, came through literal weeks of testing and debugging to get this working. Some of the issues require quite a refactor (as you suggested would be done after the hold).

If Rasa wants to be a product that is "open source", but paid to be made "usable" then that's fine, but it should just be stated upfront.

To me the value for paid customers should be added by additional features, and not be forced to be paid due to the things not working easily. I would imagine that many companies are just like us, and would like to evaluate the product in a "production" setting before committing to something to assist with the management and operation of a bot over time.

Anyway, this issue is not the place to discuss this.

[RASADSA]

hello @nyejon

the Opensource sector lifed in the last 20+ years of the contributions of the community.

https://daniel.haxx.se/blog/2022/01/17/enforcing-the-pyramid-of-open-source/

in the recent years it has changed since a lot of companies abuse open source in the way that the want features / open bugs for their specific scenarios or edge cases with no transaction in any way back (contribution/support of the OSS devs/money take your pick)
and to be fair - Opensource means that everybody can read the code and work a way around it based on the informations gather out of the opensource code.

also since you dont see your wording as problematic (which is odd) and you are not going in on the PR statement.
( if you are putting up so much time in debugging problems on a helmchart - then it should be not a big issue to put up an PR with a solution )
this is how Opensource works - at least it has worked like that.

the paid part is a different scenario for a reason.