Replies: 3 comments
-
Perhaps we could introduce a device type 'unmanaged' which gets ignored (i.e. does not trigger errors about unsupported modules)? |
Beta Was this translation helpful? Give feedback.
-
none was a bogus device that I needed in test cases. It is not used in any CI tests and it doesn't matter which modules it supports ;) If you want to use it to model external devices, then I agree with @jbemmel that it should be renamed to unmanaged, support all modules, and use the tasks/deploy-config/unmanaged.yml task list that would do nothing (or maybe print a message saying not doing this). There's still the question of netlab initial -o which would have to skip it (maybe we can add the test that netlab_device_type is non-empty (or some such), and the virtualbox/libvirt/clab templates that would have to skip it. Any takers? BTW, this should go into 1.4. |
Beta Was this translation helpful? Give feedback.
-
I'm taking this, tracking on a specific "issue" (#547). |
Beta Was this translation helpful? Give feedback.
-
I have a setup when I want netlab to take care of some network gear equipment config (using the external provider), but at the same time I need to establish peerings with their counterparts which should not be configured by netlab.
(i.e. configure a BGP session on a device controlled by netlab)
I was thinking to use the none device type for that kind of stuff, with sth like:
(for this specific example, I need pe1 to have two configured bgp sessions towards 10.211.211.11 and 10.211.211.12.)
But unfortunately the none device does not support vlan, vrf, and bgp.
Do you think it would be a good idea to allow the none device type to support all modules,
or should I use a real platform on all the devices, and the rely on a group of configurable devices to limit the ansible config with
-l group
?Beta Was this translation helpful? Give feedback.
All reactions