Hi, guys,
TL;DR
After implementation of the blueprint[1], now we use olso.log module in
Mistral, just as the same with other projects. However, we still use
mistral.utils.wf_trace module to make some info insertion into log
messages(we want to log execution id or task id during workflow running),
which is a little bit ugly, considering it could be replaced using oslo.log
features itself.
So, I submit the proposal here to bring more people to have an open
discussion, to make sure wo make consensus about that before I start to do
code work.
Below is the long version in rst format:
Problem Description
===================
Currently, we have mistral.utils.wf_trace module to get execution-id and
task-id during mistral workflow execution, then insert them to the log, so
there are plenty of wf_trace.info invokings all around our code repo, which
is much more likely a hacking to log module funtionality, and it's not
consistent with most of the log behavior in code writing.
Proposed Change
===============
Instead of adding an extra wf_trace module, we make use of the capability
provided by oslo.log. Take an example, we have code as below::
wf_ex = task_ex.workflow_execution
wf_trace.info(task_ex, "Task '%s' [%s -> %s]" % (task_ex.name,
task_ex.state, state))
then, you will see from the log with content below:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO Task
'my_task' [WAITING -> RUNNING]
(execution_id=c79b656f-f57f-4761-a270-138ee2417e54
task_id=a8935974-5468-de89-b785-138ee241qefd)``
the execution_id and task_i
d are automatically inserted in wf_trace module. With oslo.log, we could
change the log behavior::
wf_ex = task_ex.workflow_execution
LOG.info("Task '%s' [%s -> %s]" % (task_ex.name, task_ex.state, state),
resource={'type': 'workflow', 'id': wf_ex.id})
and don't forget config *logging_default_format_string* value in
*mistral.conf* to:
``%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-]
%(resource)s%(message)s``
so, the log content would be like this:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task 'my_task' [WAITING ->
RUNNING]``
As you could noticed, the task_id is lost, yes, actually, for the time
being, oslo.log don't provide the capability such as recording various
resources at the same time in one line, which I have send an email to
openstack-dev mailing list to ask what oslo team suggest for this issue.
However, IMO, we have enough information for the operators to debug, we
have execution-id, task name, etc, and most importnantly it's a more
general way for logging.
But, if you really don't tolerate this change, we have workaround here
before the oslo.log has a final solution(maybe that will never happen). We
change the code as below::
wf_ex = task_ex.workflow_execution
LOG.info("Task '%s'(%s) [%s -> %s]" % (task_ex.name, task_ex.id,
task_ex.state, state), resource={'type': 'workflow', 'id': wf_ex.id})
so, the log content would be like this:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task
'my_task'(a8935974-5468-de89-b785-138ee241qefd) [WAITING -> RUNNING]``
Finally, we get rid of the redundant wf_trace module from Mistral, which is
really important for an engineer with OCD :-)
REST API Impact
---------------
No, it's just an improvement internally
Security Impact
---------------
No
Other End User Impact
---------------------
No
Performance Impact
------------------
Absolutely no.
Other Deployer Impact
---------------------
No
Developer Impact
----------------
Yes, it will change how the developers want to log something related to
executions or tasks.
Alternatives
------------
Anyway, we could keep the wf_trace module as it is, but it's a very ugly
way.
References
==========
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
[1]: https://blueprints.launchpad.net/mistral/+spec/mistral-log-enhancement
--
Regards!
-----------------------------------
Lingxian Kong
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
