cancel
Showing results for 
Search instead for 
Did you mean: 

Can't import api from exos

Can't import api from exos

Mirco
New Contributor
Hey everybody!

I'm working on a project with an Extreme Networks Summit X440-8p running firmware-version 16.1.1.4. I want to write a python script, but I'm stuck at the beginning.

The Python Scripting Guide (http://www.extremenetworks.com/wp-content/uploads/2015/02/Python_Getting_Started_Guide.pdf) tells me I have to import api from exos with the following line:

"from exos import api"

Unfortunately, every time I want to execute my script (which just has a print command at the moment), there's an error:

"* X440-8p.81 # run script print_test
Traceback (most recent call last):
File "/config/print_test.py", line 1, in
from exos import api
File "/exos/tools/lib/python2.7/site-packages/exos/api/__init__.py", line 21, in
File "/exos/tools/lib/python2.7/site-packages/exos/api/ems.py", line 10, in
ImportError: No module named _exos_ext_ems".

What am I doing wrong? It's exactly how the scripting guide tells me to import the api. This site tells me the same: http://documentation.extremenetworks.com/python/

Has anything changed since it looks like this site is for software-version 15.7.1 whereas I'm running 16.1.1.4?

Thanks in advance!
Mirco
22 REPLIES 22

Hi Mirco,
We don't have anything like a field by field description.
The relationship of what a CLI displays and the raw data that went into it is easier to see with:

run script cli2json.py -d .

This built in script gives the CLI output and any data that was used to create the CLI for a visual mapping.
There are hundreds of CLI commands, if you have a few that you are using, I could ask the engineers for an explanation of the fields that you have questions about.
DaveH

Mirco
New Contributor
Hi Dave,

thanks a lot for your great support! Since my partner already worked on the XML-capturing, we're going for the way to connect to the switch via telnet and run the script periodically.

But I have another question: The XML-output contains a lot of information and we don't know what every piece of the information means. Is there anything like a reference guide where we can look up what information is contained in the XML-output of specific commands?

Thanks again 🙂
Mirco

I have one other idea. There is a script included with EXOS: cli2json.py.

This script runs any EXOS command, captures the XML and converts it to JSON.

JSON may be easier to process since python has simple conversion routines that converts JSON to/from dictionaries/lists.

From the app environment, spawn an EXOS shell to run the cli2json.py script with the desired CLI command and collect the data in JSON. An example python snippet is below.

You can run cli2json.py from the cli prompt to see what kind of information a show command will give you before including it in a script. My recommendation is to run it from a telnet session instead of the console since it can display a lot of data and console speeds are slow.

Be sure to use the -d when running it from a CLI prompt so the output is human readable.

It is important not to use the 'auto refresh' capabilities of some of the EXOS commands. E.g. show ports will display a list of ports and refresh it on the screen. If it is called from cli2json.py, the script will never return.

The cli2json.py JSON output also has a variable CLIoutput which contains what the actual CLI display would have been for the command. This way you get the formatted output as well as the data structures that were used to create the display

The non-refreshing format of that command would look like: show ports no-refresh

From a CLI prompt: run script cli2json.py -d

E.g.

run script cli2json.py -d show port 1-2 statistics no-refresh
[
{
"CLIoutput": "Port Link Tx Pkt Tx Byte Rx Pkt Rx Byte Rx Pkt Rx Pkt Tx Pkt Tx Pkt\n State Count Count Count Count Bcast Mcast Bcast Mcast\n========= ===== =========== =========== =========== =========== =========== =========== =========== ===========\n1 A 128 22980 128 22599 0 65 0 63\n2 R 0 0 0 0 0 0 0 0\n========= ===== =========== =========== =========== =========== =========== =========== =========== ===========\n > in Port indicates Port Display Name truncated past 8 characters\n > in Count indicates value exceeds column width. Use 'wide' option or '0' to clear.\n Link State: A-Active, R-Ready, NP-Port Not Present, L-Loopback\n"
},
{
"show_ports_stats": {
"dot1dTpPortInDiscards": 0,
"dot1dTpPortInFrames": 128,
"dot1dTpPortMaxInfo": 1500,
"dot1dTpPortOutFrames": 128,
"linkState": 1,
"port": 1,
"portList": "1-2",
"portNoSnmp": 1,
"rxBcast": 0,
"rxByteCnt": 22599,
"rxMcast": 65,
"rxPktCnt": 128,
"txBcast": 0,
"txByteCnt": 22980,
"txMcast": 63,
"txPktCnt": 128
},
"status": "MORE"
},
{
"show_ports_stats": {
"dot1dTpPortInDiscards": 0,
"dot1dTpPortInFrames": 0,
"dot1dTpPortMaxInfo": 1500,
"dot1dTpPortOutFrames": 0,
"linkState": 0,
"port": 2,
"portList": "1-2",
"portNoSnmp": 2,
"rxBcast": 0,
"rxByteCnt": 0,
"rxMcast": 0,
"rxPktCnt": 0,
"txBcast": 0,
"txByteCnt": 0,
"txMcast": 0,
"txPktCnt": 0
},
"status": "SUCCESS"
}
]



Now for the scripting part.

Spawning an EXOS shell from inside the app environment enables the app to run the cli2json.py script and collect the JSON formatted result.

import subprocess
import json

def exos2json(cmd):
JSONERROR = 'error'
shellCmd = '/exos/bin/exsh -n 0 -b -c "run script cli2json.py {0}"'.format(cmd)
p = subprocess.Popen([shellCmd], shell=True,
stdin = subprocess.PIPE,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE)
(stdoutdata, stderrdata) = p.communicate()
try:
jsonData = json.loads(stdoutdata)
except:
jsonData = {JSONERROR:'error processing command {0}'.format(cmd)}
return jsonData

#example calling an EXOS show command

jsonData = exos2json('show ports 1 statistics no-refresh')
print json.dumps(jsonData, sort_keys=True, indent=2)

[
{
"CLIoutput": "Port Link Tx Pkt Tx Byte Rx Pkt Rx Byte Rx Pkt Rx Pkt Tx Pkt Tx Pkt\n State Count Count Count Count Bcast Mcast Bcast Mcast\n========= ===== =========== =========== =========== =========== =========== =========== =========== ===========\n1 A 147 26426 147 26036 0 74 0 72\n========= ===== =========== =========== =========== =========== =========== =========== =========== ===========\n > in Port indicates Port Display Name truncated past 8 characters\n > in Count indicates value exceeds column width. Use 'wide' option or '0' to clear.\n Link State: A-Active, R-Ready, NP-Port Not Present, L-Loopback\n"
},
{
"show_ports_stats": {
"dot1dTpPortInDiscards": 0,
"dot1dTpPortInFrames": 147,
"dot1dTpPortMaxInfo": 1500,
"dot1dTpPortOutFrames": 147,
"linkState": 1,
"port": 1,
"portList": 1,
"portNoSnmp": 1,
"rxBcast": 0,
"rxByteCnt": 26036,
"rxMcast": 74,
"rxPktCnt": 147,
"txBcast": 0,
"txByteCnt": 26426,
"txMcast": 72,
"txPktCnt": 147
},
"status": "SUCCESS"
}
]

Mirco
New Contributor
Hi Dave, thanks for your suggestion!

I thought about it, but unfortunately, this won't help us 

Here's what we're trying to achieve:
We want to write two python apps. The first one should run on the switch and collect specific data like avb status, stream information and so on.

The second app should run on a PC and connect to the app that's running on the switch to get the collected data and display it for monitoring purposes.
This should be possible in the app-environment with socket-programming, right?

We know, there are already monitoring tools which we could use, but we want to write our own app to adapt it exactly to our needs.

But you say there's no way to get XML-formatted data in the app-environment? That would be too bad 😞

If that's the case, the only way I can think of is the following: connect our monitoring-app to the switch via telnet, run a script, let's say every 30 seconds, and capture the XML-output.
That wouldn't be as nice as a native app on the switch, but it should work, right?

If you have any other ideas, please let me know! (a way to get XML-formatted data in the app-environment would be great ;))

Thanks a lot for your great support!

To run a periodic script using the 'run script' python environment, I would suggest using the EXOS UPM capability. This would allow capturing the XML information in the script. The script will be started by UPM and runs to completion each time. It also simplifies the script a bit by letting UPM determine when, and how often, the script should run. It would also be possible to enter 'run script
GTM-P2G8KFN