On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <[email protected]> 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 <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
