----- Original Message ----- > From: "Alon Bar-Lev" <alo...@redhat.com> > To: "David Jaša" <dj...@redhat.com> > Cc: engine-devel@ovirt.org > Sent: Friday, August 31, 2012 5:09:47 AM > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > ----- Original Message ----- > > From: "David Jaša" <dj...@redhat.com> > > To: engine-devel@ovirt.org > > Sent: Friday, August 31, 2012 11:57:11 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400: > > > > > > ----- Original Message ----- > > > > From: "Andrew Cathrow" <acath...@redhat.com> > > > > To: "Alon Bar-Lev" <alo...@redhat.com> > > > > Cc: "Shireesh Anjal" <san...@redhat.com>, > > > > engine-devel@ovirt.org, > > > > "Selvasundaram" <sesub...@redhat.com> > > > > Sent: Thursday, August 30, 2012 9:37:59 PM > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" <alo...@redhat.com> > > > > > To: "Selvasundaram" <sesub...@redhat.com> > > > > > Cc: "Shireesh Anjal" <san...@redhat.com>, > > > > > engine-devel@ovirt.org > > > > > Sent: Thursday, August 30, 2012 2:35:16 PM > > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > > > > > > > > > > > > > > > > ----- 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. > > > > > > > > > > > > or create custom chains ? > > > > > > Can you please elaborate what is custom chains? > > > Thanks! > > > > iptables -N my_new_chain > > iptables -A my_new_chain <rule_1> > > iptables -A my_new_chain ... > > iptables -A my_new_chain <rule_n> > > > > # if this <rule> is matched, packet goes through rules in > > my_new_chain > > iptables -A INPUT <rule> -j my_new_chain > > > > Hello, > > How does this solve the original issue?
It makes it easier for customers who are adding their own IPTables configuration - when we do rhev-h plugins it'll make things easier. This way we don't wipe out the original rules we just add our own chain. > The need to provide different rules to different hosts by software > installed on destination? > > Standard host needs iptables X. > Gluster host needs iptables X+Y. > XXX host needs iptables X+Z. > Maintainer of Gluster knows what Y is. > Maintainer of XXX knows what Z is. > > If we merge all to one entry product comes with default X. > User override X to A. > New version of product comes with default Y. > Upgrade options: > 1. System continues to use A. > 2. Some AI to upgrade and create A'. > 3. Revert to Y, dropping user's customization. > > Or we can maintain one large table with complete configuration and > conditionals. > > Alon. > _______________________________________________ > 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