On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak@redhat.com> wrote:
Clients should be made aware their custom rules are going to be obsolete and that they should reapply them once they reinstall.
Would you want to manually fix every reinstalled host? I would consider that very annoying. This has to be somewhat automatic if we want to support custom firewall rules. And although I agree the engine is not the right place for that, it is the only central place we have and from which we are starting the reinstall task.
But we do not want to support custom firewall rules, we are not a firewall manager. IMO, oVirt should support the hardening of its services and co-exist with other rules. Custom firewall settings imply one of these: - We need to extend current firewall options. - It needs to be implemented outside oVirt. But if the need to support back doors is proven to be a must, then implement them outside the main core solution, these edge cases should not block the main business logic.
Martin
On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
You're right, but I don't think it matters; hosts will remain unaffected until they're reinstalled via an upgraded Engine.
Clients should be made aware their custom rules are going to be obsolete and that they should reapply them once they reinstall.
On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi@redhat.com> wrote:
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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel