added graphite-module to pythonpath
modified to ensure compatibility with python2.6

235: line = "{}.{}\n".format(path, metric) is python 2.7 syntax
DEVEL-986: improves exception handling of MultiReader
DEVEL-986 improves exception handling of nodes

should avoid that http exceptions get forwarded to clients
DEVEL-986 disabled best_coverage selection for the moment to investigate duplicate elimination
Merge branch 'datalib-exceptions'
Revert "Merge branch 'datalib-exceptions'"

This reverts commit 271f0a876182fd909521408a0695f98f0559b4b0, reversing
changes made to 54e286ad5eb39bd8e48b2b2b2d71be29d24ba6bb.
DEVEL-986: Better exception handling, do make data fetching more robust
Merge branch 'new_fetch_exception'
DEVEL-986 makes max retries for render.dataview.fetch configureable
Merge branch 'configureable_max_fetch'
log exceptions on remote retry
don't copy irritating example conf files in post install, which will not belong to the rpm
fix data-cache invalidation

This fixes and issue with adding data to the data-cache. The previous
implementation used 'set' instead of 'add'. As discussed in
https://docs.djangoproject.com/en/dev/topics/cache/ 'set' will add the value
again, even if it exists already. This has the side-effect of also updating the
cache expiry time.

This means, that when you use 'set' on values that have been retrieved from the
cache, you keep bumping the cache expiry time and thereby extending the
life-time of the data in the cache.

This behaviour can lead to problems if you select a time in the future as your
value for the 'until' parameter in your query and then keep sending that query
at intervals smaller than the DEFAULT_CACHE_DURATION. The result is that you
will, until you cease requesting at that interval, receive the same values,
even if new values have become available in the meantime.

To reproduce select an existing metric and fix the 'from' and 'until' times to
fixed values selecting the 'until' time to be in the future:

current time is 12:0520131106:

curl "http://grphite/render/?target=METRIC&format=json&from=12:0020131106&until=12:2020131106&local=0"

Then execute the above curl statement in a while loop for about 15 minutes.
Observe how the same set of values is returned over the course of these 15
minutes.  Then, wait one minute (or whatever you set DEFAULT_CACHE_DURATION to)
and execute the curl query once again. Observe how several additional values
have appeared.

The fix is to use 'add' instead of 'set'. 'add' will only add new values if
they do not exist already.

If you apply this patch and try the same while loop again, observe how any new
values are fetched correctly one minute after they actually become available
from carbon.

Of course this depends on how often the metric is written to carbon. In my
example above my metric was written every 5 minutes.
improve data-cache invalidation

The further improves the previous commit by only even communication with the
cache, if the data has not been retrieved from the cache. The 'add' instead of
'set' is still used to make sure that concurrent WSGI workers who are accessing
a distributed cache, e.g. memcached, don't interfer with each other.
Merge branch 'fix_data_cache' into is24-master

* fix_data_cache:
  improve data-cache invalidation
  fix data-cache invalidation
configure NullHandlers in case logging is not requested

We frequently see error messages of the form:

[Tue Nov 12 01:06:53 2013] [error] No handlers could be found for logger "cache"

This commit fixes that issue.
reconfigure the metricAccessHandler

Make it have a backup of 1 file, like all the other Rotators. Also, this logger
isn't even used anywhere, so it will not matter.
introduce a function to configure loggers
configure infoLogger via function