Sounds great Murali, thanks for the quick response!
On Thu, Aug 22, 2013 at 10:42 PM, Murali Reddy <murali.re...@citrix.com>wrote: > > I made a commit in 4.2-forward, will wait for BVT to run before raising a > pull request to 4.2. > > On 22/08/13 12:12 PM, "Dave Cahill" <dcah...@midokura.com> wrote: > > >Adding Chiradeep for guidance, as Murali seems to be away at the moment. > > > >Prasanna kindly verified that this is an issue with Virtual Router as well > >as MidoNet, so I have filed a bug against 4.2: > >https://issues.apache.org/jira/browse/CLOUDSTACK-4442 > > > > > > > >On Thu, Aug 22, 2013 at 12:10 PM, Dave Cahill <dcah...@midokura.com> > >wrote: > > > >> Also, I tried to find the code review for this change, but couldn't > >>track > >> it down - could someone point me to it? > >> > >> > >> On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill > >><dcah...@midokura.com>wrote: > >> > >>> Hi Murali, > >>> > >>> After this change [1], how do Source NAT IPs get applied to a network > >>>on > >>> network startup / first VM launch? > >>> > >>> Previously, applyIpAssociations would get called as part of > >>> reprogramNetworkRules, but this change introduces what it calls "a lazy > >>> approach". From what I can see, this means that source NAT doesn't > >>>work on > >>> startup, and I need to add a Static NAT or some other rule in order to > >>>wake > >>> up the lazy approach and have the Source NAT + the new rule be applied. > >>> > >>> Is there a workaround I'm missing? Maybe it's necessary to also enable > >>> the firewall service to trigger application of the source NAT rules? > >>> > >>> Thanks, > >>> Dave. > >>> > >>> [1] > >>> > >>> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se > >>>rver/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6 > >>>102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe5 > >>>68fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d > >>> > >>> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA) > >>><j...@apache.org>wrote: > >>> > >>>> > >>>> [ > >>>> > >>>> > https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian > >>>>.jira.plugin.system.issuetabpanels:all-tabpanel] > >>>> > >>>> Murali Reddy resolved CLOUDSTACK-234. > >>>> ------------------------------------- > >>>> > >>>> Resolution: Fixed > >>>> > >>>> > create/delete firewa/lb/pf rule: send ip assoc command only on first > >>>> rule is created on the IP and last rule is revoked on the IP > >>>> > > >>>> > >>>>----------------------------------------------------------------------- > >>>>---------------------------------------------------------- > >>>> > > >>>> > Key: CLOUDSTACK-234 > >>>> > URL: > >>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234 > >>>> > Project: CloudStack > >>>> > Issue Type: Bug > >>>> > Security Level: Public(Anyone can view this level - this is the > >>>> default.) > >>>> > Components: Management Server > >>>> > Affects Versions: 4.0.0 > >>>> > Reporter: Alena Prokharchyk > >>>> > Assignee: Murali Reddy > >>>> > Fix For: 4.2.0 > >>>> > > >>>> > > >>>> > We have to improve the logic for creating/deleting any kind of > >>>> firewall rules. At the moment ipAssoc is being called when: > >>>> > * the first rule for the ip address is being created > >>>> > * the last rule for the IP address is being removed > >>>> > As a part of ipAssoc command, we send all ip addresses assigned to > >>>>the > >>>> guest network of the rule. The behavior has to be fixed the way we > >>>>send ip > >>>> assoc only for the ip address the rule is being created for. > >>>> > >>>> -- > >>>> This message is automatically generated by JIRA. > >>>> If you think it was sent incorrectly, please contact your JIRA > >>>> administrators > >>>> For more information on JIRA, see: > >>>> http://www.atlassian.com/software/jira > >>>> > >>> > >>> > >> > > > > >
