I have several surprising behaviours on my application, 'getplantin-shah'. I've never had similar experiences with my other apps, so I'm just writing them all up in one bug report; but if you need me to split this up into multiple bugs, please let me know. I have created a few php apps and added mysql and phpmyadmin cartridges just fine on them. I've only used the command-line tools for this. When I added the mysql cartridge, the tool would show me the host, admin passwd, etc., info on success. For this new app, getplantin-shah, I didn't get these details on adding the mysql cartridge. I tried removing and adding multiple times, with same results. I even tried doing this from the web console once, and that didn't change things. I ssh'ed into the server, and checked the env. vars. There's no DB-related variables there. I temporarily modified my app to use sqlite instead of mysql, and that seems to get the app working. Another oddity is that the web console shows 'Status: 0/0 started', 'Gears: None'. All my other apps have 'Status: started', 'Gears: 1' listed, so maybe this is related? Note that the app is working even 'Gears: None' being listed in the web console. I didn't create the app with the '-s' option, so scaling isn't enabled. Finally, I've pointed getplant.in to getplantin-shah.rhcloud.com, but the redirect insists on going to https://getplant.in/app. Why does it use https instead of http, and why does it go to /app? Removing /app, the page doesn't show up anything. My other apps with aliases work fine, though. 'rhc domain show' output for this app: getplantin Framework: python-2.6 Creation: 2012-08-18T02:01:20-04:00 UUID: b7d6936846f641038820f760bf824415 Git URL: ssh://b7d6936846f641038820f760bf824415.com/~/git/getplantin.git/ Public URL: http://getplantin-shah.rhcloud.com/ Aliases: getplant.in, www.getplant.in Embedded: mysql-5.1 phpmyadmin-3.4 metrics-0.1
What version of the client do you have?
Amit, something is wrong with this apps setup. We are looking to figure out what went wrong. But you'll probably want to delete the app and recreate it. We might have to delete parts of it manually. Let me know if you want to go this route and we can work out the details.
(In reply to comment #1) > What version of the client do you have? rubygem-rhc-0.92.11-1.fc16.noarch The other apps (which are working perfectly fine) were created on a different system, which has a different version of the 'rhc' package: rhc-0.96.9-1.el6_3.noarch. Both run F16. (In reply to comment #2) > Amit, something is wrong with this apps setup. We are looking to figure out > what went wrong. But you'll probably want to delete the app and recreate > it. We might have to delete parts of it manually. Let me know if you want > to go this route and we can work out the details. I can destroy and re-create the app, this time from the other machine, to check if things work OK. Do you want me to preserve some parts of the app for your troubleshooting? Do you want me to keep the app around till some time for you to poke at it?
Lets keep the app for a while to debug. I assume you can still create similar app successully using the same client tool without issues, so its not a consistent problem.
(In reply to comment #4) > Lets keep the app for a while to debug. > I assume you can still create similar app successully using the same client > tool without issues, so its not a consistent problem. Dunno; I've reached my limit of maximum apps, so can't confirm things till I destroy this one and re-create another one.
Ok. I think you can destroy and re-create the app. The existing app in its current form will be difficult to restore. Debugged this and found that there was an apparent server restart that happened at the same time as the app was being created. This resulted in runaway gear. There are known issues with database consistency that we are addressing in forthcoming releases. The DNS should get fixed with the new app as well. Please let it be known if there are issues in deleting the old app.
Amit, could you please help mark this bug as VERIFIED if your problem has gone since the comment#6. And we cannot know that if your account's issue has been resolved. Thanks.
(In reply to comment #6) > Ok. I think you can destroy and re-create the app. The existing app in its > current form will be difficult to restore. > > Debugged this and found that there was an apparent server restart that > happened at the same time as the app was being created. This resulted in > runaway gear. There are known issues with database consistency that we are > addressing in forthcoming releases. > > The DNS should get fixed with the new app as well. Please let it be known if > there are issues in deleting the old app. I re-created the app, and everything's working fine now. Thanks.
(In reply to comment #7) > Amit, could you please help mark this bug as VERIFIED if your problem has > gone since the comment#6. I can, but as I understand from comment 6, the fix is supposed to be rolled out in the future. Do you want to wait for the fix to be rolled out and use this bug for tracking?
Lets treat this bug as production issue arising from known limitations. We are tracking the inconsistency problems as part of planned feature work. Based on comment #8, marking this bug as verified.