<div dir="ltr"><div>You're right, but I don't think it matters; hosts will remain unaffected until they're reinstalled via an upgraded Engine.<br><br></div><div>Clients should be made aware their custom rules are going to be obsolete and that they should reapply them once they reinstall.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 9:01 AM, 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 6:01 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>> wrote:<br>
> Effectively, upgrading will leave lingering (but nonetheless operational)<br>
> iptables rules on the hosts. I'm not even sure there needs to be special<br>
> upgrade treatment?<br>
<br>
</span>Please describe the expected flow.<br>
<br>
Please note that at least when I tried, 'systemctl start firewalld' stops<br>
iptables.<br>
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>> wrote:<br>
>><br>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>> wrote:<br>
>> > 1) Do we actually need iptables for any reason that isn't a legacy<br>
>> > consideration?<br>
>><br>
>> No idea personally.<br>
>><br>
>> Perhaps some users prefer that, and/or need that for integration with<br>
>> other<br>
>> systems/solutions/whatever.<br>
>><br>
>> If we drop iptables, how do you suggest to treat upgrades?<br>
>><br>
>> ><br>
>> > 2 & 3) I am in favor of treating custom services as a requirement and<br>
>> > 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<br>
>> > (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<br>
>> > all<br>
>> > the services to be statically provided (by either firewalld or the<br>
>> > relevant<br>
>> > 3rd party packages).<br>
>> ><br>
>> > Ideally I think we'd like use statically provided services, and provide<br>
>> > 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<br>
>> > 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>><br>
>> > wrote:<br>
>> >><br>
>> >><br>
>> >> 1. Do we want to support in some version X both iptables and firewalld,<br>
>> >> or<br>
>> >> is it ok to stop support for iptables and support only firewalld<br>
>> >> 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<br>
>> >> 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>
>> --<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>