Python salt cloudclient is not logging anything - python

I am trying to create new nodes using the CloudClient in saltstack python API. Nodes are created successfully but I don't see any logging happening. Below is the code which I am using.
from salt.cloud import CloudClient
cloud_client = CloudClient()
kwargs = {'parallel': True}
cloud_client.map_run(path="mymap.map",**kwargs)
Is there way to run the same code in debug mode to see the output on console from this python script if logging cannot be done.
logging parameters in cloud
log_level: all
log_level_logfile: all
log_file: /var/logs/salt.log
When I try to run with sal-cloud on cli it is working with the below command:
salt-cloud -m mymap.map -P

I was able make it work by adding the below code
from salt.log.setup import setup_console_logger
setup_console_logger(log_level='debug')

Related

Redirecting output of launchfile called from Python

I have a simple piece of code which runs a specified launchfile:
roslaunch.configure_logging(uuid)
uuid = roslaunch.rlutil.get_or_generate_uuid(None, False)
file = [(roslaunch.rlutil.resolve_launch_arguments(cli)[0], cli[2:])]
launch = roslaunch.parent.ROSLaunchParent(uuid, file)
Execution of the launchfile stuff generates lots of logging output on stdout/err, so the actual script's output is getting lost.
Is it possible to somehow redirect or disable printing it on the screen?
Two options:
via env vars (export).
via python logging module.
Using env vars
You can set ROS logging to a /dev/null like file system.
See ROS env vars: https://wiki.ros.org/ROS/EnvironmentVariables
export ROS_LOG_DIR=/black/hole
Use https://github.com/abbbi/nullfsvfs to create the dir.
Using python logging
import logging
logging.getLogger("rospy").setLevel(logging.CRITICAL)
https://docs.python.org/3/library/logging.html#logging-levels
How about redirecting stdout and stderr to files? As long as you redirect them before your calls to roslaunch it should put all the output into the files you point to (or /dev/null to ignore it).
import sys
sys.stdout = open('redirect.out','w')
sys.stderr = open('redirect.err','w')

Docker-compose with python command handler

I am trying to the python cmd library in combination with docker.
This is my minimal command class setup.
class Commands(cmd.Cmd):
intro = 'Welcome to the shell.\nType help or ? to list commands.\n'
prompt = 'Shell: '
#staticmethod
def do_stop(arg):
"""
Stops the servers gracefully
:param arg:
:return:
"""
logger.info("Stopping server...")
# Do stuff
If I start the app without docker, the shell is just working fine. I can interact with it, without issues. However, if I use docker-compose up I get an endless loop of error messages, like in the image below.
My application main.py looks like the following:
if __name__ == "__main__":
Commands().cmdloop()
Why is docker complaining about an unknown syntax? is something writing to the stdout or stderr, I am not aware of?
Using:
stdin_open: true
in the docker compose file, will fix the issue.

Making the log.html more verbose when using the API

I am attempting to use the API for building and running test suites and I've noticed that the log.html that is output when using the API vs the shell is subtly different.
The log when using the command line invocation
The log when run through a minimal python script
The minimal python script:
import robot.api
import robot.result
from robot.conf.settings import RobotSettings
options = {
"output": "./results.xml",
"log": "./log.html",
"report": "./report.html",
"loglevel": "TRACE"
}
settings = RobotSettings(options)
suite = robot.api.TestSuiteBuilder().build(".")
result = suite.run(settings=settings)
result_writer = robot.api.ResultWriter(result)
result_writer.write_results(settings=settings.get_rebot_settings())
As can be seen the log is missing a lot of keyword detail, how can I get this back?
edit: The minimal file after changing it to the correct method:
import robot.api
import robot.result
from robot.conf.settings import RobotSettings
options = {
"output": "./results.xml",
"log": "./log.html",
"report": "./report.html",
"loglevel": "TRACE",
"rpa": False
}
settings = RobotSettings(options)
suite = robot.api.TestSuiteBuilder().build(".")
result = suite.run(settings=settings)
result_writer = robot.api.ResultWriter("./results.xml")
result_writer.write_results(settings=settings.get_rebot_settings())
Are you sure you don't have two different Robot Framework packages active on your system? One externally in your path and another as a package within your venv.
Try
robot --version
and check if the version in your cmd line is the same as the one running the script.
You should also try to upgrade to the latest version, which typically solves such errors.
I have also found a similar error on this thread, which states
The problem is that the result object you get from
suite.run(settings) doesn't contain all information about test
execution. The reason for this behavior is saving memory during test
execution. All information about the execution is in the generated
output.xml file, and what you need to do is passing a path to it to
the ResultWriter class instead of the result object. This ought to
be documented somewhere in the API docs but I'm not sure about it.

