Logger is feature complete; Ginkgo feature complete?

[Jeff Lindsay]

Just pushed to master some commits that do these things:

 - Implemented logger behavior/API previously discussed

 - Initialize app service after daemonization

 - Shed privs after start

In reverse order detail:

## Shed privs after start

Changing the user/group needs to happen after you've done any port binding. This is expected to be done in do_start, so we move changing user/group out of process.do_start to process.post_start, making it happen after all do_starts. 

## Initialize app service after daemonization

In a previous email, we talk about how we would like to assume we can safely do IO operations in our service's __init__'s (even though you shouldn't, sometimes you have to ... and saying you can't seems like an arbitrary constraint to put on the user). We wanted to keep __init__ calls before daemonization because it was assumed this was needed to get configuration help. This turned out not to be the case, so I simply put calling your top level service's __init__ towards the end of Process.do_start, after daemonizing (which now happens before anything else). 

## Implemented logger behavior/API previously discussed

The logger module exists to let us safely use Python's standard logging from Ginkgo. Earlier, it provided the most basic "log to a file" functionality. Now it lets you get that as default behavior that can be configured in several ways. There are three builtin settings you have for logging:

 logfile - Filepath to log to in the simple case (defaults to a log file under /tmp currently). Ignored if logconfig is set.

 loglevel - Log level to use in simple case (defaults to debug). Ignored if logconfig is set.

 logconfig - Can be one of three things or None, which implies simple case configuration (defaults to None):

   1) Dictionary of values to pass into logging.basicConfig

   2) Dictionary of values to pass into logging.config.dictConfig (since the 'version' key is required, that's how we know)

   3) Filepath to an ini file compatible with logging.config.fileConfig 

I think the result is the most easy to configure, yet expressive, good-defaults way to use Python logging. And you can easily change your configuration between any of these and reload a running process and logging will change. 

## NOW WHAT

This concludes the functionality expected for a 1.0 release! Anything else (for example, eventlet support, etc) won't go in until after 1.0. What's needed before a release candidate?

  - TESTS

  - DOCS

  - BUGS?

How can you help?

 - Port your gservice apps to Ginkgo!

 - Build stuff with Ginkgo!

 - Report bugs with GitHub issues!

 - Review code and comment on list!

If you're feeling extra charitable:

 - Write tests!

 - Write docs!

--
Jeff Lindsay
http://progrium.com