cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abhinav Roy (JIRA)" <j...@apache.org>
Subject [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
Date Tue, 02 Apr 2013 12:21:15 GMT

     [ 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

Mime
View raw message