[ https://issues.apache.org/jira/browse/CLOUDSTACK-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
sadhu suresh closed CLOUDSTACK-7169. ------------------------------------ closing this as its working as per design. "Not a problem because without aggregation command, network restart would execute in the same order as well. Aggregation command doesn't change the order of commands passing to it." > VR_Rolling_Upgarde: command execution order changed when we restart the > network > --------------------------------------------------------------------------------- > > Key: CLOUDSTACK-7169 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7169 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server > Affects Versions: 4.5.0 > Reporter: sadhu suresh > Assignee: Sheng Yang > Priority: Critical > > when we reboot the VR, the order is proper (i.e ip assoc first then later > firewall rule next) but when restart the network ,the order has changed > i.e we are programming firewall before ipassoc. > 1.configure advanced zone with vmware > 2.deploy a vm > 3.acquire a public IP and configure the LB rule > 4. restart the router > 5. once the router is up ,check the command execution order > 6.again perform the network restart > 7.check the configured order > actual result: > step 4:(incase of router restart) - the order is ok as per expected (i.e > programming firewall after ipassoc) > Step 6:(restart network) > Here order has changed and it s programming firewall rule before ipassoc > please check the VR*.cfg > root@cen62307 ~]# cat VR-18351526-c087-48b9-8f8b-10b2c3f8a07e.cfg > #Apache CloudStack Virtual Router Config File > <version> > 1.0 > </version> > <script> > /opt/cloud/bin/firewall_ingress.sh -F -a 10.147.49.200:tcp:22:22:0.0.0.0/0:, > </script> > <script> > /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1 > </script> > <script> > /opt/cloud/bin/ipassoc.sh -A -l 10.147.49.200/24 -c eth2 -g 10.147.49.1 > </script> > <file> > /etc/haproxy/haproxy.cfg.new.1406117121933 > global > log 127.0.0.1:3914 local0 warning > maxconn 4096 > maxpipes 1024 > chroot /var/lib/haproxy > user haproxy > group haproxy > daemon > defaults > log global > mode tcp > option dontlognull > retries 3 > option redispatch > option forwardfor > option forceclose > timeout connect 5000 > timeout client 50000 > timeout server 50000 > listen stats_on_public 10.147.49.189:8081 > mode http > option httpclose > stats enable > stats uri /admin?stats > stats realm Haproxy\ Statistics > stats auth admin1:AdMiN123 > listen 10_147_49_189-22 10.147.49.189:22 > balance roundrobin > server 10_147_49_189-22_0 10.1.1.2:22 check > listen 10_147_49_200-22 10.147.49.200:22 > balance roundrobin > server 10_147_49_200-22_0 10.1.1.105:22 check > </file> > <script> > /opt/cloud/bin/loadbalancer.sh -i 10.147.41.29 -f > /etc/haproxy/haproxy.cfg.new.1406117121933 -a > 10.147.49.189:22:,10.147.49.200:22:, -s 10.147.49.189:8081:0/0:,, > </script> > <script> > /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1 > </script> > <script> > /opt/cloud/bin/ipassoc.sh -A -l 10.147.49.200/24 -c eth2 -g 10.147.49.1 > expected result: > "as per the functional spec:•Order is extremely important!••We don't want to > program firewall before ipassoc". so need to handle the order when we restart > the network as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)