<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> But we do not want to support custom firewall rules, we are not a firewall<br>
> manager.<br>
> IMO, oVirt should support the hardening of its services and co-exist with<br>
> other rules.<br>
> Custom firewall settings imply one of these:<br>
> - We need to extend current firewall options.<br>
> - It needs to be implemented outside oVirt.<br>
><br>
> But if the need to support back doors is proven to be a must, then implement<br>
> them<br>
> outside the main core solution, these edge cases should not block the main<br>
> business<br>
> logic.<br>
<br>
</span>I seem to remember that the one feature that sets us apart from<br>
everybody else is that we know how to manage the bare metal. And the<br>
current standing decision I know about is that we want to keep that<br>
capability.<br>
<br>
Yaniv? Is that still so?<br></blockquote><div><br></div><div>It is, but we also need to acknowledge that:</div><div>1. We can't configure (and/or possibly customize) everything (NTP? multipath.conf configuration? even vdsm.conf!). We strive to improve and do it well, but there are limits and challenges.</div><div>2. There are better tools to do it than via engine-config -> database -> host-deploy, which are also easier for both us to support as well as our users to work with.</div><div>Y.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
All other solutions (OpenStack, OpenShift, ..) require you to<br>
configure the bare metal first and then deploy virtualization. We<br>
simplify this for the sysadmin and that makes us special (for good and<br>
bad as Sven pointed out).<br>
<br>
So, if we do not want to support custom rules in the engine, then the<br>
whole host deploy script (not just firewall) needs to work very<br>
differently, because the end goal is to have properly deployed node<br>
for virtualization. And the "properly" word is defined both by us and<br>
the owner sysadmin.<br>
<br>
But deploy has to all or nothing operation, otherwise the engine will<br>
start using half configured host and you risk someone forgetting to<br>
run an extra script.<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <<a href="mailto:ehaas@redhat.com">ehaas@redhat.com</a>> wrote:<br>
><br>
><br>
> On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>><br>
>> > Clients should be made aware their custom rules are going to be obsolete<br>
>> > and<br>
>> > that they should reapply them once they reinstall.<br>
>><br>
>> Would you want to manually fix every reinstalled host? I would<br>
>> consider that very annoying. This has to be somewhat automatic if we<br>
>> want to support custom firewall rules. And although I agree the engine<br>
>> is not the right place for that, it is the only central place we have<br>
>> and from which we are starting the reinstall task.<br>
><br>
><br>
> But we do not want to support custom firewall rules, we are not a firewall<br>
> manager.<br>
> IMO, oVirt should support the hardening of its services and co-exist with<br>
> other rules.<br>
> Custom firewall settings imply one of these:<br>
> - We need to extend current firewall options.<br>
> - It needs to be implemented outside oVirt.<br>
><br>
> But if the need to support back doors is proven to be a must, then implement<br>
> them<br>
> outside the main core solution, these edge cases should not block the main<br>
> business<br>
> logic.<br>
><br>
><br>
>><br>
>><br>
>> Martin<br>
>><br>
>> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>> wrote:<br>
>> > You're right, but I don't think it matters; hosts will remain unaffected<br>
>> > until they're reinstalled via an upgraded Engine.<br>
>> ><br>
>> > Clients should be made aware their custom rules are going to be obsolete<br>
>> > and<br>
>> > that they should reapply them once they reinstall.<br>
>> ><br>
>> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>> >> wrote:<br>
>> >> > Effectively, upgrading will leave lingering (but nonetheless<br>
>> >> > operational)<br>
>> >> > iptables rules on the hosts. I'm not even sure there needs to be<br>
>> >> > special<br>
>> >> > upgrade treatment?<br>
>> >><br>
>> >> Please describe the expected flow.<br>
>> >><br>
>> >> Please note that at least when I tried, 'systemctl start firewalld'<br>
>> >> stops<br>
>> >> iptables.<br>
>> >><br>
>> >> Thanks,<br>
>> >><br>
>> >> ><br>
>> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>> >> >> wrote:<br>
>> >> >> > 1) Do we actually need iptables for any reason that isn't a legacy<br>
>> >> >> > consideration?<br>
>> >> >><br>
>> >> >> No idea personally.<br>
>> >> >><br>
>> >> >> Perhaps some users prefer that, and/or need that for integration<br>
>> >> >> with<br>
>> >> >> other<br>
>> >> >> systems/solutions/whatever.<br>
>> >> >><br>
>> >> >> If we drop iptables, how do you suggest to treat upgrades?<br>
>> >> >><br>
>> >> >> ><br>
>> >> >> > 2 & 3) I am in favor of treating custom services as a requirement<br>
>> >> >> > and<br>
>> >> >> > plan<br>
>> >> >> > accordingly. Many (most, even) of the services are already<br>
>> >> >> > provided<br>
>> >> >> > by<br>
>> >> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party<br>
>> >> >> > packages<br>
>> >> >> > (e.g.<br>
>> >> >> > gluster). Some are missing (I've recently created a pull request<br>
>> >> >> > for<br>
>> >> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able<br>
>> >> >> > to<br>
>> >> >> > get<br>
>> >> >> > all<br>
>> >> >> > the services to be statically provided (by either firewalld or the<br>
>> >> >> > relevant<br>
>> >> >> > 3rd party packages).<br>
>> >> >> ><br>
>> >> >> > Ideally I think we'd like use statically provided services, and<br>
>> >> >> > provide<br>
>> >> >> > the<br>
>> >> >> > capability to provide additional services (I'm not a fan of the<br>
>> >> >> > current<br>
>> >> >> > methodology of converting strings into xmls). I don't think we'd<br>
>> >> >> > want<br>
>> >> >> > to<br>
>> >> >> > limit usage to just statically provided services. (2)<br>
>> >> >> ><br>
>> >> >> > As previously stated, I don't see a technical reason to keep<br>
>> >> >> > iptables<br>
>> >> >> > under<br>
>> >> >> > consideration. (3)<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David<br>
>> >> >> > <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>> >> >> > wrote:<br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> 1. Do we want to support in some version X both iptables and<br>
>> >> >> >> firewalld,<br>
>> >> >> >> or<br>
>> >> >> >> is it ok to stop support for iptables and support only firewalld<br>
>> >> >> >> without<br>
>> >> >> >> overlap? If so, do we handle upgrades, and how?<br>
>> >> >> >><br>
>> >> >> >> 2. Do we want to support custom firewalld xml to be configured on<br>
>> >> >> >> the<br>
>> >> >> >> host by us? Or is it ok to only support choosing among existing<br>
>> >> >> >> services,<br>
>> >> >> >> which will need to be added to the host using other means<br>
>> >> >> >> (packaged<br>
>> >> >> >> by<br>
>> >> >> >> firewalld, packaged by 3rd parties, added manually by users)?<br>
>> >> >> >><br>
>> >> >> >> 3. Opposite of (2.): Do we want to support firewalld services<br>
>> >> >> >> that<br>
>> >> >> >> are<br>
>> >> >> >> added to the host using other means (see there)? Obviously we do,<br>
>> >> >> >> but:<br>
>> >> >> >> If we do, do we still want to support also iptables (see (1.))?<br>
>> >> >> >> And<br>
>> >> >> >> if<br>
>> >> >> >> so, what do we want to then happen?<br>
>> >> >> >><br>
>> >> >> >> (2.) and (3.) are not conflicting, each needs its own answer.<br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> --<br>
>> >> >> >> Didi<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> --<br>
>> >> >> Didi<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Didi<br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Devel mailing list<br>
>> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> ______________________________<wbr>_________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>