[Engine-devel] Gluster IPTable configuration

[Shireesh Anjal]

On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Selvasundaram" <sesubram at redhat.com>, engine-devel at 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 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 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?

When I say "Append it with IPTablesConfig.<service> for every service to be enabled on the host/cluster", I mean every service that "needs to be enabled" on the host. In today's scenario, where virt and gluster are the only two services, it will look something like:

  - If cluster supports virt, append IPTablesConfig.VIRT
  - If cluster supports gluster, append IPTablesConfig.GLUSTER

So it will be driven by the cluster in which the host is being added. And gluster rules will be sent to only the hosts of clusters that have gluster enabled.

>
> Alon.