<div dir="ltr">Effectively, upgrading will leave lingering (but nonetheless operational) iptables rules on the hosts. I'm not even sure there needs to be special upgrade treatment?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@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 Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>> wrote:<br>
> 1) Do we actually need iptables for any reason that isn't a legacy<br>
> consideration?<br>
<br>
</span>No idea personally.<br>
<br>
Perhaps some users prefer that, and/or need that for integration with other<br>
systems/solutions/whatever.<br>
<br>
If we drop iptables, how do you suggest to treat upgrades?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> 2 & 3) I am in favor of treating custom services as a requirement and plan<br>
> accordingly. Many (most, even) of the services are already provided by<br>
> either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages (e.g.<br>
> gluster). Some are missing (I've recently created a pull request for<br>
> ovirt-imageio to firewalld, for example) and I hope we'll be able to get all<br>
> the services to be statically provided (by either firewalld or the relevant<br>
> 3rd party packages).<br>
><br>
> Ideally I think we'd like use statically provided services, and provide the<br>
> capability to provide additional services (I'm not a fan of the current<br>
> methodology of converting strings into xmls). I don't think we'd want to<br>
> limit usage to just statically provided services. (2)<br>
><br>
> As previously stated, I don't see a technical reason to keep iptables under<br>
> consideration. (3)<br>
><br>
><br>
> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>> wrote:<br>
>><br>
>><br>
>> 1. Do we want to support in some version X both iptables and firewalld, or<br>
>> is it ok to stop support for iptables and support only firewalld without<br>
>> overlap? If so, do we handle upgrades, and how?<br>
>><br>
>> 2. Do we want to support custom firewalld xml to be configured on the<br>
>> host by us? Or is it ok to only support choosing among existing services,<br>
>> which will need to be added to the host using other means (packaged by<br>
>> firewalld, packaged by 3rd parties, added manually by users)?<br>
>><br>
>> 3. Opposite of (2.): Do we want to support firewalld services that are<br>
>> added to the host using other means (see there)? Obviously we do, but:<br>
>> If we do, do we still want to support also iptables (see (1.))? And if<br>
>> so, what do we want to then happen?<br>
>><br>
>> (2.) and (3.) are not conflicting, each needs its own answer.<br>
>><br>
>><br>
>> --<br>
>> Didi<br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Didi<br>
</font></span></blockquote></div><br></div>