You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to not be restricted to using a testbed file in my PyATS usage. The reason for this is because my environment is ephemeral. The connection details change from environment to environment. I personally would prefer not to create an intermediary script, and I suspect others would too, that writes the testbed script after ingesting local environment details. In my opinion a yaml testbed file is ideal for human to programmatic interaction, however a yaml testbed file is not ideal for environmental discovery and programmatic interaction. Such as workflow again in my opinion should remain in the python script. I also acknowledge the Netbox Plugin but it is simply not practical for local development environment.
Current Examples:
$ python>>>fromuniconimportConnection>>>dev=Connection(hostname='R1', start=['ssh admin@clab-bgp-R1'], credentials={'default': {'username': 'admin', 'password': 'admin'}}, os='iosxe')
>>> (omittedoutputforbrevity)
>>>>>>dev. # tab tab to expose auto-complete optionsDisplayall101possibilities? (yorn)
dev.acquire( dev.connection_typedev.guestshell( dev.logdev.parse_spawn_command( dev.release( dev.state_machine_class(
dev.add_service( dev.contextdev.hostnamedev.log_bufferdev.patch_service_attributes( dev.reload( dev.subcommand_list(
dev.aliasdev.copy( dev.init_config_commandsdev.log_file( dev.ping( dev.roledev.switchto(
(omittedoutputforbrevity)
>>># This object is missing methods from the other pyATS family of libraries such as "parsed" from Genie.
A Network Engineer is working on a proposed change to the infrastructure. They create a repository on their local, initialize git, use ansible for their configuration management, they also create a virtualization environment / orchestration tool definition yaml file, and now they need to write unit tests to prove their change is acceptable as well as providing the same test files that will move into production to allow for continuous testing of the new feature.
These inventory files, testbeds and etc. must survive being deployed into different environments.
Proposed experience of exposed unicon connection API
$ python>>>fromgenieimporttestbed>>>>>>testbed. # tab tab to expose auto-complete optionstestbed.Genie( testbed.load( testbed.unicon(
>>>>>>tb=testbed.unicon(hostname='R1', start=['ssh admin@clab-bgp-R1'], credentials={'default': {'username': 'admin', 'password': 'admin'}}, os='iosxe')
>>>r1=tb.devices['R1']
>>>r1.connect()
>>>r1.parsed('show ip int bri')
The text was updated successfully, but these errors were encountered:
As we currently not supporting, we will add to backlog for support as per priority of customer need to resolve the issue you are facing in future. If you need further assistance, please let me know and I'll do my best to provide additional guidance.
Feature Request
I would like to not be restricted to using a testbed file in my PyATS usage. The reason for this is because my environment is ephemeral. The connection details change from environment to environment. I personally would prefer not to create an intermediary script, and I suspect others would too, that writes the testbed script after ingesting local environment details. In my opinion a yaml testbed file is ideal for human to programmatic interaction, however a yaml testbed file is not ideal for environmental discovery and programmatic interaction. Such as workflow again in my opinion should remain in the python script. I also acknowledge the Netbox Plugin but it is simply not practical for local development environment.
Current Examples:
vs.
Story
A Network Engineer is working on a proposed change to the infrastructure. They create a repository on their local, initialize git, use ansible for their configuration management, they also create a virtualization environment / orchestration tool definition yaml file, and now they need to write unit tests to prove their change is acceptable as well as providing the same test files that will move into production to allow for continuous testing of the new feature.
These inventory files, testbeds and etc. must survive being deployed into different environments.
Proposed experience of exposed unicon connection API
The text was updated successfully, but these errors were encountered: