Python LXC api needs to be much better at error reporting

[Christopher Townsend]

I use the Python API extensively on the lp:libertine project. However, when there is an error somewhere in the LXC layer, the only thing that is returned is False which is not very useful when trying to figure out what has gone wrong.

For example, I try to use the Container.create() method and it is failing However, when I try using the lxc-create CLI tool using the same exact parameters, it works. Since the Python API does not have an error output, I'm having a very difficult time figuring out why the Python create is failing.

[Serge Hallyn (serge-hallyn)]

Hi,

the intent is that you can set the logfile and loglevel and find
out more about how it failed for those. While there is talk about
work to improve on the startup failure debugging, it is still
based on the logfile output.

As an example:

^C2 ✗ serge@sl ~ $ python3
Python 3.4.3+ (default, Oct 14 2015, 16:03:50)
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxc
>>> c=lxc.Container("x1")
>>> c.set_config_item("lxc.loglevel", "1")
True
>>> c.set_config_item("lxc.logfile", "/tmp/outout")
True
>>> c.start()
False

but now /tmp/outout has the debug information.

It sounds like we could stand to have this better explained
somewhere, but I'm not sure where.

[Christopher Townsend (townsend)]

Ok, thanks, that might work.

I will have to think on how best to parse the log file for any error messages that are only applicable to the actual LXC Python API call the application is executing and pass these error messages back to the user and present them in a meaningful manner.

[Serge Hallyn (serge-hallyn)]

Thanks, if it turns out there is more that lxc could do please do reply here or open a github issue.

Doing more in the C api woudl be tough, as we'd presumably need to allocate memory for the error msg which the caller would need to free.

Returning more in the python API could be doable if it could control the lxc.logfile and present the output after a failure, but since the caller may want to set those himself it's not so simple.

Not sure what to do with the status of this bug. If we re-title it general failure logging improvements then it definately could be Confirmed. Otherwise it may be Invalid, not sure. Either way, marking Wishlist for now.