On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >>> >>> >> >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
