Simplifying runner, service controller

[Jeff Lindsay]

I alluded to this in other topics, but if we make the Process
container service take care of configuring process level properties
(pidfile, daemonizing, etc), then our runner would become very simple.

ginkgo -c path/to/myservice.conf.py

The config would say whether to daemonize or not. Etc. Most of the
hardcoded arguments would go back into configuration land. The only
options the runner would have are:

-c, --config Point to your configuration file (or several of
them, executed in order)
-s, --service Point to a Python module and class using default
configuration (ie mymodule.MyService)

If you're service wants to expose configuring to the CLI, you can pull
from the environment explicitly in your config:

# myservice.conf.py
import os

port = int(os.environ.get("PORT", 5000))

Then you could do:

PORT=9000 ginkgo -c path/to/myservice.cong.py

But then, hey, what about start, stop, restart, reload, etc?

These would be pulled out into a separate command with similar
arguments, but since it is about sending signals to your process, you
can also just specify a pid:

ginkgoctl -c path/to/myservice.cong.py start
ginkgoctl -c path/to/myservice.cong.py stop
ginkgoctl -c path/to/myservice.cong.py reload

This assumes the config has a pidfile and you daemonize. Let's say you
start it with:

ginkgo -s mymodule.MyService

That would start a process in the foreground. You could still use
ginkgoctl to interact with it:

ginkgoctl -p 2745 reload

Anyway, this separates concerns a bit more and makes the simple case
much more common. And if you don't want to use ginkgoctl because you
have some other process manager (upstart, whatever), you don't have
to.

[Bulat Shakirzyanov]

What about making service runnable modules? Then you could do

pythom -m mymodule.MyService

to run it in foreground

--
Bulat Shakirzyanov | Software Alchemist

a: about.me/avalanche123

e: malll...@gmail.com

[Jeff Lindsay]

Right, I talked about that before. -m only works for modules. So your module would have to define a way to run your service. Alternatively you could do

python -m ginkgo mymodule.MyService

But then you might as well just use the ginkgo CLI. 

And then you'd only be able to use that when you just want the default configuration. So once you want your own configuration, you'd have to use the ginkgo tool. You might as well start with it. 

-jeff

--
Jeff Lindsay
http://progrium.com

[Jeff Lindsay]

As Kenneth Reitz points out, ginkgo doesn't need two options. It can
just take arguments that are either a config file path or a module
path to a service. And in the case of multiple configuration files,
you can just list them as arguments and they'd load and override in
that order.

ginkgo path/to/base.conf.py path/to/dev.conf.py

ginkgo mymodule.MyService

etc

-jeff