Re: [Engine-devel] Gluster IPTable configuration

----- Original Message ----- > From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: "Selvasundaram" <sesubram(a)redhat.com&gt;, engine-devel(a)ovirt.org > Sent: Monday, September 3, 2012 4:00:14 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > > On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: >> ----- 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 don't get the concern here. Could you please elaborate? If we have 500 nodes, out of them 200 gluster, why do I need to distribute gluster specific rules to all 500?

Alon.