HI Paul, You need to an init module to your package.
touch modules/network/ironware/__init__.py Peter On Sat, Sep 30, 2017 at 8:55 AM, Paul Baker <p...@paulbaker.id.au> wrote: > Hi Peter, > > Thanks for the guidance. I’ve made some progress but have hit a wall. > > When executing via a playbook I get the following error msg "provider > support not available for this host” > > Comparing the debug output to the asa_command module, it seems that module > calls out to the network_cli plugin to connect first, where my module seems > to launch straight into execution. I see there’s an action plugin for asa, > which i tried to replicate to no avail. Any idea what’s missing? > > Code is here if you wanted to see anything for yourself… > https://github.com/paulquack/ansible/tree/ironware-module > > TASK [ios_command] ****************************** > ************************************************************ > ************************************************************** > task path: /Users/paul.baker/playbook/ios.yml:7 > <bdr01.lab> using connection plugin network_cli > <bdr01.lab> socket_path: /Users/paul.baker/.ansible/pc/b2304e7e13 > Using module file /Users/paul.baker/ansible/lib/ > ansible/modules/network/ios/ios_command.py > … etc. > > Vs. > > TASK [ironware_command] ****************************** > ************************************************************ > ********************************************************* > task path: /Users/paul.baker/playbook/ironware.yml:7 > Using module file /Users/paul.baker/ansible/lib/ansible/modules/network/ > ironware/ironware_command.py > > > On 27 Sep 2017, at 11:29 am, pspry...@redhat.com wrote: > > HI Paul, > > Happy to have the contribution. There are are a number of pieces that > need to be developed in order to support a new network device. Based on > your message, the following is assumed to be using a CLI based connection > (as opposed to say NetConf). > > 1) The device os will need a terminal plugin. Terminal plugins control > aspects of the CLI shell. Things like privilege escalation (enable mode) > or terminal line settings are types of things you add to this file. There > is a terminal plugin for each supported network CLI device and can be found > in plugins/terminal. Of the key items here is the prompt handling and > recognition. Of particular note is implementing the instance variables > terminal_stdout_re and terminal_stderr_re. These lists are regular > expressions that are used to introspect the stream data to determine when > data has completed and if any errors were encountered. If the Brocade CLI > maps close enough to Cisco IOS, you might be able to use the terminal > instance variables found in plugins/terminal/ios.py as a starting point. > > 2) The device os will need a cliconf plugin as well. Cliconf plugins > provide an implementation for sending and receiving basic commands with the > device. For instance executing commands (show command, ping, etc) using > the get() method. The get_config() and edit_config() methods are > responsible for working with the configuration file, setting up CLI context > etc. Finally, the get_capabilities() method is important as it returns > basic device information for us in modules such as version information and > supported RPC endpoints. Again I will direct you to any of the cliconf > plugins as examples (plugin/cliconf). I'm presently documenting this > plugin to try to keep consistency across implementations so more to come > very shortly. > > 3) Once you have 1 and 2 done, the next step is to write your modules for > command, config, facts, etc. Here I will direct you to looking at the ASA > modules as they are the only ones (as of 2.4) converted to using cliconf. > We are transitioning the other modules in this release cycle. Take a look > at modules/network/asa/asa_command.py and modules/network/asa/asa_config.py > and their shared library module_utils/asa.py. They will give you good > indiciations as to how to implement your modules to take advantage of the > network_cli connection plugin. > > Note on naming schemes, we keep network modules named for their OS not the > vendor (ios_ not cisco_ etc). Please follow the same naming scheme. > > Unfortunately I have only scratched the surface here but hopefully its > enough to get you started. I would highly recommend you come out to the > #ansible-network channel on Freenode IRC and chat with us. You can find me > out there under the nick privateip. We will be more than happy to help > walk you through this and answer any and all questions you might have. > > Regards, > Peter > > > On Tuesday, September 26, 2017 at 7:45:15 AM UTC-4, Paul Baker wrote: >> >> Hi Team, >> >> I'm interested in developing command/config/facts modules for Brocade >> Ironware routers. The CLI is very Ciscoish so I'm thinking it should not >> take too much effort. I started this a while back on release 2.1 but things >> have changed a lot recently. Anyone here that might be able to point me in >> the right direction? >> >> Thanks >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Development" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/ansible-devel/TVe1HLYh4s8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > ansible-devel+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
