Replies: 2 comments
-
|
I totally agree it would be useful, but there are tons of hurdles. We could start with something minimal like using this provider means we're not doing any stuff. Even there:
The "only" problem with "minor code changes" is the exploding decision tree. Just look at how complex I did work on physical lab provisioning tools in the past, and the true problem is pushing initial device configurations and cleaning up device configs, in particular once the device gets bricked. That problem would have to be ignored (we're not building that product). Hybrid setup is a whole different can of worms. I'm thinking about mixing VMs with containers in libvirt; once I get that done we'd have at least the minimal multi-provider infrastructure in place. The gluing part needed to get the hybrid networking working is way beyond the scope of this tool though. To recap:
|
Beta Was this translation helpful? Give feedback.
-
|
Implemented in 'external' provider |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
It can be useful to validate a given topology using virtual nodes, and then apply the same configs to physical nodes.
This could be accomplished by having a 'physical' provider, which would assume there is a physical node reachable at the given management address. This provider would include the logic required to transfer generated configs to physical devices, and possibly the ability to build hybrid setups (mix of virtual and physical nodes)
Beta Was this translation helpful? Give feedback.
All reactions