You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Abhinav Roy (JIRA)" <ji...@apache.org> on 2013/04/02 14:21:15 UTC

[jira] [Updated] (CLOUDSTACK-1891) [AWS style Health Checks]After upgrade from 4.0 to 4.2 , cleanup not happening properly after releasing the IP on which LB was configured

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

Abhinav Roy updated CLOUDSTACK-1891:
------------------------------------

    Description: 
Steps :
==============================
1. Upgrade MS from 4.0 to 4.2
2. Go to the existing Netscaler network, acquire IP and create a LB rule.
3. configure health checks on the LB rule.
4. Release the IP acquired in step 2


Expected behaviour :
=============================
IP should be relased, LB rule and the LB monitor created on NS device also should be deleted.


Observed behaviour :
============================
IP is released
LB rule doesn't get deleted on CS but the corresponding lb vserver is deleted from NS
LB health check policy gets deleted on CS but the corresponding monitor doesn't get deleted from NS

2013-04-02 17:23:13,735 ERROR [network.resource.NetscalerResource] (DirectAgent-29:null) Failed to execute LoadBalancerConfigCommand due to 
com.cloud.utils.exception.ExecutionException: Failed to delete monitor :Cloud-Hc-10.102.195.19-22 due to Monitor must be unbound before it can be deleted
        at com.cloud.network.resource.NetscalerResource.removeLBMonitor(NetscalerResource.java:2289)
        at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:678)
        at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:351)
        at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:340)
        at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:679)
2013-04-02 17:23:13,793 WARN  [network.resource.NetscalerResource] (DirectAgent-29:null) Retrying LoadBalancerConfigCommand. Number of retries remaining: 1
2013-04-02 17:23:13,823 INFO  [network.resource.NetscalerResource] (DirectAgent-29:null) Successfully executed resource LoadBalancerConfigCommand: {"loadBalancers":[{"uuid":"eaa5d85c-6d81-43dc-b2a2-9431f2cb9c12","srcIp":"10.102.195.19","srcPort":22,"protocol":"tcp","algorithm":"roundrobin","revoked":true,"alreadyAdded":false,"inline":false,"destinations":[{"destIp":"10.2.113.88","destPort":22,"revoked":true,"alreadyAdded":false},{"destIp":"10.2.112.78","destPort":22,"revoked":true,"alreadyAdded":false}],"healthCheckPolicies":[{"pingPath":"/","responseTime":2,"healthcheckInterval":5,"healthcheckThresshold":2,"unhealthThresshold":1,"revoke":true}]}],"lbStatsVisibility":"guest-network","lbStatsPort":"8081","lbStatsSrcCidrs":"0/0","lbStatsAuth":"admin1:AdMiN123","lbStatsUri":"/admin?stats","accessDetails":{"guest.vlan.tag":"819"},"wait":0}

  was:
Steps :
==============================
1. Upgrade MS from 4.0 to 4.2
2. Go to the existing Netscaler network, acquire IP and create a LB rule.
3. configure health checks on the LB rule.
4. Release the IP acquired in step 2


Expected behaviour :
=============================
IP should be relased, LB rule and the LB monitor created on NS device also should be deleted.


Observed behaviour :
============================
IP is released
LB rule doesn't get deleted on CS but the corresponding lb vserver is deleted from NS
LB health check policy gets deleted on CS but the corresponding monitor doesn't get deleted from NS



    
> [AWS style Health Checks]After upgrade from 4.0 to 4.2 , cleanup not happening properly after releasing the IP on which LB was configured
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1891
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1891
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.2.0
>            Reporter: Abhinav Roy
>            Assignee: Rajesh Battala
>             Fix For: 4.2.0
>
>
> Steps :
> ==============================
> 1. Upgrade MS from 4.0 to 4.2
> 2. Go to the existing Netscaler network, acquire IP and create a LB rule.
> 3. configure health checks on the LB rule.
> 4. Release the IP acquired in step 2
> Expected behaviour :
> =============================
> IP should be relased, LB rule and the LB monitor created on NS device also should be deleted.
> Observed behaviour :
> ============================
> IP is released
> LB rule doesn't get deleted on CS but the corresponding lb vserver is deleted from NS
> LB health check policy gets deleted on CS but the corresponding monitor doesn't get deleted from NS
> 2013-04-02 17:23:13,735 ERROR [network.resource.NetscalerResource] (DirectAgent-29:null) Failed to execute LoadBalancerConfigCommand due to 
> com.cloud.utils.exception.ExecutionException: Failed to delete monitor :Cloud-Hc-10.102.195.19-22 due to Monitor must be unbound before it can be deleted
>         at com.cloud.network.resource.NetscalerResource.removeLBMonitor(NetscalerResource.java:2289)
>         at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:678)
>         at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:351)
>         at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:340)
>         at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:679)
> 2013-04-02 17:23:13,793 WARN  [network.resource.NetscalerResource] (DirectAgent-29:null) Retrying LoadBalancerConfigCommand. Number of retries remaining: 1
> 2013-04-02 17:23:13,823 INFO  [network.resource.NetscalerResource] (DirectAgent-29:null) Successfully executed resource LoadBalancerConfigCommand: {"loadBalancers":[{"uuid":"eaa5d85c-6d81-43dc-b2a2-9431f2cb9c12","srcIp":"10.102.195.19","srcPort":22,"protocol":"tcp","algorithm":"roundrobin","revoked":true,"alreadyAdded":false,"inline":false,"destinations":[{"destIp":"10.2.113.88","destPort":22,"revoked":true,"alreadyAdded":false},{"destIp":"10.2.112.78","destPort":22,"revoked":true,"alreadyAdded":false}],"healthCheckPolicies":[{"pingPath":"/","responseTime":2,"healthcheckInterval":5,"healthcheckThresshold":2,"unhealthThresshold":1,"revoke":true}]}],"lbStatsVisibility":"guest-network","lbStatsPort":"8081","lbStatsSrcCidrs":"0/0","lbStatsAuth":"admin1:AdMiN123","lbStatsUri":"/admin?stats","accessDetails":{"guest.vlan.tag":"819"},"wait":0}

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