[jira] [Updated] (CLOUDSTACK-7715) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-7715: Fix Version/s: (was: 4.5.0) 4.6.0 > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7715 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Sanjay Tripathi > Fix For: 4.6.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7925) test_lb_secondary_ip.py- test cases failing while creating port forwarding rule
Ashutosk Kelkar created CLOUDSTACK-7925:
---
Summary: test_lb_secondary_ip.py- test cases failing while
creating port forwarding rule
Key: CLOUDSTACK-7925
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7925
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Environment: Observed on VMware
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
Fix For: 4.5.0
integration.component.test_lb_secondary_ip.TestNetworkOperations.test_17_restart_router
Job failed: {jobprocstatus : 0, created : u'2014-11-16T13:57:35+',
jobresult : {errorcode : 530, errortext : u'Failed to apply port forwarding
rule'}, cmd :
u'org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd',
userid : u'3070f9f8-6d41-11e4-8648-8a3716eea435', jobstatus : 2, jobid :
u'13373f10-b4e2-4d2d-a034-fb79f7bb4869', jobresultcode : 530, jobresulttype :
u'object', jobinstancetype : u'FirewallRule', accountid :
u'3070ec2e-6d41-11e4-8648-8a3716eea435'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7924) Browser-based Template / Volume upload
Rajani Karuturi created CLOUDSTACK-7924: --- Summary: Browser-based Template / Volume upload Key: CLOUDSTACK-7924 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7924 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rajani Karuturi Assignee: Rajani Karuturi Fix For: 4.6.0 design document is at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=39620237 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5744) [Hyper-v] White screen on console window when more than two console sessions are opened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5744: Assignee: (was: Rajani Karuturi) > [Hyper-v] White screen on console window when more than two console sessions > are opened > --- > > Key: CLOUDSTACK-5744 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5744 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.3.0 > Environment: Latest build from 4.3 branch with commit: > 95b6a7b96dab1c77e25987d6fe6003b4447281f1 >Reporter: Sanjeev N > Fix For: Future > > Attachments: console.PNG, console2.PNG > > > [Hyper-v] white screen on console window when more than two console sessions > are opened > Steps to reproduce: > > 1.Bring up CS with hyperv host > 2.Deploy few guest vms > 3.Open console sessions for all the guest and system vms > Result: > === > From 3rd console window onwards we see while screen blinking on all the > further console windows. > Attaching screen shot to describe the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5724) Console Proxy View - when using ctl c , errors seen on the console proxy view.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5724: Assignee: (was: Rajani Karuturi) > Console Proxy View - when using ctl c , errors seen on the console proxy view. > -- > > Key: CLOUDSTACK-5724 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5724 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan > Fix For: Future > > Attachments: cpv-ctlc.png > > > Console Proxy View - when using ctl c , errors seen on the console proxy view. > Set up: > Advanced zone set up with KVM (rhel 6.3) hosts. > Deploy few Vms. > Steps to reproduce the problem: > Launch console proxy view of the VM. > Try using ctl c. > We see the following exception on the screen: > atkdb.c: Unknow key pressed (translated set 2 , code 0x0 on isa0060/serio0) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5753) [Hyper-v] ConsoleProxyLoadReportCommand does not honor the default value of consoleproxy.loadscan.interval which is 10sec
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-5753:
Assignee: (was: Rajani Karuturi)
> [Hyper-v] ConsoleProxyLoadReportCommand does not honor the default value of
> consoleproxy.loadscan.interval which is 10sec
> -
>
> Key: CLOUDSTACK-5753
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5753
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller
>Affects Versions: 4.3.0
> Environment: Latest build from 4.3branch with commit:
> 95b6a7b96dab1c77e25987d6fe6003b4447281f1
>Reporter: Sanjeev N
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: Future
>
>
> [Hyper-v] ConsoleProxyLoadReportCommand does not honor the default value of
> consoleproxy.loadscan.interval which is 10sec
> Steps to reproduce:
> ===
> 1.Bring up CS in advanced zone with Hyper-v cluster
> 2.Wait for the system vms to come up.
> 3.Deploy one guest vm with default centos template
> 4.Observe MS log for events related to ConsoleProxyLoadReportCommand
> Result:
> ==
> ConsoleProxyLoadReportCommand is getting executed for every 5 sec. However
> the default value for consoleproxy.loadscan.interval is set to 10sec. So the
> command should be exected at 10sec interval.
> Few events grepped for the above command:
> [root@RIAK-57 ~]# tail -f
> /var/log/cloudstack/management/management-server.log | grep
> ConsoleProxyLoadReportCommand
> 2014-01-03 12:56:10,881 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 4-11496: Processing Seq 4-11496: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-01-03 12:56:15,885 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-5:null) SeqA 4-11497: Processing Seq 4-11497: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-01-03 12:56:20,889 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-12:null) SeqA 4-11498: Processing Seq 4-11498: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-01-03 12:56:25,933 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 4-11500: Processing Seq 4-11500: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-01-03 12:56:30,896 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-10:null) SeqA 4-11501: Processing Seq 4-11501: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6063) CLONE - Non windows instances are created on XenServer with a vcpu-max above supported xenserver limits
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala updated CLOUDSTACK-6063:
Fix Version/s: (was: 4.5.0)
Future
> CLONE - Non windows instances are created on XenServer with a vcpu-max above
> supported xenserver limits
> ---
>
> Key: CLOUDSTACK-6063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6063
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: Future, 4.2.1, 4.3.0
>Reporter: Nitin Mehta
>Assignee: Harikrishna Patnala
> Fix For: Future
>
>
> CitrixResourceBase.java contains a hardcoded value for vcpusmax for non
> windows instances:
> if (guestOsTypeName.toLowerCase().contains("windows")) {
> vmr.VCPUsMax = (long) vmSpec.getCpus();
> } else {
> vmr.VCPUsMax = 32L;
> }
> For all currently available versions of XenServer the limit is 16vcpus:
> http://support.citrix.com/servlet/KbServlet/download/28909-102-664115/XenServer-6.0-Configuration-Limits.pdf
> http://support.citrix.com/servlet/KbServlet/download/32312-102-704653/CTX134789%20-%20XenServer%206.1.0_Configuration%20Limits.pdf
> http://support.citrix.com/servlet/KbServlet/download/34966-102-706122/CTX137837_XenServer%206_2_0_Configuration%20Limits.pdf
> In addition there seems to be a limit to the total amount of assigned vpcus
> on a XenServer.
> The impact of this bug is that xapi becomes unstable and keeps losing it's
> master_connection because the POST to the /remote_db_access is bigger then
> it's limit of 200K. This basically renders a pool slave unmanageable.
> If you would look at the running instances using xentop you will see hosts
> reporting with 32 vcpus
> Below the relevant portion of the xensource.log that shows the effect of the
> bug:
> [20140204T13:52:17.264Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin
> R:e58e985539ab|master_connection] stunnel: Using commandline:
> /usr/sbin/stunnel -fd f3b8bb12-4e03-b47a-0dc5-85ad5aef79e6
> [20140204T13:52:17.269Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin
> R:e58e985539ab|master_connection] stunnel: stunnel has pidty: (FEFork
> (43,30540))
> [20140204T13:52:17.269Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin
> R:e58e985539ab|master_connection] stunnel: stunnel start
> [20140204T13:52:17.269Z| info|xenserverhost1|144 inet-RPC|host.call_plugin
> R:e58e985539ab|master_connection] stunnel connected pid=30540 fd=40
> [20140204T13:52:17.346Z|error|xenserverhost1|144 inet-RPC|host.call_plugin
> R:e58e985539ab|master_connection] Received HTTP error 500 ({ method = POST;
> uri = /remote_db_access; query = [ ]; content_length = [ 315932 ]; transfer
> encoding = ; version = 1.1; cookie = [
> pool_secret=386bbf39-8710-4d2d-f452-9725d79c2393/aa7bcda9-8ebb-0cef-bb77-c6b496c5d859/1f928d82-7a20-9117-dd30-f96c7349b16e
> ]; task = ; subtask_of = ; content-type = ; user_agent = xapi/1.9 }) from
> master. This suggests our master address is wrong. Sleeping for 60s and then
> restarting.
> [20140204T13:53:18.620Z|error|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] Caught Master_connection.Goto_handler
> [20140204T13:53:18.620Z|debug|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] Connection to master died. I will continue
> to retry indefinitely (supressing future logging of this message).
> [20140204T13:53:18.620Z|error|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] Connection to master died. I will continue
> to retry indefinitely (supressing future logging of this message).
> [20140204T13:53:18.620Z|debug|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] Sleeping 2.00 seconds before retrying
> master connection...
> [20140204T13:53:20.627Z|debug|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] stunnel: Using commandline:
> /usr/sbin/stunnel -fd 3c8aed8e-1fce-be7c-09f8-b45cdc40a1f5
> [20140204T13:53:20.632Z|debug|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] stunnel: stunnel has pidty: (FEFork
> (23,31207))
> [20140204T13:53:20.632Z|debug|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] stunnel: stunnel start
> [20140204T13:53:20.632Z| info|xenserverhost1|10|dom0 networking update
> D:5c5376f0da6c|master_connection] stunnel connected pid=31207 fd=20
> [20140204T13:53:28.874Z|error|xenserverhost1|4
> unix-RPC|session.login_with_password D:2e7664ad69ed|master_connection] Caught
> Master_connection.Goto_handler
> [2014
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Open (was: Reviewable) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.r
[jira] [Created] (CLOUDSTACK-7923) RabbitMQ integration, make SSL protocol configurable rather than hard coded
Damodar Reddy T created CLOUDSTACK-7923: --- Summary: RabbitMQ integration, make SSL protocol configurable rather than hard coded Key: CLOUDSTACK-7923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7923 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0, 4.5.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: 4.5.0 In the current RabbitMQ integration implementation we are using default SSL Context which uses SSLv3 by default. Make it configurable so that let the users decide which protocol to be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214229#comment-14214229 ] Rajesh Battala commented on CLOUDSTACK-7364: I saw public vlan is bouned to public interface. let me check whether public ip is bouned to vlan. > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz, screenshot-1.png, > screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francois Gaudreault updated CLOUDSTACK-7364: Attachment: screenshot-2.png > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz, screenshot-1.png, > screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francois Gaudreault updated CLOUDSTACK-7364: Attachment: screenshot-1.png > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz, screenshot-1.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214207#comment-14214207 ] Francois Gaudreault commented on CLOUDSTACK-7364: - On my NetScaler, I don't see the public IP bound to a VLAN. Only the private IP is bound to a VLAN. I added a screen capture. > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214205#comment-14214205 ] Rajesh Battala commented on CLOUDSTACK-7364: we are binding the public vlan to (1/1) mentioned public interface in cloudstack in Netscaler device. >From the code, we are binding the vlan to nsip similar like private ip. > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7774) Description field is missing in Health policy API's
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala resolved CLOUDSTACK-7774.
Resolution: Fixed
> Description field is missing in Health policy API's
> ---
>
> Key: CLOUDSTACK-7774
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7774
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
> Fix For: 4.5.0
>
>
> Load balancer Health Policy API's does not return description field.
> API's:
> listLBHealthCheckPolicies
> createLBHealthCheckPolicy
> updateLBHealthCheckPolicy
> Example:
> When we call listLBHealthCheckPolicies API, following is the resultant json.
> { "listlbhealthcheckpoliciesresponse" : { "count":1 ,"healthcheckpolicies" :
> [
> {"lbruleid":"318c4fcb-1c49-473d-a065-ba730b81840b","account":"newcorp","domainid":"4415b414-b742-4540-987f-835edaafc9bc","domain":"AA04","healthcheckpolicy":[{"id":"67167ce7-c31c-47fc-b370-d1a70837e908","pingpath":"/","responsetime":2,"healthcheckinterval":5,"healthcheckthresshold":2,"unhealthcheckthresshold":1}]}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
