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 >>>> >>> >>> >> >
