[Engine-devel] Gluster IPTable configuration

[Alon Bar-Lev]

----- Original Message -----
> From: "Shireesh Anjal" <sanjal at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Selvasundaram" <sesubram at redhat.com>
> Sent: Monday, September 3, 2012 3:42:17 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
> 
> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Selvasundaram" <sesubram at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Cc: "Shireesh Anjal" <sanjal at redhat.com>
> >> Sent: Thursday, August 30, 2012 4:30:16 PM
> >> Subject: [Engine-devel] Gluster IPTable configuration
> >>
> >>
> >> Hi,
> >>
> >> I want to add gluster specific IPTable configuration in addition
> >> to
> >> the ovirt IPTable configuration (if it is gluster node).
> >>
> >> There are two approaches,
> >> 1. Having one more gluster specific IP table config in db and
> >> merge
> >> with ovirt IPTable config (merging NOT appending)
> >> [I have the patch engine: Gluster specific firewall configurations
> >> #7244]
> >> 2. Having two different IP Table config (ovirt and ovirt+gluster)
> >> and
> >> use either one.
> >>
> >> Please provide your suggestions or improvements on this.
> >>
> > Hello all,
> >
> > The mentioned patch[1], adds hard coded gluster code into the
> > bootstrap code, manipulate the firewall configuration to be
> > gluster specific. It hardcoded search for "reject", insert before
> > some other rules.
> >
> > I believe this hardcode approach is obsolete now that we have
> > proper tools for templates.
> >
> > A more robust solution would be defining generic profiles, each
> > profile as a template, each template can refer to different
> > profiles, and assign profile to a node.
> >
> > This way the implementation is not gluster [or any] specific and
> > can be reused for more setups, code is cleaner.
> >
> > Example:
> >
> > BASIC.PRE
> >      :INPUT ACCEPT [0:0]
> >      :FORWARD ACCEPT [0:0]
> >      :OUTPUT ACCEPT [0:0]
> > BASIC.IN
> >      accept ...
> >      accept ...
> > BASIC.POST
> >      reject ...
> >      reject ...
> >
> > BASIC
> >      ${BASIC.PRE}
> >      ${BASIC.IN}
> >      ${BASIC.POST}
> >
> > GLUSTER
> >      ${BASIC.PRE}
> >      ${BASIC.IN}
> >      accept ...
> >      ${BASIC.POST}
> >      reject ...
> 
> I like the separation of PRE/IN/POST rules here. However I think it
> is
> better to keep the service specific rules in separate configurations.
> Currently, whole iptables rules script is kept in the vdc option
> "IPTablesConfig". How about changing this as follows?
> 
> - Split the current config into three: IPTablesConfig.PRE,
> IPTablesConfig.VIRT and IPTablesConfig.POST
> - Let services like Gluster add their own vdc options e.g.
> IPTablesConfig.GLUSTER
> - When assembling the full script in VdsInstaller,
>    - Take IPTablesConfig.PRE
>    - Append it with IPTablesConfig.<service> for every service to be
> enabled on the host/cluster
>    - Append it with IPTablesConfig.POST
> 
> Thoughts?

This is a simple approach that will work for current implementation and configuration.

However, it will effect all nodes, with or without gluster.

I think that while we at it we should consider how to effect only appropriate subset of nodes.

Alon.