R
Railway12mo ago
bjn

Confusion regarding redis migration

I was asked to migrate a redis cache to the new V2 databases thing. My application is not working now that it has finished. It fails to connect to redis. I expect the configuration is no longer correct. But I'm getting confused among all the variables. The old redis service ("Redis Legacy") has a tab "connect" with a section "available variables", where it lists REDIS_URL, REDISHOST, REDISPASSWORD, REDISPORT, REDISUSER. My application was using this via REDISHOST, REDISPASSWORD, REDISPORT, REDISUSER. The new redis service ("Redis") does not have a "connect" tab. Instead it has a "variables" tab which lists 9 things:
RAILWAY_RUN_AS_ROOT
RAILWAY_RUN_UID
REDISHOST
REDISPASSWORD
REDISPORT
REDISUSER
REDIS_PASSWORD
REDIS_PRIVATE_URL
REDIS_URL
RAILWAY_RUN_AS_ROOT
RAILWAY_RUN_UID
REDISHOST
REDISPASSWORD
REDISPORT
REDISUSER
REDIS_PASSWORD
REDIS_PRIVATE_URL
REDIS_URL
Not only are there duplicates (REDISPASSWORD and REDIS_PASSWORD for example), these are editable and I don't know if I'm supposed to or if that would break something. What's more, my application service's "variables" tab now has duplicates of some of the variables. Along with the ones I added manually, I see REDISHOST, REDISPASSWORD, REDISPORT, REDISUSER, REDIS_URL. I don't remember adding these manually. It looks like these have been copied from the new "Redis" service (but why only these, why not also REDIS_PRIVATE_URL and some of the others), since for example REDISHOST is the same as on "Redis", not the same as on "Redis Legacy". I notice that the "shared variables" feature does not seem to be active; it tells me "no shared variables yet". Can someone help me untangle this confusion? I don't know if some of the variables are legacy and so I can delete them. I don't know if I'm expected to copy or edit or share any of these.
Solution:
reference the variables from it in your apps service the same way you always have https://docs.railway.app/guides/variables#reference-variables
Jump to solution
14 Replies
Percy
Percy12mo ago
Project ID: bb413c1a-f4bc-4df7-94e1-76afdb0a4d82
bjn
bjnOP12mo ago
bb413c1a-f4bc-4df7-94e1-76afdb0a4d82 I guess maybe I want to use REDIS_PRIVATE_URL to connect? But that one wasn't copied/shared over to my application. I don't know if I'm expected to do that myself. It also worries me that it's defined as redis://default:${{REDIS_PASSWORD}}@${{RAILWAY_PRIVATE_DOMAIN}}:6379 which doesn't pull in the actual value of REDISUSER or REDISPORT, it's just hardcoded as "default" and "6379" OK it seems in fact my app is working as is. It gives a "timed out when trying to connect to redis" message at the start of each deployment but then I guess it manages to connect. So maybe there's no real problem? Though I'm still super confused about all these variables.
Brody
Brody12mo ago
there duplicates (REDISPASSWORD and REDIS_PASSWORD for example)
REDIS_PASSWORD is there to set the password, REDISPASSWORD is there for backwards compatibility. 
these are editable and I don't know if I'm supposed to or if that would break something.
you should have no need to edit the variables on the redis service itself 
It looks like these have been copied from the new "Redis" service (but why only these, why not also REDIS_PRIVATE_URL and some of the others)
REDIS_PRIVATE_URL among others are new variables only available with a redis v2 database. 
I notice that the "shared variables" feature does not seem to be active; it tells me "no shared variables yet".
dont quite know what redis has to do with shared variables tbh, maybe im not understanding where youre coming from on this? 
I guess maybe I want to use REDIS_PRIVATE_URL to connect.
it would be a good idea, but youd need to reference it first https://docs.railway.app/guides/variables#reference-variables. 
But that one wasn't copied/shared over to my application. I don't know if I'm expected to do that myself.
yes, see above link.
It also worries me that it's defined as redis://default:${{REDIS_PASSWORD}}@${{RAILWAY_PRIVATE_DOMAIN}}:6379
the user will always be default and the port will always be 6379. feel free to ask for any further clarification on anything, but im gonna drop some links to the new docs that i think would be a worthwhile read! https://docs.railway.app/guides/redis#private-networking https://docs.railway.app/reference/private-networking https://docs.railway.app/guides/private-networking#known-configuration-requirements-for-ipv6
bjn
bjnOP12mo ago
REDIS_PASSWORD is there to set the password, REDISPASSWORD is there for backwards compatibility
What was wrong with the old one? If a underscored version of that was added, why not also one for port etc? The underscored one is not even mentioned in the documentation. https://docs.railway.app/guides/redis
you should have no need to edit the variables on the redis service itself
Why allow the user to do this? It just adds confusion. The old way was clear: "this service provides these variables".
dont quite know what redis has to do with shared variables tbh
The migration seems to have made copies of many of the variables from the new redis service to my app service; why would it use copies which I'm worried I can break accidentally later when there's a shared variables feature?
the user will always be default and the port will always be 6379
Yet for some reason the UI allows the user to edit them. Don't you see a problem here?
Brody
Brody12mo ago
What was wrong with the old one? If a underscored version of that was added, why not also one for port etc?
nothing was wrong with it, the variable with the underscore is just what that image uses to set the password, this is what bitnami set the variable to.
Why allow the user to do this? It just adds confusion. The old way was clear: "this service provides these variables".
I didn't say you shouldn't or that you can't edit them, but allowing the user to edit or add more brings great flexibility to those who need it, for those who don't you can simply treat them as read only as they where on the legacy databases.
The migration seems to have made copies of many of the variables from the new redis service to my app service; why would it use copies which I'm worried I can break accidentally later when there's a shared variables feature?
if you where using reference variables before, they should have been updated, but for me to get a better understanding of this particular question I'd like to ask for some screenshots.
Yet for some reason the UI allows the user to edit them. Don't you see a problem here?
nope, it allows for greater flexibility now that databases are just a service with a volume.
bjn
bjnOP12mo ago
But you just said the username is always default and the port is always 6379. So why are those editable? Wouldn't I break either the redis service or my app by editing the URL strings? What flexibility is the ability to edit them adding exactly?
Brody
Brody12mo ago
But you just said the username is always default and the port is always 6379. So why are those editable?
definitely could have been clearer here.. they are always going to be default and 6379 when you deploy the database.
So why are those editable?
editing any variable allows the user to set up their database how they want, if you dont need that then nothing to worry about.
What flexibility is the ability to edit them adding exactly?
the user could add more variables that could set the database to act or run differently, not just redis, im talking big picture.
bjn
bjnOP12mo ago
I'm not talking big picture, nor do I want to. To me and everyone else who did this migration, this is just a redis service, and shouldn't be configurable any more than the legacy one was. The new way it's presented, and the way this migration reconfigured things, is confusing. Should I delete all the REDIS* variables from my app service and instead share particular variables from the redis service?
Brody
Brody12mo ago
you are absolutely right, it is just a redis service, if you dont need anything special from it, just treat it like a redis service
Solution
Brody
Brody12mo ago
reference the variables from it in your apps service the same way you always have https://docs.railway.app/guides/variables#reference-variables
Brody
Brody12mo ago
Should I delete all the REDIS* variables from my app service and instead share particular variables from the redis service?
if thats what you would like to do go for it, just make sure you are using referance variables in the end
bjn
bjnOP12mo ago
Oh. What I had failed to remember is that these even are reference variables. That isn't made clear in the UI until I ask to edit the variable. That's a shortcoming in the UI. So yeah maybe these weren't copied but rather were references I set up a year or more ago. Less scary and confusing now
Brody
Brody12mo ago
i fully agree with you there, with the legacy databases youd also get an icon bedsides the variable, so yes 100% on that side of things its confusing
bjn
bjnOP12mo ago
I opened a thread in "feedback" https://discord.com/channels/713503345364697088/1184615479374008491 I think this one can be closed.
Want results from more Discord servers?
Add your server