<div dir="ltr">Ok, so I guess I misread.<div>VDSM should have that responsibility and engine should not be evolved.</div><div>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.<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">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: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 29, 2017 at 9:53 AM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <<a href="mailto:ydary@redhat.com">ydary@redhat.com</a>> wrote:<br>
> Hi,<br>
> I like option number 3 the most from reading the comments.<br>
> We are not a configuration management system, so custom rules should not be<br>
> a main consideration.<br>
> VDSM should probably enable the firewalld rules it needs to work and engine<br>
> should not care about firewall at all.<br>
> A user wanting to add more rules then this should probably use the ones<br>
> planned in:<br>
> <a href="https://github.com/cockpit-project/system-api-roles" rel="noreferrer" target="_blank">https://github.com/cockpit-<wbr>project/system-api-roles</a><br>
<br>
<br>
</span>I, too, like the idea of shedding off the attempt to configure custom<br>
iptables rules. Moving to firewalld makes it much easier to manage<br>
such customization out of oVirt. (Anybody who's ever edited iptables<br>
chains by hand would know what I mean)<br>
<br>
Please note that what you describe is Leon's alternative (2.). Where<br>
Vdsm, as oVirt host agent, has complete responsibility on configuring<br>
the services needed by oVirt. There is no Engine/Vdsm interaction in<br>
alternative (2.). Option (3.) requires Engine to provide a list of<br>
services to the host.<br>
</blockquote></div><br></div></div></div>