Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

PIVOTAL LABS
Standup 6/29/10 – EngineYard Redis change

Help!

  • Ey cloud deploy – has anyone done a deploy to EY cloud and seen the Mongrel instances not get bounced?
  • Does anyone have any tips on testing distributed applications? We’re looking for the least ugly/painful way to do it well.

Interesting Things

  • Rvm and sudo – for goodness sake don’t do it.
  • Sass not recompiling on deploys – a few of our projects have seen Sass files not recompile/update for some reason that we’ve yet to track down. So instead of spelunking through Sass code we just force the issue by having a rake task that forces the recompile – see this post for details.
  • Rails xhr redirect – one of our projects is using the xhr_redirect plugin to support ajax redirects – careful if you want to use it in your tests – it self-destructs if your Rails environment == ‘test’
  • Android meetup tonight at 6:30 PM – check out the details.
  • New Redis recipe from EY – following up from yesterday, the new EY recipe to set up Redis appears to work fine with a little tweaking.

Comments
  1. Luis Lavena says:

    RE: Mongrels and EY cloud

    Seems is a ongoing problem. Mongrels never get restarted on time — sometimes it takes 10 minutes for all the mongrels of one slice be ripped and spawned newer versions.

    We ended moving to Passenger which solved that but introduced the stop world request of dead after touching tmp/restart.txt :-P

    Can you tell us what tweaks did you introduce in the recipe?

    We needed using dnapi to be able to have redis configuration in the app and app_master slices.

  2. I have the mongrel issue for EY cloud, too. I usually solve it by doing a deploy:restart via capistrano after doing the deploy.

  3. Jason McCay says:

    We have experienced similar issues that seemed to start a few days ago with our Engine Yard AppCloud deploys. After the application was deployed and loaded in a browser, the .css files were not being created from the .sass files.

    Since we ignore our .css files in development, this caused sites to lose their styles. We are still not sure why this is happening and are wondering if it is a deploy script error on Engine Yard’s end…but even then, I am not necessarily sure why that would be the case.

    The .css should be created based on the timestamp of the .sass files…but more importantly, the .css file isn’t even there, so there would be no timestamp to compare it to.

    Puzzling.

  4. Jason McCay says:

    As a quick followup, we are using Haml 3.0.13.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *