having played with Amazon EC2 infrastructures myself I can understand the architectural problem. EBS volumes can only be attached to one Instance at a time so you have to run an EC2 Instance to expose the EBS volume as a NFS share to your application instances - immediately a single point of failure is introduced.
So assuming the point of failure is acceptable - a dyno would then have to be able to link to an apps shared area on the NFS - not knowing much about the Heroku archicture mind you it doesn't sound all that complicated in theory. Currently with our BrowserCMS installs on Rackspace, uploads are stored in shared/uploads which we present as /tmp/uploads via a symlink so we can replace the code/templates without touching the uploaded assets. talking in theory here, I'm sure the guys at Heroku would have implemented this if it was possible....guys - any thoughts? On Oct 15, 1:50 pm, "[email protected]" <[email protected]> wrote: > +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 -~----------~----~----~----~------~----~------~--~---
