puppet-libvirt
puppet-libvirt copied to clipboard
Network type and provider
This is an alternative to #25 using the libvirt api instead of shelling out to virsh, and maintains the current resource definition interface. This only a demonstartion at this point, to be useable it would require converting the settings to properties. It also lacks working tests.
i think i'd leave the defined type in for now, and replace its guts with a call to the type. that way we may be able to reuse the tests, maybe…
I think keeping the defined type will only increase the complexity with the added layers. The current tests in spec/defines/network_spec.rb are checking that defining a resource produses an exec resource with the correct command, so they couldn't be used as is.
I think the curent state should sufice to show the design for the provider. Although this will only update the stored config so the network would need to restarted to affect the running config. The main issue now is the lack of tests to ensure there are no regressions with this. Is there likly to be any movement on #33 in the near future?
@jaggededgedjustice i haven't had any time :(mostly due to my involvement in @puppet-community): but i hope @thias comes around to reviewing / merging this one here
This is great! It looks like the same code could be used to manage non-libvirt interfaces too, like https://github.com/raphink/puppet-netcf
@beddari most likely, since libvirt makes use of netcf internally.
@jaggededgedjustice do you have any opinions on @beddari's and @raphink's comments? otherwise, a good (re)start for this Pull Request would be a rebase.
@beddari, It might be possible, I've never encountered netcf before. Although the config schema for netcf and libvirt looks much the same there are some differences, such as the open vswitch ports that libvirt has which netcf does not. It may be possible to share the code for parsing the current state of a resource between this project and pupet-netcf. But maybe not, libvirt has its own config parser/generator which is used internally, so although the two schemas look the same they might be different enough that sharing code is pointless. Though it would be worth looking into in the future.
@jaggededgedjustice do you wanna pick this up again and rebase it? if you don't, i'll do it :P
I'm hoping to be able to get the rebase done this weekend, RL has been conspiring against me recently.
k, rebase done
superb. I'll try rewrite the unit tests next week.
@thias ping / merge :D