[ovirt-devel] Firewalld migration.

[Oved Ourfali]

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

> 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.
>
>
I see.


> 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.
>
>
Okay. I think that writing a new plugin for firewalld is indeed a good
option, whether you "refactor" the engine side or not.


>
>
> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali at 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 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/7d3e39b9/attachment.html>