cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sheng Yang (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CLOUDSTACK-7169) VR_Rolling_Upgarde: command execution order changed when we restart the network
Date Fri, 08 Aug 2014 23:28:12 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sheng Yang resolved CLOUDSTACK-7169.
------------------------------------

    Resolution: Not a Problem

> 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.2#6252)

Mime
View raw message