[ovirt-devel] Firewalld migration.

[Oved Ourfali]

top-posting:
You need to also consider how upgrade will be handled, right?
Or iptables will still remain supported?

Also, see some comments inline.

Regards,
Oved

On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber at redhat.com> wrote:

>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
>

Can you elaborate?
I'm not an otopi expert, but I think that otopi plugins shouldn't be more
complex than what you describe in section #2, and the plugins were meant in
order to handle such cases.

- Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
>
So here you replace the otopi plugin with relevant vdsm-tool code, and the
question is why is that better?


> Pros:
>
>  - Engine side involvement is greatly diminished.
>  - Simple(r).
>
> Cons:
>
>  - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170326/bf2c6cc7/attachment.html>