Community
Participate
Working Groups
Build Identifier: rev 1098 We need a new way to send a command with the client to be able to script action more easily. The scripting system already available in the client doesn't give the ability to make decisions based on the output of the client. We should be able to create a bash script that uses the tcf client to send commands and interpret the output correctly. Reproducible: Always
Created attachment 175995 [details] Patch that add new command line arguments to send commands This patch adds a new way to send command with the client. You can now call the client with the -c flag and give it a command to send. -c COMMAND To give the possibility to send the command to any agent, you can also specify the host with the -h flag (default = localhost). -h HOST We also added a new flag that can be used with those new command. -d keeps the client alive after it sends the command. When using this mode, the program can be killed by sending the kill signal or it can be killed by a plugin. This mode is necessary to be able to gives the client plugins that wait for events after a command to be able to receive them. What do you think about it ? Legal Message: I, Michael Sills-Lavoie, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL and EDL. I am authorized by my employer, École Polytechnique de Montréal, to make this contribution under the EPL and EDL.
Another option for scripting in TCF is Lua: http://dsdp.eclipse.org/dsdp/tm/tcf/docs/TCF%20Getting%20Started.html#TcfLua http://www.lua.org/ Since it is somewhat awkward to handle asynchronous communications in bash, Lua seems to be a better approach.
What we have right now is an architecture with 3 main components. 1)We have created a plugin that integrates with the C agent called lttng-agent that publish a new service in TCF agent to be able to control and stream traces for LTTng and UST. 2)We have also created an Eclipse plugin to give user a great graphical interface for the LTTng service. 3)Since our tools is also targeted to system administrator we've created a plugin for the tcf client to be able to receive events when we are streaming a trace over the network and using the command line interface. This plugin adds a new command in the client called lttng-client. What we wanted with this new patch was to be able to provide a bash program to our users that would be very similar to what we have locally. So we need a script that will send different commands to the client depending of the command line arguments given to our script. I don't see any way to create a true program or script that require arguments with Lua. It is more isolated inside TCF, am I wrong? I also think that giving user another way to script the client is great. Many people aren't familiar with Lua but are familiar with bash or other scripting tools (python, ...) that could just send single commands to the client. What do you think?
Michael, I'm not suggesting to change your users workflow :) My comment was much smaller in scope. At the moment we have, at least, two possible ways to send a command to the agent from bash: 1) echo "connect <host>" >cmd.tmp echo "<command>" >>cmd.tmp tcf-client -S cmd.tmp 2) echo "<lua script>" >cmd.lua tcflua cmd.lua You proposing: 3) tcf-agent -h <host> -c <command> It see no problems with that - it is more elegant then #1. However, it is only a shortcut for #1, it does not provide new functionality. Problem is both #1 and #3 don't allow you to handle events, so it is still "impossible to ... make decision based on the output". To work around this, you proposing "-d" that allows "the client plugins that wait for events after a command to be able to receive them". This seems awkward: logic related to same command is spread between the script and client plugins. Instead, you could program without -d and have all related logic in one place - if you would be able to register call-backs in a script. Lua supports that. Python would work too. But I'm not sure about bash. Anyway, if you feel that -d is the way to go, I will commit it. Regards.
Ahah, I didn't wanted to blame you or something, I just wanted to explain better what we wanted to do. ;) You are right, #3 is only a shortcut for #1. In fact we can still make decision by piping the output of the client into awk of sed to extract information and by doing something different depending on the data. I agree with you that the workaround with "-d" is kind of a hack and not very elegant. Truth is, we only have one command that can generate events, the other are very simple. I guess the best way to do it would be to have a standalone TCF dynamic library. It would be great to be able to create a new program, include tcf, initialize the event loop and call a small and simple set of functions to communicate with the TCF protocol. This way one would be able to write a specialized client very easily without using the reference client. Is this plausible, realistic? We would still like to have the new way to send a command integrated while we find a better way to do it, if it's OK with you. Thanks Michael
(In reply to comment #5) > I guess the best way to do it would be to have a standalone TCF dynamic > library. It would be great to be able to create a new program, include tcf, > initialize the event loop and call a small and simple set of functions to > communicate with the TCF protocol. This way one would be able to write a > specialized client very easily without using the reference client. > > Is this plausible, realistic? The library does not have to be dynamic, a static library will work too. And the agent makefile already builds the library - libtcf.a. So, it is already entirely possible to create new programs using small and simple set of functions from the library. > > We would still like to have the new way to send a command integrated while we > find a better way to do it, if it's OK with you. I have committed the patch. Thanks!
Moving bugs to new home for IP log.
Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3
