On Tue, Apr 13, 2010 at 5:34 PM, Pete <p...@kapiti.co.nz> wrote:
> I need to pass some startup options on to my rails application. Using
> environment variables will not work because multiple mongrel clusters of my
> rails application (each of a slightly different flavour) served from a
> single code base can run concurrently and each cluster instance is activated
> via mongrel_service.
>
> Extra arguments passed in to either mongrel_rails service::install or
> mongrel_rails cause errors.
>

I think you've already reported this to me here:

http://github.com/fauna/mongrel_service/issues#issue/4

And if wasn't you, pretty much is similar request.

> The only documentation on the --script option I could find related to unix
> so I gave up on that thought.
>

Script takes any Ruby script and execute it before starting mongrel,
and is honored by mongrel_service

> I also tried using the --config option, but I had the same problem there: as
> soon as I added an option to the YAML file that wasn't documented, mongrel
> complained with an error.
>

mongrel_rails start --help:

    -C, --config PATH                Use a config file
    -S, --script PATH                Load the given file as an extra
config script
    -G, --generate PATH              Generate a config file for use with -C

mongrel_rails start -G foo.yml
** Writing config to "C:/Users/Luis/projects/secret/foo.yml".
** Finished.  Run "mongrel_rails start -C
C:/Users/Luis/projects/secret/foo.yml" to use the config file.

> The last one is a real nuisance. It just doesn't make sense that my config
> file should be restricted to content mongrel understands. Wouldn't it be a
> better approach to parse that file and look/apply the options mongrel
> recognises and provide a public interface so that other interested clients
> can access the config file?
>

Sorry, but is the configuration file *for* mongrel, nobody says to you
that you should use it.

The problem is that you're trying to use the same application, the
same checkout of it and everything to run multiple instances that are
different on configuration settings.

Apologizes for this but that is wrong.

Even sharing database.yml could lead to problems.

> Or are there other ways to achieve this without resorting to modifying
> mongrel and mongrel services startup code?
>

Do checkouts of your application on different directories. Have
per-location configuration settings like config/settings.yml that is
not part of your application source code.

Is kind of complicated expect the same application folder serve
multiple versions of the same application. Perhaps if you would
explain better what are those settings we can advise you on different
approaches.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

Reply via email to