On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
> 1) Do we actually need iptables for any reason that isn't a legacy
> consideration?

No idea personally.

Perhaps some users prefer that, and/or need that for integration with other
systems/solutions/whatever.

If we drop iptables, how do you suggest to treat upgrades?

>
> 2 & 3) I am in favor of treating custom services as a requirement and plan
> accordingly. Many (most, even) of the services are already provided by
> either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages (e.g.
> gluster). Some are missing (I've recently created a pull request for
> ovirt-imageio to firewalld, for example) and I hope we'll be able to get all
> the services to be statically provided (by either firewalld or the relevant
> 3rd party packages).
>
> Ideally I think we'd like use statically provided services, and provide the
> capability to provide additional services (I'm not a fan of the current
> methodology of converting strings into xmls). I don't think we'd want to
> limit usage to just statically provided services. (2)
>
> As previously stated, I don't see a technical reason to keep iptables under
> consideration. (3)
>
>
> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi@redhat.com> wrote:
>>
>>
>> 1. Do we want to support in some version X both iptables and firewalld, or
>> is it ok to stop support for iptables and support only firewalld without
>> overlap? If so, do we handle upgrades, and how?
>>
>> 2. Do we want to support custom firewalld xml to be configured on the
>> host by us? Or is it ok to only support choosing among existing services,
>> which will need to be added to the host using other means (packaged by
>> firewalld, packaged by 3rd parties, added manually by users)?
>>
>> 3. Opposite of (2.): Do we want to support firewalld services that are
>> added to the host using other means (see there)? Obviously we do, but:
>> If we do, do we still want to support also iptables (see (1.))? And if
>> so, what do we want to then happen?
>>
>> (2.) and (3.) are not conflicting, each needs its own answer.
>>
>>
>> --
>> Didi
>
>

--
Didi