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
Yeah, a much more flexible way to go about configuring Libvirtd, Qemu and others would be to model their configurations as Puppet hashes, i.e. key-value pairs that the respective template then processes.
Example for the libvirt::libvirtd_config parameter (which by default is an empty hash):
# /etc/libvirt/libvirtd.conf - This configuration file is managed by Puppet, do not edit.
<%- @libvirtd_config.sort.map do |param,val|-%>
<%= param %> = <%= val %>
<%- end -%>
The same pattern can be used for Debian's /etc/default/libvirt-bin or RHEL's sysconfig:
# Defaults for libvirt-bin initscript (/etc/init.d/libvirt-bin)
# This is a POSIX shell fragment
<%- @debian_defaults.sort.map do |variable,val|-%>
<%= variable %>="<%= val %>"
<%- end -%>
As for backwards-compatibility: we could check if, e.g., the libvirtd_config hash parameter in question is empty, and only if it is not empty process it and ignore all other class parameters pertaining to the Libvirt configuration (such as listen_tls, auth_tcp and so on).
it would be /way/ more convenient to pass two (four?) hashes to configure libvirtd, quemu, and their defaults (sysconfig) files.
This could be in a backwards compatible, or incompatible way, depending on our choosing / effort ;)
The text was updated successfully, but these errors were encountered: