[Engine-devel] Gluster IPTable configuration

Shireesh Anjal sanjal at redhat.com
Mon Sep 3 14:34:41 UTC 2012


On Monday 03 September 2012 07:20 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:21:58 PM
>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>
>> 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.
> OK... this is why I prefer templates. Much more simple and generic. No need to have custom application logic within application.

I don't see what is so complex about the above approach, but do agree 
that it is not completely generic. A new service will require a new if 
condition in the VdsInstaller.

In order to understand the templates approach better, can you please 
point me to some existing code in oVirt that uses such an approach? I 
see an example of the template text above, but I'm not sure how it can 
be used from the code.

>
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




More information about the Engine-devel mailing list