Mininet Python API - CLI Class

I am having trouble understanding how to use to class properly. Calling the class constructor without a script automatically runs the CLI in interactive mode. Therefore you need to manually exit interactive mode to obtain the class instance. Only then can you call the class methods using said instance. This seems very strange.
What I am trying to do is write a program which configures the network and then opens several xterm windows on separate nodes and launches an application inside them. Is this possible?
Edit:
For example something like the following:
#!/usr/bin/python
from mininet.net import Mininet
from mininet.log import setLogLevel
from mininet.cli import CLI
from mininet.topolib import TreeTopo
def test():
"Create and test a simple network"
net = Mininet(TreeTopo(depth=2,fanout=2))
net.start()
cli = CLI(net)
CLI.do_xterm(cli, "h1 h2")
net.stop()
if __name__ == '__main__':
setLogLevel('info')
test()
Calling the CLI class constructor in order to obtain the class instance automatically launches mininet in interactive mode. This needs to be manually exited before the call to the do_xterm method can be envoked on the class instance.
I suppose a CLI is made to be used on stdin, so making use of scripting instead of programmatic manipulation of the CLI makes some sense.
If you want to obtain a reference to the cli object without interactive mode, you could make a workaround by creating an empty text file called "null_script" and then calling
cli = CLI(net, script='null_script')
Your real goal seems to be to programatically open xterms and have them run applications. Since you don't give a reason why you can't use scripts I propose a solution that uses a script. Put the following in a text file:
py h1.cmd('screen -dmS mininet.h1')
sh xterm -title Node:h1 -e screen -D -RR -S mininet.h1 &
sh screen -x -S mininet.h1 -X stuff 'ls'`echo '\015'`
Using this text file as a script in the cli works for me both using the 'source' command on CLI and by passing the filename into 'sript='.
I took the command arguments from the makeTerm function in term.py, and the screen stuff arguments from an answer on superuser. Just replace 'ls' with the name of the application you want to run.
Each screen you are trying to attach to needs to have a unique name, otherwise you will get a message listing the matching names and you will have to specify a pid for the correct session, which would complicate things.

Odoo - how to use it interactively in python interpreter?

I read here that it might be possible to use python interpreter to access Odoo and test things interactively (https://www.odoo.com/forum/help-1/question/how-to-get-a-python-shell-with-the-odoo-environment-54096), but doing this in terminal:
ipython
import sys
import openerp
sys.argv = ['', '--addons-path=~/my-path/addons', '--xmlrpc-port=8067', '--log-level=debug', '-d test',]
openerp.cli.main()
it starts Odoo server, but I can't write anything in that terminal tab to use it interactively. If for example I write anything like print 'abc', I don't get any output. Am I missing something here?
Sometime I use "logging" library for print output on the console/terminal.
For example:
import logging
logging.info('Here is your message')
logging.warning('Here is your message')
For more details, You may checkout this reference link.
The closest thing I have found to interactive is put the line
import pdb; pdb.set_trace()
in the method I want to inspect, and then trigger that method.
It's clunky, but it works.
As an example, I was just enhancing the OpenChatter implementation for our copy of OpenERP, and during the "figure things out" stage I had that line in .../addons/mail/mail_thread.py::mail_thread.post_message so I could get a better idea of what was happening in that method.
The correct way to do this is with shell:
./odoo-bin shell -d <yourdatabase>
Please, be aware that if you already have an instance of odoo, the port will be busy. In that case, the instance you are opening should be using a different port. So the command should be something like this:
./odoo-bin shell --xmlrpc-port=8888 -d <yourdatabase>
But if you want to have your addons available in the new instance, yo can make something similar to the following:
./odoo-bin shell -c ~/odooshell.conf -d <yourdatabase>
This way you can have in your odooshell.conf whatever you need to have configured (port, addons_path, etc). This way you can work smoothly with your shell.
As I always use docker, this is what I do to have my shell configured in docker:
docker exec -ti <mycontainer> odoo shell -c /etc/odoo/odooshell.conf -d <mydatabase>
You will have the env available to do anything. You can create express python code to make whatever you need. The syntax is very similar to server actions. For example:
partner_ids = env['res.partner'].search([])
for partner in partner_ids:
partner['name'] = partner.name + '.'
env.cr.commit()
Remember to env.cr.commit() if you make any data change.

Categories

Resources