API, Python or other way to check command syntax and ability to execute

[Tomasz]

Hello,

I'm about to do some initial steps with Python for EXOS. I want to write kind of an intermediate shell that would work on user input (CLI commands) before ultimate execution.
Walked through Python Getting Started Guide (some old PDF) and the API reference (https://api.extremenetworks.com/EXOS/ProgramInterfaces/PYTHONAPI/) but I've no idea if I can achieve some ready-to-go syntax check (e.g. 'crete veelan Data tag 20') and validity check (e.g. 'conf vlan Data add port 20 tagged' when Data doesn't exist), or should I attempt to create these checks from the scratch. Would CM Backend be useful here?

Kind regards,
Tomasz

[Tomasz]

Oops, I wanted to like your post but when one posts a thread there is 'Answer' in place... But it's a good answer indeed! 🙂
With rollback dictionary I thought we would have to rely on enable/disable add/delete, but with some exceptions manually treated with higher precedence than generic inversion rules, e.g.:

code:

if: enable sharing X grouping (whatever)
then: disable sharing X

It will get even more funny with some examples but once you see this working... 😉

Kind regards,
Tomasz

P.S. @Drew C., can we revert the topic from 'answered' state, please? 

[AdrianO · Accepted solution]

If you have your current config as rollback.xsf, it might not necessarily roll things back. If your config.xsf had "create vlan Data tag 20" and your rollback.xsf doesn't, it will not remove the vlan Data. With that in mind you could do.

You're right. It would reapply the rollback config but wouldn't unconfigure anything.

Check command syntax (e.g. 'cerate veelan Data'), most likely right at the time of being provided by user
Check command validity

To do this right for the full command catalog it would require a lexical, syntactic and semantic analyzers. Additionally we would have to update them with changes in commands. I dont want to be the party popper but its a huge undertaking. Maybe we can leverage the capacity in the OS of the switch to do this somehow.

Engine that will create contrary commands for a rollback, seems to be massive pain in the bottom but least complicated.

Maybe this is more approachable thanks to the configure/unconfigure, add/delete, etc structure, although I think that not always you can substitute one for the other for rollback, like in:

enable sharing 1:1 grouping 1:1 lacp
disable sharing 1:1 grouping 1:1 lacp -> its not correct

I don´t think I have so much free time, but I could collaborate on some parts maybe. If someone from extreme sees this and can push for it with the engineers it can be a feature request. I really think that it should be a integrated feature in exos, but I dont know if it is feasible with scripts or the best way is integration in exos.

Great thread by the way.

[Tomasz]

Hi Adrian,

If you have your current config as rollback.xsf, it might not necessarily roll things back. If your config.xsf had "create vlan Data tag 20" and your rollback.xsf doesn't, it will not remove the vlan Data. With that in mind you could do:

code:

1. If 'commit confirmed' (or let's say 'commit ack' 😉 )
1.a. save config as rollback.cfg
1.b. load script config.xsf
1.c. sleep(timeout)
1.d. use configuration rollback.cfg
1.e. reboot

It could also be default.xsf created from current pre-commit config, so once the switch went unconfigured it would load the older config. But both approaches require a reboot, so I thought of something different.

I wanted to create a script that is a 'shell' which collects the commands.

code:

1. If 'show*' -> pass the command to the CLI immediately
2. If another user input -> add to a list of commands to execute
3. If 'commit' -> execute all commands (flush the buffer)
4. If 'commit ack [min]':
4.a. Build contrary config for each user input command
4.b. Execute all commands (flush the buffer)
4.c. Timer set to [min]
4.d. If commit then stop the timer, save config and clear the rollback commands buffer
4.e. If timer expires issue contrary commands (flush the rollback buffer)

Things to overcome with some effort:

1. Check command syntax (e.g. 'cerate veelan Data'), most likely right at the time of being provided by user - here is where I wanted to rely on EXOS Python library, otherwise would have to build some kind of command library and some smart checks (never done that before  ).
2. Check command validity (e.g. 'configure vlan Nonexistent add port 1 tagged) - gotta check not only the existing config but also the ones that are already in the pre-commit buffer as the VLAN might not be in the config but the user just ordered to create it and will commit alongside. In the example it would have to parse the config and the buffer to see if there is 'create vlan Nonexistent tag *'. Hmm... this would also be nice to check right at the time of user input.
3. Engine that will create contrary commands for a rollback, seems to be massive pain in the bottom but least complicated.

Kind regards,
Tomasz

[AdrianO]

Hi guys,

I´ve thinking about something like this too, the same behavior as in JunOS. Roughly I think we need:

1. A script "commit_confirmed" that takes two arguments: timeout to automatic rollback and the configuration file (config.xsf) to apply . This script would do:

code:

 save config as rollback.xsf

 load script config.xsf

 sleep(timeout)

 load script rollback.xsf

2. A script "commit" witch would find the process started by the "commit_confirmed" script and stop it while it is sleeping, effectively canceling the rollback.

The are nuances and enhancements to this but I think this could work, its something to start. What do you think?

We can do more: a "commit_check" for syntax, a "commit_at" for scheduled, log messages for each step (even with commit messages)...