Re: [Engine-devel] Gluster IPTable configuration

----- Original Message ----- > From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > To: engine-devel(a)ovirt.org > Cc: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "Selvasundaram" <sesubram(a)redhat.com&gt; > 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(a)redhat.com&gt; >>> To: engine-devel(a)ovirt.org >>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com&gt; >>> 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.