[ovirt-devel] Firewalld migration.
Martin Sivak
msivak at redhat.com
Tue Mar 28 13:00:05 UTC 2017
> 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.
I seem to remember that the one feature that sets us apart from
everybody else is that we know how to manage the bare metal. And the
current standing decision I know about is that we want to keep that
capability.
Yaniv? Is that still so?
All other solutions (OpenStack, OpenShift, ..) require you to
configure the bare metal first and then deploy virtualization. We
simplify this for the sysadmin and that makes us special (for good and
bad as Sven pointed out).
So, if we do not want to support custom rules in the engine, then the
whole host deploy script (not just firewall) needs to work very
differently, because the end goal is to have properly deployed node
for virtualization. And the "properly" word is defined both by us and
the owner sysadmin.
But deploy has to all or nothing operation, otherwise the engine will
start using half configured host and you risk someone forgetting to
run an extra script.
Martin
On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas at redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak at 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 at 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 at redhat.com>
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber at 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 at redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber at 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 at 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 at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
More information about the Devel
mailing list