+1 on details of these plugins. I'm having trouble with newsdesk's translate plugin from github as it needs to write to the locales directory. It's a gui to rails i18n locale files. I just spent a day setting up another server and troubleshooting it at Railsplayground so that my translation team can use this gui. I had loads of issues with gem install requests, suspected misconfiguration at the server end, tech support overwriting my environments/production.rb file without telling me. Got it working in the end but it was a real headache, if I'd know I would have just sent them the yaml files to the translation team.
I hated having to go back to Railplayground and battle with Cpanel interface and so a plugin which rerouted file writes to my S3 account would be great as it means I could stay with Heroku all the time (me => happybunny). I know I'll run into this sort of thing again with some other plugin or app I want to run on Heroku. How are assets handled when using a CMS such as Radiant for instance? I know their was a tutorial, publicised on a Heroku blog, on how to get it running on Heroku and so assuming there must have been a solution there for uploaded assets. I figure that there are lot's of ways to write to the local file system and so such a plugin would need to think of all cases that it needs to intercept. No easy task me thinks. A plugin would be a short term fix, but the best thing would be for Heroku to introduce a feature to make this transparent. It could use some sort of magic directory that appears to the Heroku rails app as being a normal local directory. If the user writes to this however Heroku would actually intercept the writes and feed them to a named bucket on the users S3 account. Would this approach bypass EC2 scaling issues assocaited with Heroku's architecture. I guess this would mean that we would need some way of providing Heroku with security details for an S3 account along with the target bucket for each app via the heroku gem. This should allow users to be billed for storage and bandwidth directly from S3 as Heroku is effectively only working as an S3 uploader. Obviously the contents of this 'magic' directory would not count towards Heroku's storage quota. A feature such as this would mean I can stop messing about with S3 up-loaders like S3Hub or S3fox for managing my static assets. The side benefit being that these app assets can become part of my git workflow once again whilst benefitting form being served from my S3 account. Obviously there would still be a requirement to change routes for some apps that assume they can write anywhere in the app, but this code is usually relatively easy to find and change comapred to trying to bootstrap the write entirely to s3 using the AWS s3gem or suchlike. A final thought, and again only as a short term solution to my specific problem with the translate plugin, how long are files in the tmp and log directories kept ther, are these routinely cleared out by Heroku's houskeeping routines? If so how often. If I knew that I could temporarily reroute the translate plugin to the tmp directory and be confident the files would stay there for a week or so then I could do that as a short term hack. If not the tmp directory what about the logs directory? Thanks. Rob On Oct 14, 11:00 am, Neil <[email protected]> wrote: > Do you have links to any of these plugins at all or is it still to > early? > > N > > On Oct 6, 10:32 pm, Oren Teich <[email protected]> wrote: > > > > > Hi Neil, > > There aren't any plans for shared storage right now. I wish I could > > say otherwise. The big challenge is that we're able to achieve our > > scaling and overall cool features by imposing certain constraints. A > > read-only file system is one of those. If we had a shared filesystem, > > we wouldn't be able to offer the scalability or performance that makes > > our platform so unique. There are some interesting plugins that some > > 3rd partys have in development that will capture filesystem requests > > and send them to S3 instead. Hopefully as these come out they might > > help address some of the constraints for you. > > > Believe me, I wish we could figure out a way to give you a writeable > > filesystem! > > > Good luck, > > Oren > > > On Oct 6, 2009, at 2:53 AM, Neil wrote: > > > > One of the big issues we have with Heroku as a business at the moment > > > is the read-only file system and the fact that this then renders some > > > of our legacy apps, and our CMS of choice, BrowserCMS, unable to be > > > deployed without some serious hacker-age. > > > > Question is, are there any plans at all for some sort of shared > > > storage, where I can somehow define a directory or two that should be > > > shared across all dyno's serving my application, as well as across all > > > deploys of my application? > > > > For me, this is a major thing, and it would be good to remove one of > > > the big barriers that people might have. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~----------~----~----~----~------~----~------~--~---
