On 02/27/2015 10:50 AM, James E. Blair wrote: > Ian Wienand <[email protected]> writes: > >> Hi, >> >> Firstly, being someone who is trying to keep several images going in >> nodepool and being some distance away from the nodepool servers, the >> current situation of it logging to a single rather large file is often >> annoying. Yes I do know how to use grep, but IMO the use-case for >> wanting every single log message all jumbled up is weaker than the >> case for splitting it up. > > Yes, there is no good use case for that, I would love for them to be > split. > >> I'm trying to get on-top of fedora kernel issues; compare logs for >> centos builds to some manual testing being done and generally monitor >> the health of the builds. > > By the way, does a resumed transfer work for a partial download (ie, the > HTTP Range header)? > >> There is a proposal to have nodepool automatically split out these >> logs [1], have puppet deal with it [2] and I'm willing to add nodepool >> support for re-reading the config if we can agree. > > I do not think that OpenStack's logging configuration should be > contained within the nodepool source code. I think any of these > alternate approaches would be okay: > > 1) Have a logger definition in a config file that is treated as a > template and then automatically duplicated for each provider-image > combination. > > 2) Stop using the python logging module and just take a path for the > directory and write files there, leaving rotation/cleanup to an external > tool (that we would manage with puppet). > > 3) Manually create log config file entries for DIB images, since there > won't be as many of them. Once we finish moving away from snapshot > images, the set of logs and configuration for them will be manageable. > > There might be other options I haven't thought of.
4) Just use syslog, and have splitting/rotation handled at the system level by syslog config (not saying that's preferrable, just where my brain went wrt listing things) _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
