Ok, so I guess I misread. VDSM should have that responsibility and engine should not be evolved. I like the suggestion from other in the thread on managing the admin custom rules via Ansible and the inventory playbook we have already created. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary On Wed, Mar 29, 2017 at 9:53 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <ydary@redhat.com> wrote:
Hi, I like option number 3 the most from reading the comments. We are not a configuration management system, so custom rules should not be a main consideration. VDSM should probably enable the firewalld rules it needs to work and engine should not care about firewall at all. A user wanting to add more rules then this should probably use the ones planned in: https://github.com/cockpit-project/system-api-roles
I, too, like the idea of shedding off the attempt to configure custom iptables rules. Moving to firewalld makes it much easier to manage such customization out of oVirt. (Anybody who's ever edited iptables chains by hand would know what I mean)
Please note that what you describe is Leon's alternative (2.). Where Vdsm, as oVirt host agent, has complete responsibility on configuring the services needed by oVirt. There is no Engine/Vdsm interaction in alternative (2.). Option (3.) requires Engine to provide a list of services to the host.