-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDS Support does not work with Rails Application and non-MySQL database #136
Comments
We also addressed this internally and a fix will be rolled out very soon. As you mentioned, the workaround is to either 1) override the deploy["database"]["adapter"] value via custom JSON or in an attribute file or 2) to override the database.yml template. We will update this issue as soon as the fix is deployed. |
Sigh. This broke our production app (Rails + Postgres on RDS) without warning. I wound up writing a bunch of deployment shell scripts and moving off Opsworks to Autoscalinggroups + cloud init. |
@sudhirj I'm interested in how this broke you. We only send an additional parameter 'type' that wasn't there before. |
A day before the announcement was made, our deploys (with migrations) began to fail. On looking at the logs, we realized that the I tried turning the migrations off and deploying. Big mistake. Now the deploy went through fine (And opsworks gave me all green checks) but the app couldn't connect to the database. To top it all off, adding an SSH key to an instance didn't seem to work either. After much stopping and starting and experimenting with different instances and types and double checking settings (no changes, deploys always succeeded but results in an app that couldn't connect), I gave up and moved off OpsWorks. That was about 8 hours or downtime, and me sitting up till 3AM trying to get prod back up. Decided I'd rather stick to shell scripts. |
I'm not sure if it was the type parameter or the new IAM role requirement, but something broke connectivity between the app server layer and RDS/Postgres with no warning. No security groups were changed. |
Same problem as pull request #166 |
To be explicit with the workaround. I've had to add this JSON to my deployment:
where |
or something like this:
|
So, I've added a clause like the above to my deployment...and it still seems to be falling back to MySQL. Any other ideas? :-) |
up ? |
It never did work. I gave up. OpsWorks was an experiment for me. It failed for now. I'll try again when Amazon stops dragging its heels and supports PostgreSQL properly. |
Seems like this is still an issue. The work around works, but make sure you use the app's shortname, and not the name: {"deploy":{"app_short_name":{"database":{"adapter":"postgresql","type":"postgresql"}}}} |
It's incredible that this still isn't fixed, almost a year later. I've confirmed that this is STILL a problem. |
@johntxi +1 |
I just ran into this problem. Like sudhirj said my rake db:migrate keeps failing as well and soon as I turned it off, OpsWorks gave me all green checks. How is this not fixed yet? And is there any other way to migrate my database once it's deployed? |
I have come to the conclusion that, for whatever reason, the OpsWorks team just doesn't care about PostgreSQL support. It's sad, and it pretty much guarantees I can't use that service to simplify things, but such is life. |
Its surprising the PR #166 has not been merged yet. @awsrequena you guys can change the case switch statements later, at least fix this issue fix for the existing users. |
Still nothing? |
I really don't understand why you have to mess with the database.yml in the first place. |
What's the status on this?? |
Custom json works just fine. Nothing is broken. See baruchlubinsky's answer advice. Just change the short name to your app sorry name. |
2015 and we are still looking Googling on how to use Postgres with Opsworks. |
Nope. It works without a problem. See @zacstewart's post above. It's exactly how I do it in 5 different stacks. |
@johncblandii Yes it works after you search google and come to this issue. Anyway there are a bunch of issues including no out of the box support for asset precompiles. It is ok if one spends a few hours searching and solving the problem on your own of course. |
The docs tell you the same thing as this issue. Create AWS is just normal Chef stuff. It has a larger learning curve if you haven't used it before (say with Engine Yard or similar) but the AWS docs and forums have these details in them. With that said, I 100% agree some things should be built in. If the RDS database is Postgres, use the PG adapter. Those sort of things just make sense to get built into their system. |
One thing I would change to @zacstewart's answer is to fix a minor typo from
|
closing as this is a very old issue |
I tried to use a Postgres RDS database.
The cookbooks don't correctly set the database type in
config/database.yml
.Apparently
deploy["database"]["adapter"]
is not set, but onlydeploy["database"]["type"]
, which is not used by the rails cookbook. The cookbooks seem to requireadapter
to be set and default tomysql2
when it's not:This results in the database connection failing.
As a workaround, I set deploy["database"]["adapter"] for the application in the Stack JSON.
The text was updated successfully, but these errors were encountered: