On 01/20/11 10:41 AM, Ginnie Wray wrote:
Hi William -
Your suggestion for a server-side boolean parameter sounds reasonable.
Would you file a bug on it, and I'll add the functionality?
thanks,
ginnie
On 01/20/11 05:19, William Schumann wrote:
Ginnie, Dave,
Please find my responses inline:
On 01/19/11 01:17 AM, Ginnie Wray wrote:
Hi William -
You should be able to use the InstallLogger. The DC was able to
modify it It creates its own logging files. Here is a sample of what
they did:
global DC_LOGGER
DC_LOGGER = logging.getLogger(INSTALL_LOGGER_NAME)
# set the logfile name
log_name = "log.%s" % time.strftime("%Y-%m-%d.%H:%M")
detail_log_name = "detail-%s" % log_name
simple_log_name = "simple-%s" % log_name
# create an additional FileHandler for a simple log
base, logfile = os.path.split(DEFAULTLOG)
simple_logname = os.path.join(base, "simple-" + logfile)
simple_fh = FileHandler(simple_logname)
simple_fh.setLevel(logging.INFO)
DC_LOGGER.addHandler(simple_fh)
Through the installLogger, when adding a handler, the format has a
default unless another is applied to the handler. So the format can be
modified.
When you invoke the InstallLogger, you get the default log and the
default format, but you can add additional handlers to fit your needs.
During the design, Sarah wanted there to be defaults that were not able
to be modified. Thus the hardcoded location of the log. If the defaults
don't work for a situation, it would make sense to see what needs to be
done to make it more flexible.
So it appears that InstallLogger was designed to be inflexible to
benefit installation on the client. InstallLogger forces use of a
log file named /var/tmp/install/default_log with the PID appended.
Neither the filename nor path is appropriate for the AI server UI or
CGI. The CGI should be as efficient as possible, and it should not
be doing any unnecessary logging. So there's a basic conflict in
using it for a CGI and the AI server.
Recall too that there are three places where the log level is relevant:
- Individual logging statements (logger.warn(), logger.debug(), etc.)
- The overall InstallLogger has a log level set
- Each log handler has a log level set
The InstallLogger's log level takes precedence in terms of preventing
unnecessary logging. So if you set InstallLogger's level to "WARN",
then, despite the fact that the default file handler's level is "DEBUG",
no logger.debug() statements will get logged.
To be truly performant, you'll also want to ensure that logging
statements of the form:
logging.info(" Deleted profile " + deldict['name'])
are changed to something like:
logging.info(" Deleted profile %s", deldict['name'])
Using that form will defer the performance expensive string operations
to the last possible moment - and more importantly, skip them entirely
if the InstallLogger never actually logs the statement (as a result of
the log level).
Adding a flag to allow for non-use of the default file handler may still
also be valuable, but the above should be considered first and made use
of regardless.
- Keith
The one benefit InstallLogger has for CGI and server UIs is that it
has a good standard class name. If I were to adapt InstallLogger, I
would add a boolean parameter indicating server-side functionality,
which would bypass the logfile handler intended for the client:
Arg (optional, defaults to False): server - set to True to indicate
server-side logic
Server-side logic would inhibit logging intended for client.
On 01/17/11 10:42, William Schumann wrote:
Dave, responding to your logging comments below.
On 01/12/11 09:51 PM, Dave Miner wrote:
On 12/21/10 11:32 AM, William Schumann wrote:
Requesting code review for enhancements for service
configuratiohttp://cr.opensolaris.org/~wmsch/profile/ n
profiles in the Automated Installer.
http://cr.opensolaris.org/~wmsch/profile/
...
45, 46, others: I'm skeptical of having our own log rotation going
on here. logadm is the general facility in Solaris for
administrators to control log rotation and I'd prefer to see that
used since it provides a way for them to express their preferred
policy, which doesn't seem to be supported here. Also, I'm
somewhat surprised that this isn't using InstallLogger, but
perhaps there's a reason that's not suitable somehow?
The InstallLogger class from solaris_install/logger.py was written
for the install environment on the install target, and not the
installadm UI nor an AI server CGI (e.g., logfile is hard-coded for
/var/tmp, formatting method seems to be intended only for the
Transfer phase logging, hardcoded formatter, etc.).
However, logger.py does seem to be a more appropriate place for new
AI server-side logging code than common_profile.py.
To substitute logadm for the RotatingFileHandler, I think it could
be accomplished like this:
- if an /etc/logsvc.conf record for installadm logfile did not
exist, installadm would append one, leveraging fmadm(1M) with some
defaults
- replace RotatingFileHandler with a non-rotating logging handler
like logger.py's FileHandler, which is a class derived from the
Python logging.FileHandler class (needs some exception handling for
failure to create log directory or log file)
You would be able to do that with code similar to what I've included
above.
Yes, thanks for that.
To recap, I would add the "server" boolean argument to suppress the
normal InstallLogger logfile, then use logger.py's FileHandler to add
a handler for a logfile to be pruned by logadm(1M). The logadm
command would be run upon the installation of the installadm package
on the AI server.
Thank you,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
