Description of problem: If you have a pre-existing cluster and you add a new host, it gets default values for conf files (vdsm.conf, multipath.conf, ecc..) Version-Release number of selected component (if applicable): 4.1.0 How reproducible: Steps to Reproduce: 1. Add new host to existing infrastructure 2. Verify its settings 3. vdsm.conf is default and no sync with /etc/vdsm/vdsm.conf.d entries Actual results: host has to be manually aligned with pre-existing ones Expected results: automatic alignment or proposal of alignment of some files like vdsm.conf and multipath.conf Additional info:
So essentially, a vdsm.conf per cluster?
I think host in a cluster are tightly connected, so it would be nice to have a sort of sync. Or eventually some tool, initiated from inside the web admin gui that is able to crosscheck the config of the hosts and notify about discrepancy between config of the hosts...
I don't think we need to sync vdsm configuration, this will disable the option to have different configuration on one host. What we need is to manage the configuration in engine, and when adding a new host install the cluster configuration in /etc/vdsm.conf.d/50_cluster.conf. A system administrator can override settings on particular host by having /etc/vdsm/vdsm.conf.d/99_my_cluster.conf file (conf file are sorted and last settings wins). This configuration can be stored when adding or reinstalling a host, we already do this for the pki files, why not for vdsm configuration? Same solution will also solve multipath and lvm configuration, done now by vdsm-tool configure step.
This all sounds very suitable for Ansible. We should perhaps pack it with our Ansible modules and have it so users will be able to easily use it. Ondra, thoughts?
This can be solved very easily with simple playbook and using 'ovirt-engine-hosts-ansible-inventory'. Do we want to integrate it with webadmin, or is using ansible from command line sufficient?
Adding a host to a cluster is a core feature of the system, user may expect that using engine to add a host does everything needed without running a separate command line tool to complete the task.
If there is a need for engine-defined configuration to be applied to cluster or group of hosts - it should be a regular property sent by regular API channels. Either extend the API with new parameter or use existing spec params or custom properties.
That was discussed in the past, and the decision was not to sync vdsm.conf and other host configuration files. This won't be done out of the box within the engine. There were some ideas here, Gianluca, I think ansible was the easier one, but any configuration management tool can be used to set this up. Foreman as well, for example. I'm closing this as wontfix. If you need help with ansible, use the mailing list and we'll be happy to help.