On 07/29/2010 07:56 PM, David Lutterkort wrote:
On Thu, 2010-07-29 at 19:30 -0400, Mohammed Morsi wrote:
On 07/28/2010 06:51 PM, David Lutterkort wrote:
On Wed, 2010-07-28 at 13:13 -0400, Mohammed Morsi wrote:
This will also break in some deployment scenarios like heroku.
Not too familiar with heroku, just curious as to why this wouldn't work
there.
No writable local storage - http://docs.heroku.com/constraints
I think we should be fine on heroku because of the following (from that
page):
"There are two directories that /are/ writeable: |./tmp| and |./log|
(under your application root). If you wish to drop a file temporarily
for the duration of the request, you can write to a filename like
|#{RAILS_ROOT}/tmp/myfile_#{Process.pid}|. There is no guarantee that
this file will be there on subsequent requests (although it might be),
so this should not be used for any kind of permanent storage."
Since we're writing keys to the ./tmp/keys dir, and we only need it for
the duration of the request, this should all work there for the time being.
Can you elaborate on what this RackSpace file injection feature is and
what it entails. Thanks.
In RS, when you create an instance, you can include up to 5 files (paths
+ contents) that will be overwritten in the instance before it is
started (using scary uses of kpartx) It's described on page 23 of
http://docs.rackspacecloud.com/servers/api/cs-devguide-latest.pdf
David
Is this a critical use case? Or one that can be taken care of at some
later point?
I suppose if some custom files need to be present for use when booting
an instance, we'd have to implement this, but I'm not aware of any
production scenarios that require this (at least for Linux instances,
feel free to correct me if I'm wrong).
Or if there are some major cases for this, could this be solved by
creating new images which contain the custom files necessary for booting
up the desired instances?
-Mo
