Re: [Engine-devel] Gluster IPTable configuration
- Original Message - From: Doron Fediuck dfedi...@redhat.com To: Itamar Heim ih...@redhat.com Cc: David Jaša dj...@redhat.com, engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:09:04 AM Subject: Re: [Engine-devel] Gluster IPTable configuration why not use the chains approach, and have a chain per service? Since you wish to avoid collisions. So for gluster only, have a VIRT prefix as well. If an implementation may separate between the WHAT and the HOW, it may be easier to be maintained. --- WHAT Merge several iptables rules into one node iptables. HOW Use templates to build string, send string as a file in remote. --- As you can see the HOW (which is the actual implementation) knows nothing about iptables. So it is simple and can be reused. The whole logic of WHAT is put into the metadata, where humans may customized without touching the code, even when iptables get messy and complex. An example of WHAT and HOW that are not separated is the authentication/authorization (Kerberos/LDAP) implementation, where both WHAT and HOW are inter-connected, the cost of adding a new environment in this case is huge. Doron suggested to use comments or some signature within the iptables configuration, this is what templates are all about, however, instead of re-inventing the wheel, a standard text based templates engine can be used. The template (the WHAT) may use custom chains, regular chains, it is not important as implementation (the HOW) is not looking into the content. Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
what about using netcf for the configuration similarly as libvirt does? http://libvirt.org/formatnwfilter.html IMHO it should solve the problem temporarily before firewalld matures. David PS: please keep me out of CC, I'm more than happy when I watch these discussions via list Alon Bar-Lev píše v Po 03. 09. 2012 v 05:51 -0400: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Itamar Heim ih...@redhat.com Cc: David Jaša dj...@redhat.com, engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:09:04 AM Subject: Re: [Engine-devel] Gluster IPTable configuration why not use the chains approach, and have a chain per service? Since you wish to avoid collisions. So for gluster only, have a VIRT prefix as well. If an implementation may separate between the WHAT and the HOW, it may be easier to be maintained. --- WHAT Merge several iptables rules into one node iptables. HOW Use templates to build string, send string as a file in remote. --- As you can see the HOW (which is the actual implementation) knows nothing about iptables. So it is simple and can be reused. The whole logic of WHAT is put into the metadata, where humans may customized without touching the code, even when iptables get messy and complex. An example of WHAT and HOW that are not separated is the authentication/authorization (Kerberos/LDAP) implementation, where both WHAT and HOW are inter-connected, the cost of adding a new environment in this case is huge. Doron suggested to use comments or some signature within the iptables configuration, this is what templates are all about, however, instead of re-inventing the wheel, a standard text based templates engine can be used. The template (the WHAT) may use custom chains, regular chains, it is not important as implementation (the HOW) is not looking into the content. Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote:
- Original Message -
From: Selvasundaram sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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?
Regards,
Alon Bar-Lev
[1] http://gerrit.ovirt.org/#/c/7244/
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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?
I think that while we at it we should consider how to effect only appropriate
subset of nodes.
Alon.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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?
Alon.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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.
Alon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
On Monday 03 September 2012 07:20 PM, Alon Bar-Lev wrote:
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Shireesh Anjal san...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Monday, September 3, 2012 9:50:52 AM
Subject: Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com,
engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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.
Do we want to
Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Andrew Cathrow acath...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: engine-devel@ovirt.org, Shireesh Anjal san...@redhat.com
Sent: Monday, September 3, 2012 11:05:20 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Shireesh Anjal san...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Monday, September 3, 2012 9:50:52 AM
Subject: Re: [Engine-devel] Gluster IPTable configuration
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com, engine-devel@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 san...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Selvasundaram sesub...@redhat.com,
engine-devel@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 san...@redhat.com
To: engine-devel@ovirt.org
Cc: Alon Bar-Lev alo...@redhat.com, Selvasundaram
sesub...@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 sesub...@redhat.com
To: engine-devel@ovirt.org
Cc: Shireesh Anjal san...@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:
Re: [Engine-devel] Gluster IPTable configuration
- Original Message - From: Andrew Cathrow acath...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel@ovirt.org, Shireesh Anjal san...@redhat.com, Mike Burns mbu...@redhat.com Sent: Monday, September 3, 2012 11:57:57 PM Subject: Re: [Engine-devel] Gluster IPTable configuration snip Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to Here I lost you... :) I thought ovirt-engine is the master and ovirt-hypervisor is a slave. This derives that all management activities of slave is done by master... There should be no setting at slave that master is not aware of. This also enables you to duplicate hipervisor, recover configuration or push mass configuration change. In your above case, this rule for monitoring agent may be added at master repository and pushed to slaves belongs to specific group, just like the gluster case. The template mechanism is what enable you to create a custom configuration per environment. Using push and not re-integrate derives much simpler and deterministic implementation. But maybe I did not understand some of the fundamental concepts of the architecture. Regards, Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster IPTable configuration
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Shireesh Anjal san...@redhat.com, Mike Burns mbu...@redhat.com Sent: Monday, September 3, 2012 5:09:34 PM Subject: Re: [Engine-devel] Gluster IPTable configuration - Original Message - From: Andrew Cathrow acath...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel@ovirt.org, Shireesh Anjal san...@redhat.com, Mike Burns mbu...@redhat.com Sent: Monday, September 3, 2012 11:57:57 PM Subject: Re: [Engine-devel] Gluster IPTable configuration snip Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to Here I lost you... :) I thought ovirt-engine is the master and ovirt-hypervisor is a slave. This derives that all management activities of slave is done by master... Let's say I use nagios for my host monitoring. I setup a rhel/fedora/*EL host using my standard corporate and include port 5667/5666 for nagios. ovirt engine connects to it and blocks nagios. While it would be great to have all firewall rules (and other settings) managed from ovirt-engine we are a long way away from that. Adding rules rather than overwriting iptables config would allow us not to stomp on the user's existing settings. There should be no setting at slave that master is not aware of. This also enables you to duplicate hipervisor, recover configuration or push mass configuration change. In your above case, this rule for monitoring agent may be added at master repository and pushed to slaves belongs to specific group, just like the gluster case. yes, but in the 24 months between now and when we get to implement that feature .. The template mechanism is what enable you to create a custom configuration per environment. Using push and not re-integrate derives much simpler and deterministic implementation. But maybe I did not understand some of the fundamental concepts of the architecture. Regards, Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
