On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
> 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?

Please describe the expected flow.

Please note that at least when I tried, 'systemctl start firewalld' stops
iptables.

Thanks,

>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi@redhat.com> wrote:
>>
>> 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
>
>

--
Didi