2:08 p.m.
Hey Oved,
I don't think completely moving away from iptables is foreseeable at this
point, but I could be of course wrong. Either way, upgrading still needs to
be thought of.
By stating that the current infrastructure is complex, I was referring to
the entire chain of storing rules in the database, fetching them using a
dedicated deployment class consisting of include/exclude logic, sending
them over, unpacking, deploying...
This procedure involves a lot of code that could be made redundant if the
required logic is present in the host, which to me seems favorable. It of
course entails other potential difficulties, primarily in the form of
custom services.
I don't think otopi's firewalld plugin is any more complex than the
potential code that will have to be written in vdsm-tool, however it
currently expects the data generated by aforementioned chain. The hybrid
approach briefly touches on simplifying Engine's involvement while
retaining use of otopi's plugin.
On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali(a)redhat.com> wrote:
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(a)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
>
>