Interactive commands
84 views
Skip to first unread message
Thomas Quinot
Nov 17, 2014, 12:05:48 PM11/17/14
to ansible...@googlegroups.com
Redirecting from -devel as advised...
On Thu, Nov 13, 2014 at 2:27 PM, Thomas Quinot <tho...@quinot.org> wrote:
> I am considering managing some network equipment (switches) with the
> 'raw' module. This requires sending commands to the switch in an
> interactive session (command streamed before receiving the switch's
> prompt are ignored), performing successive 'wait for prompt/send
> command' steps [over a 'raw' ssh session]. Is there any existing support
> for such interactive processing (generalizing the circuitry providing
> optional stdin data)? If not, would there be interest in it?
(I am willing to prototype this if that's of interest).
> I guess this could apply to the 'raw', but also possibly 'shell' and
> 'command' modules.
Thomas.
On Thu, Nov 13, 2014 at 2:27 PM, Thomas Quinot <tho...@quinot.org> wrote:
> I am considering managing some network equipment (switches) with the
> 'raw' module. This requires sending commands to the switch in an
> interactive session (command streamed before receiving the switch's
> prompt are ignored), performing successive 'wait for prompt/send
> command' steps [over a 'raw' ssh session]. Is there any existing support
> for such interactive processing (generalizing the circuitry providing
> optional stdin data)? If not, would there be interest in it?
(I am willing to prototype this if that's of interest).
> I guess this could apply to the 'raw', but also possibly 'shell' and
> 'command' modules.
Thomas.
Michael DeHaan
Nov 17, 2014, 3:29:42 PM11/17/14
to ansible...@googlegroups.com
Basically this isn't going to end well.
The 'raw' module is useful for sending to devices that look like Unix shells, but some things are too weird to work this way.
The 'raw' module is useful for sending to devices that look like Unix shells, but some things are too weird to work this way.
The right way to go with Cisco is going to be to get modules speaking to OnePK or NXOS APIs - similar to what has happened with Juniper or Arista. (things like Cumulus don't need them, because it's got a real SSH environment we can use like Linux).
In any case, I don't want to go down the 'parse CLI' path for Cisco, and we're in touch with Cisco about modules for Ansible -- but it's been slow going.
If this is something people would like to work on instead, I'd be quite interested.
They should strive for something close to what the Juniper and Arista modules can do, I'd think.
Thomas.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20141114205932.GB98767%40melamine.cuivre.fr.eu.org.
For more options, visit https://groups.google.com/d/optout.
Thomas Quinot
Nov 18, 2014, 5:02:23 AM11/18/14
to ansible...@googlegroups.com
* Michael DeHaan, 2014-11-17 :
> Basically this isn't going to end well.
Can you elaborate?
> The 'raw' module is useful for sending to devices that look like Unix
> shells, but some things are too weird to work this way.
Right, hence the proposal to extend it to offer a chat-script-style
facility.
> The right way to go with Cisco is going to be to get modules speaking to
> OnePK or NXOS APIs - similar to what has happened with Juniper or Arista.
> (things like Cumulus don't need them, because it's got a real SSH
> environment we can use like Linux).
>
> In any case, I don't want to go down the 'parse CLI' path for Cisco, and
> we're in touch with Cisco about modules for Ansible -- but it's been slow
> going.
We're not talking Cisco hardware here but Brocade switches, and various
other devices with limited interactive access over SSH. This is for very
specialized cases, and I doubt it would be worthwhile to create a
specific module for each such niche device.
Thomas.
> Basically this isn't going to end well.
> The 'raw' module is useful for sending to devices that look like Unix
> shells, but some things are too weird to work this way.
facility.
> The right way to go with Cisco is going to be to get modules speaking to
> OnePK or NXOS APIs - similar to what has happened with Juniper or Arista.
> (things like Cumulus don't need them, because it's got a real SSH
> environment we can use like Linux).
>
> In any case, I don't want to go down the 'parse CLI' path for Cisco, and
> we're in touch with Cisco about modules for Ansible -- but it's been slow
> going.
other devices with limited interactive access over SSH. This is for very
specialized cases, and I doubt it would be worthwhile to create a
specific module for each such niche device.
Thomas.
Reply all
Reply to author
Forward
0 new messages