[jira] [Commented] (CLOUDSTACK-2919) Snapshot cannot be saved to full Secondary Storage, but doesn't utilize other Secondary Storage locations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077309#comment-14077309 ] yabinliu commented on CLOUDSTACK-2919: -- May I know this issue will be fixed in which version? Or in all supported versions? In addition, please note the template or ISO have the same issue. > Snapshot cannot be saved to full Secondary Storage, but doesn't utilize other > Secondary Storage locations > - > > Key: CLOUDSTACK-2919 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2919 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.5.0 > > > This issue was noticed when a customer attempted to take a snapshot but > failed. > Logs revealed that the Secondary Storage to which CS was trying to save the > Snapshot had no more free space. > CS did retry multiple times to save to the same Secondary Storage location > after the initial failure but with no success. > However, CS failed to notice two other Secondary Storage locations in the same > zone with enough free space for a successful snapshot. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3294) CLONE - System VMs not coming up due to “InsufficientServerCapacityException”.(not consistently reproducible)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-3294: Labels: GoletaReviewNeeded (was: ) > CLONE - System VMs not coming up due to > “InsufficientServerCapacityException”.(not consistently reproducible) > - > > Key: CLOUDSTACK-3294 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3294 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: Future > > Attachments: management-server.zip > > > Seps:t > 1.Have a CS with advanced zone . > 2.Created some user VMs. > 3.Created VPCs and VMs under VPCs. > 4.Shutdown the Host(Xen) and MS. > 5.Start the Host and MS. > Observation: > The SSVM and CPVM were not coming up with > “InsufficientServerCapacityException” exception. > The Dashboard was showing exhausted management IPs . > Deleted all the VMS ,still the IPs were not released. > Below is the table which shows that all the management ips are reserved. > mysql> select * from op_dc_ip_address_alloc; > ++---++++--+-+-+ > | id | ip_address| data_center_id | pod_id | nic_id | reservation_id > | taken | mac_address | > ++---++++--+-+-+ > | 1 | 10.147.40.181 | 1 | 1 | 34 | > 48d95839-6fb1-4bc4-b23a-c9f1891bf1fa | 2013-05-31 17:10:06 | 1 | > | 2 | 10.147.40.182 | 1 | 1 | 3 | > a7b9610c-9319-478c-84e4-e70be099cd9d | 2013-05-31 17:07:29 | 2 | > | 3 | 10.147.40.183 | 1 | 1 | 7 | > 238830cd-8cbe-411e-8016-352129885df6 | 2013-05-31 17:07:30 | 3 | > | 4 | 10.147.40.184 | 1 | 1 | 7 | > 70f091d4-acb4-435b-bfde-9bdb35bcfa6b | 2013-05-31 17:09:15 | 4 | > | 5 | 10.147.40.185 | 1 | 1 | 29 | > 14690352-e9a0-4695-a834-0552175f7684 | 2013-05-31 17:08:45 | 5 | > | 6 | 10.147.40.186 | 1 | 1 | 30 | > 14690352-e9a0-4695-a834-0552175f7684 | 2013-05-31 17:08:45 | 6 | > | 7 | 10.147.40.187 | 1 | 1 | 4 | > a7b9610c-9319-478c-84e4-e70be099cd9d | 2013-05-31 17:07:29 | 7 | > | 8 | 10.147.40.188 | 1 | 1 | 7 | > ea8644d1-7801-4dbb-aa0c-204f31e922a1 | 2013-05-31 17:08:25 | 8 | > | 9 | 10.147.40.189 | 1 | 1 | 7 | > 245e0082-d697-454d-9689-b36cc3b6e113 | 2013-05-31 17:11:16 | 9 | > | 10 | 10.147.40.190 | 1 | 1 | 7 | > 094e371a-da69-44e0-80fd-14c2d090e935 | 2013-05-31 17:10:15 | 10 | > ++---++++--+-+-+ > As all the IPs were in reserved state ,SSVM and CPVM were not coming up. > Was not able to reproduce this issue again . > Attached is the server log. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3294) CLONE - System VMs not coming up due to “InsufficientServerCapacityException”.(not consistently reproducible)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-3294: Labels: (was: GoletaReviewNeeded) > CLONE - System VMs not coming up due to > “InsufficientServerCapacityException”.(not consistently reproducible) > - > > Key: CLOUDSTACK-3294 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3294 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: Future > > Attachments: management-server.zip > > > Seps:t > 1.Have a CS with advanced zone . > 2.Created some user VMs. > 3.Created VPCs and VMs under VPCs. > 4.Shutdown the Host(Xen) and MS. > 5.Start the Host and MS. > Observation: > The SSVM and CPVM were not coming up with > “InsufficientServerCapacityException” exception. > The Dashboard was showing exhausted management IPs . > Deleted all the VMS ,still the IPs were not released. > Below is the table which shows that all the management ips are reserved. > mysql> select * from op_dc_ip_address_alloc; > ++---++++--+-+-+ > | id | ip_address| data_center_id | pod_id | nic_id | reservation_id > | taken | mac_address | > ++---++++--+-+-+ > | 1 | 10.147.40.181 | 1 | 1 | 34 | > 48d95839-6fb1-4bc4-b23a-c9f1891bf1fa | 2013-05-31 17:10:06 | 1 | > | 2 | 10.147.40.182 | 1 | 1 | 3 | > a7b9610c-9319-478c-84e4-e70be099cd9d | 2013-05-31 17:07:29 | 2 | > | 3 | 10.147.40.183 | 1 | 1 | 7 | > 238830cd-8cbe-411e-8016-352129885df6 | 2013-05-31 17:07:30 | 3 | > | 4 | 10.147.40.184 | 1 | 1 | 7 | > 70f091d4-acb4-435b-bfde-9bdb35bcfa6b | 2013-05-31 17:09:15 | 4 | > | 5 | 10.147.40.185 | 1 | 1 | 29 | > 14690352-e9a0-4695-a834-0552175f7684 | 2013-05-31 17:08:45 | 5 | > | 6 | 10.147.40.186 | 1 | 1 | 30 | > 14690352-e9a0-4695-a834-0552175f7684 | 2013-05-31 17:08:45 | 6 | > | 7 | 10.147.40.187 | 1 | 1 | 4 | > a7b9610c-9319-478c-84e4-e70be099cd9d | 2013-05-31 17:07:29 | 7 | > | 8 | 10.147.40.188 | 1 | 1 | 7 | > ea8644d1-7801-4dbb-aa0c-204f31e922a1 | 2013-05-31 17:08:25 | 8 | > | 9 | 10.147.40.189 | 1 | 1 | 7 | > 245e0082-d697-454d-9689-b36cc3b6e113 | 2013-05-31 17:11:16 | 9 | > | 10 | 10.147.40.190 | 1 | 1 | 7 | > 094e371a-da69-44e0-80fd-14c2d090e935 | 2013-05-31 17:10:15 | 10 | > ++---++++--+-+-+ > As all the IPs were in reserved state ,SSVM and CPVM were not coming up. > Was not able to reproduce this issue again . > Attached is the server log. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077062#comment-14077062
]
Sheng Yang edited comment on CLOUDSTACK-7186 at 7/28/14 11:59 PM:
--
I would revert it and ask Koushik to check it.
was (Author: yasker):
I would revert it and ask Koushik check it.
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,181 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 2-4214524826288652385: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang resolved CLOUDSTACK-7186.
Resolution: Fixed
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,181 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 2-4214524826288652385: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-7182) NPE while trying to deploy VMs in parallel in isolated network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang reopened CLOUDSTACK-7182: This commit breaks VPC, result in CLOUDSTACK-7186. I have to revert it. Koushik, could you check again? > NPE while trying to deploy VMs in parallel in isolated network > -- > > Key: CLOUDSTACK-7182 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7182 > 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 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > Repro steps: > - Create an account > - Deploy around 50 VMs in parallel in a new network (VR not created) > This is a race condition and NPE is not always hit. Below is the log snippet. > 2014-03-06 12:20:15,121 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Creating VIF for i-4-98-VM on nic > [Nic:Guest-10.1.1.105-null] > 2014-03-06 12:20:15,127 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Catch Exception: class > java.lang.NullPointerException due to java.lang.NullPointerException > java.lang.NullPointerException > at > com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173) > at > com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47) > 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:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:701) > 2014-03-06 12:20:15,128 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Unable to start i-4-98-VM due to > java.lang.NullPointerException > at > com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173) > at > com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable
[jira] [Commented] (CLOUDSTACK-7182) NPE while trying to deploy VMs in parallel in isolated network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077092#comment-14077092 ] ASF subversion and git services commented on CLOUDSTACK-7182: - Commit f47cfc6eb16bf0fa5830327207a2d3fdf24ab700 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f47cfc6 ] CLOUDSTACK-7186: Revert "CLOUDSTACK-7182: NPE while trying to deploy VMs in parallel in isolated network" This reverts commit 47d6a64b319ab064c4b855346f2bfdb250fb9ad8, which broke VPC completely. > NPE while trying to deploy VMs in parallel in isolated network > -- > > Key: CLOUDSTACK-7182 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7182 > 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 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > Repro steps: > - Create an account > - Deploy around 50 VMs in parallel in a new network (VR not created) > This is a race condition and NPE is not always hit. Below is the log snippet. > 2014-03-06 12:20:15,121 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Creating VIF for i-4-98-VM on nic > [Nic:Guest-10.1.1.105-null] > 2014-03-06 12:20:15,127 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Catch Exception: class > java.lang.NullPointerException due to java.lang.NullPointerException > java.lang.NullPointerException > at > com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173) > at > com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47) > 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:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:701) > 2014-03-06 12:20:15,128 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-233:ctx-210c1052) Unable to start i-4-98-VM due to > java.lang.NullPointerException > at > com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173) > at > com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.execut
[jira] [Commented] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077090#comment-14077090
]
ASF subversion and git services commented on CLOUDSTACK-7186:
-
Commit f47cfc6eb16bf0fa5830327207a2d3fdf24ab700 in cloudstack's branch
refs/heads/master from [~yasker]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f47cfc6 ]
CLOUDSTACK-7186: Revert "CLOUDSTACK-7182: NPE while trying to deploy VMs in
parallel in isolated network"
This reverts commit 47d6a64b319ab064c4b855346f2bfdb250fb9ad8, which broke VPC
completely.
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,181 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 2-4214524826288652385: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7196) listVpcOfferings/listNetworkOfferings/listVpcs - a) pagination is broken b) "count" parameter doesn't return the actual count, but requested pageSize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-7196. --- Resolution: Fixed Fixed with: commit 477f91327c4c0d11ea39cc2327409f6053238c24 Author: Alena Prokharchyk Date: Mon Jul 28 15:06:14 2014 -0700 CS-19072: fixed broken pagination and count in listVpcs commit fa74b3a300a679f3e47a3fac13fab323cda34cf3 Author: Alena Prokharchyk Date: Mon Jul 28 14:41:50 2014 -0700 CS-19072: fixed broken pagination and count in listVpcOfferings commit 8b98cc22028ce867671cc360ad81a764b44be88a Author: Alena Prokharchyk Date: Mon Jul 28 14:25:46 2014 -0700 CS-19072: fixed broken pagination and count in listNetworkOfferings > listVpcOfferings/listNetworkOfferings/listVpcs - a) pagination is broken b) > "count" parameter doesn't return the actual count, but requested pageSize > - > > Key: CLOUDSTACK-7196 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7196 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > a) For listVpcOfferings/listNetworkOfferings/listVpcs we do some post > processing after requesting the data from the db based on search parameters. > This post processing breaks pagination. > b) "count" parameter doesn't return the actual number of entries satisfying > the search criteria, but rather returns the requested page size. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077062#comment-14077062
]
Sheng Yang commented on CLOUDSTACK-7186:
I would revert it and ask Koushik check it.
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,181 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 2-4214524826288652385: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077039#comment-14077039
]
Sheng Yang commented on CLOUDSTACK-7186:
After 4 hours of "git bisect", found it caused by:
yasker@yasker-devbox:~/develop/cloudstack-oss$ git bisect good
47d6a64b319ab064c4b855346f2bfdb250fb9ad8 is the first bad commit
commit 47d6a64b319ab064c4b855346f2bfdb250fb9ad8
Author: Koushik Das
Date: Fri Jul 25 15:17:35 2014 +0530
CLOUDSTACK-7182: NPE while trying to deploy VMs in parallel in isolated
network
The following changes are made:
- Check to see if network is implemented changed from 'state ==
Implementing||Implemented' to 'state == Implemented'.
The earlier check was a hack to prevent the issue described below.
- At the time of implementing network (using implementNetwork() method), if
the VR needs to be deployed then
it follows the same path of regular VM deployment. This leads to a nested
call to implementNetwork() while
preparing VR nics. This flow creates issues in dealing with network state
transitions. The original call
puts network in "Implementing" state and then the nested call again tries
to put it into same state resulting
in issues. In order to avoid it, implementNetwork() call for VR is replaced
with below code.
:04 04 ec5b50fd35e5b8f9e8128fcd67b1d470e3b0993d
be498171617417358348ad4fcf8f02f946f7a637 M engine
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":
[jira] [Created] (CLOUDSTACK-7197) Upgrade 4.2 to 4.4 failed, because of 4.3 template is not installed
edison su created CLOUDSTACK-7197: - Summary: Upgrade 4.2 to 4.4 failed, because of 4.3 template is not installed Key: CLOUDSTACK-7197 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7197 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Environment: 4.2 management server + kvm host, 4.5 KVM template is downloaded through url before upgrade. Reporter: edison su Assignee: Kishan Kavala Fix For: 4.5.0 After upgraded to 4.5 management server, management server failed to start: 2014-07-28 14:55:23,608 DEBUG [c.c.u.d.Upgrade421to430] (main:null) Done upgrading RAM for service offering of Secondary Storage VM to 512 2014-07-28 14:55:23,608 DEBUG [c.c.u.d.Upgrade421to430] (main:null) Updating System Vm template IDs 2014-07-28 14:55:23,615 DEBUG [c.c.u.d.Upgrade421to430] (main:null) Updating LXC System Vms 2014-07-28 14:55:23,616 WARN [c.c.u.d.Upgrade421to430] (main:null) 4.3.0 LXC SystemVm template not found. LXC hypervisor is not used, so not failing upgrade 2014-07-28 14:55:23,618 DEBUG [c.c.u.d.Upgrade421to430] (main:null) Updating KVM System Vms 2014-07-28 14:55:23,621 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) Unable to upgrade the database com.cloud.utils.exception.CloudRuntimeException: 4.3.0 KVM SystemVm template not found. Cannot upgrade system Vms at com.cloud.upgrade.dao.Upgrade421to430.updateSystemVmTemplates(Upgrade421to430.java:298) at com.cloud.upgrade.dao.Upgrade421to430.performDataMigration(Upgrade421to430.java:73) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:326) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:447) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79) at org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61) at org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) The commit: c0f60651b94828d52407b3a6b6c47c451dabb45f, seems cause the trouble, we ne
[jira] [Commented] (CLOUDSTACK-6518) [Hyper-V] Efficient way of finding the empty nic in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076901#comment-14076901 ] ASF subversion and git services commented on CLOUDSTACK-6518: - Commit 095fb09b7519289ab0d2ae3a880c5477d0cb52cc in cloudstack's branch refs/heads/4.4 from [~rajesh_battala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=095fb09 ] CLOUDSTACK-6518 [Hyper-V] Efficient way of finding the empty nic in VR/VpcVR to configure VPC entities (cherry picked from commit cf41ccaa5b6475dace0bddbe6681c98cc5149189) Conflicts: plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/IWmiCallsV2.cs plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs > [Hyper-V] Efficient way of finding the empty nic in VR > --- > > Key: CLOUDSTACK-6518 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6518 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7178) [Automation] Escalations test cases failing with import error while importing BOOLEAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076883#comment-14076883 ] ASF subversion and git services commented on CLOUDSTACK-7178: - Commit 2025f359c4fbff6b24132d39e8cf587315a2a981 in cloudstack's branch refs/heads/4.4 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2025f35 ] CLOUDSTACK-7178: Correcting imports in test_escalations* test cases (cherry picked from commit 4e45b296891f71fc7991dc507dc7ae9cec6f5496) > [Automation] Escalations test cases failing with import error while importing > BOOLEAN > - > > Key: CLOUDSTACK-7178 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7178 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Following test cases failing while importing BOOLEAN > test_escalations_ip_addresses.py > test_escalations_snapshtos.py > Resolution: > Remove the import as it is not used anywhere in the code. > Also modify the imports to not use import * -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7148) [Automation] Fix the script "test_redundant_router_cleanups.py" - TypeError: this constructor takes no arguments
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076882#comment-14076882
]
ASF subversion and git services commented on CLOUDSTACK-7148:
-
Commit 58987452994f1abc621a2f8f7fcdd24b443cf0e9 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5898745 ]
CLOUDSTACK-7148: Adding missing list method
(cherry picked from commit dd138ceec5faa5d5b0fcdfe5cc655199b8f9187b)
> [Automation] Fix the script "test_redundant_router_cleanups.py" - TypeError:
> this constructor takes no arguments
>
>
> Key: CLOUDSTACK-7148
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7148
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.5.0
>
>
> self.assertEqual(
> len(routers),
> 2,
> "Length of the list router should be 2 (Backup & master)"
> )
> self.debug("Stopping the user VM: %s" % virtual_machine.name)
> try:
> virtual_machine.stop(self.apiclient)
> except Exception as e:
> self.fail("Failed to stop guest Vm: %s - %s" %
> (virtual_machine.name, e))
> interval = Configurations( <-- BUG: Missing "list" method
> self.apiclient,
> name='network.gc.interval'
> )
> delay = int(interval[0].value)
> interval = Configurations.list(
> self.apiclient,
> name='network.gc.wait'
> )
> exp = int(interval[0].value)
> self.debug("Sleeping for network gc wait + interval time")
> # Sleep to ensure that all resources are deleted
> time.sleep((delay + exp) * 2)
>
> Error Message:
>
> est_network_gc
> (integration.component.test_redundant_router_cleanups.TestRedundantRouterNetworkCleanups):
> DEBUG: Sending GET Cmd : listVirtualMachines===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.135.41
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA&id=ecabe928-5dd9-4f53-a5b1-c758e664ac28&response=json&command=listVirtualMachines&signature=%2Fu2ByYo%2F3d%2BN3YRaFn00CddqfgA%3D&listAll=True
> HTTP/1.1" 200 1374
> test_network_gc
> (integration.component.test_redundant_router_cleanups.TestRedundantRouterNetworkCleanups):
> DEBUG: Response : [{domain : u'ROOT', domainid :
> u'ae89b9d2-0901-11e4-a9bc-5a9383355ca2', haenable : False, templatename :
> u'CentOS 5.6(64-bit) no GUI (XenServer)', securitygroup : [], zoneid :
> u'9f076f9c-266e-4d26-b6b5-05e197181167', cpunumber : 1, ostypeid : 142,
> passwordenabled : False, instancename : u'i-376-589-VM', id :
> u'ecabe928-5dd9-4f53-a5b1-c758e664ac28', displayvm : True, state :
> u'Stopped', guestosid : u'aea0f246-0901-11e4-a9bc-5a9383355ca2', cpuspeed :
> 100, serviceofferingid : u'956b0c1a-94a2-42e8-97a4-ed5cc4ff8afd', zonename :
> u'XenRT-Zone-0', isdynamicallyscalable : True, displayname : u'Test VM', tags
> : [], nic : [{networkid : u'4e47e163-7ee2-4bd2-807d-d53867768688', macaddress
> : u'02:00:0b:4c:00:01', type : u'Isolated', id :
> u'd0ac745f-c73f-43d6-847c-665067c70bb3', traffictype : u'Guest', netmask :
> u'255.255.255.0', ipaddress : u'192.168.200.253', networkname : u'Test
> Network', gateway : u'192.168.200.1', isdefault : True}], memory : 128,
> templateid : u'ae8e25a8-0901-11e4-a9bc-5a9383355ca2', affinitygroup : [],
> account : u'test-TestRedundantRouterNetworkCleanups-test_network_gc-YG37AT',
> name : u'VM-ecabe928-5dd9-4f53-a5b1-c758e664ac28', created :
> u'2014-07-12T12:49:11+', hypervisor : u'XenServer', rootdevicetype :
> u'ROOT', rootdeviceid : 0, serviceofferingname : u'Tiny Instance',
> templatedisplaytext : u'CentOS 5.6(64-bit) no GUI (XenServer)'}]
> test_network_gc
> (integration.component.test_redundant_router_cleanups.TestRedundantRouterNetworkCleanups):
> CRITICAL: EXCEPTION: test_network_gc: ['Traceback (most recent call
> last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 332, in run\n
> testMethod()\n', ' File
> "/home/j
[jira] [Commented] (CLOUDSTACK-7024) [Automation] Deletion of Account that manages a project failed during cleanup of TestTemplateUsage Tests
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076879#comment-14076879
]
ASF subversion and git services commented on CLOUDSTACK-7024:
-
Commit f055ec52d9d751df86e42aeb6a2aace2ceea4567 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f055ec5 ]
CLOUDSTACK-7024: Resolved cleanup issue in test script
(cherry picked from commit ec49669f1cf525b207889ae13a8a2b01a0271933)
> [Automation] Deletion of Account that manages a project failed during cleanup
> of TestTemplateUsage Tests
>
>
> Key: CLOUDSTACK-7024
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7024
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> =
> Error Message:
> =
> Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
> u'2014-06-26T05:54:00+', cmd :
> u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid :
> u'57dd7fb6-fc58-11e3-919f-4eba41a459a4', jobstatus : 2, jobid :
> u'0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u"The account id=313
> manages project(s) with ids 40, and can't be removed"}, accountid :
> u'57dd7098-fc58-11e3-919f-4eba41a459a4'}
> >> begin captured logging <<
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: Payload:
> {'signature': 'umKBWTVC8csMC7iBWcrmlZP7Bns=', 'apiKey':
> u'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q',
> 'command': 'deleteAccount', 'id': u'6096abdb-9fe1-45ef-af30-6ecca7210515',
> 'response': 'json'}
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG:
> Sending GET Cmd : deleteAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.153.217
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?signature=umKBWTVC8csMC7iBWcrmlZP7Bns%3D&apiKey=Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q&command=deleteAccount&id=6096abdb-9fe1-45ef-af30-6ecca7210515&response=json
> HTTP/1.1" 200 78
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: ===
> Jobid: 0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d Started ===
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: Payload:
> {'signature': '6MrHAB+DBVozv8OPtH8iU4S5bOc=', 'apiKey':
> u'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q',
> 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
> u'0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d'}
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG:
> Sending GET Cmd : queryAsyncJobResult===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.153.217
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?signature=6MrHAB%2BDBVozv8OPtH8iU4S5bOc%3D&apiKey=Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q&command=queryAsyncJobResult&response=json&jobid=0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d
> HTTP/1.1" 200 343
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: Response
> : {jobprocstatus : 0, created : u'2014-06-26T05:54:00+', cmd :
> u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid :
> u'57dd7fb6-fc58-11e3-919f-4eba41a459a4', jobstatus : 0, jobid :
> u'0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d', jobresultcode : 0, accountid :
> u'57dd7098-fc58-11e3-919f-4eba41a459a4'}
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: ===
> JobId:0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d is Still Processing, Will TimeOut
> in:3595
> test_01_template_usage
> (integration.component.test_project_usage.TestTemplateUsage): DEBUG: Payload:
> {'signature': '6MrHAB+DBVozv8OPtH8iU4S5bOc=', 'apiKey':
> u'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q',
> 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
> u'0cf64ae7-f95c-4c46-a3ce-42f2c318ed3d'}
> test_01_te
[jira] [Commented] (CLOUDSTACK-7013) [Automation] "AttributeError: type object 'TestFailureScenariosRemoveNicFromVM' has no attribute 'append'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076877#comment-14076877
]
ASF subversion and git services commented on CLOUDSTACK-7013:
-
Commit 6b66fe92ca89633ec64397cedb0d1572d0089c93 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b66fe9 ]
CLOUDSTACK-7013: Fixing test script issue in test_add_remove_network.py
(cherry picked from commit f99a96f38a1f2433cb01bd7af25890789716e070)
> [Automation] "AttributeError: type object
> 'TestFailureScenariosRemoveNicFromVM' has no attribute 'append'
> -
>
> Key: CLOUDSTACK-7013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7013
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> ==
> Bug in test script:
> ==
> cls.account =
> Account.create(cls.api_client,cls.services["account"],domainid =
> cls.domain.id)
> cls.append(cls.account) > BUG: should be cls.__cleanup.append
> cls.service_offering =
> ServiceOffering.create(cls.api_client,cls.services["service_offering"])
> cls._cleanup.append(cls.service_offering)
>
> Test Script Failure:
>
> test_26_add_nic_insufficient_permission
> (integration.component.test_add_remove_network.TestFailureScenariosAddNetworkToVM):
> CRITICAL: EXCEPTION: test_26_add_nic_insufficient_permission: ['Traceback
> (most recent call last):\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 208, in run\n
> self.setUp()\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 291, in setUp\n
> self.setupContext(ancestor)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 314, in
> setupContext\ntry_run(context, names)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in try_run\n
>return func()\n', ' File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_add_remove_network.py",
> line 1392, in setUpClass\ncls.append(cls.account)\n', "AttributeError:
> type object 'TestFailureScenariosRemoveNicFromVM' has no attribute
> 'append'\n"]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 208, in
> run
> self.setUp()
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 291, in
> setUp
> self.setupContext(ancestor)
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 314, in
> setupContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in
> try_run
> return func()
> File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_add_remove_network.py",
> line 1392, in setUpClass
> cls.append(cls.account)
> 'type object \'TestFailureScenariosRemoveNicFromVM\' has no attribute
> \'append\'\n >> begin captured logging <<
> \ntest_26_add_nic_insufficient_permission
> (integration.component.test_add_remove_network.TestFailureScenariosAddNetworkToVM):
> DEBUG: Payload: {\'apiKey\':
> u\'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q\',
> \'id\': u\'853b13be-4f75-4ca9-9f7c-3cf303d3cc2d\', \'state\': \'Disabled\',
> \'command\': \'updateNetworkOffering\', \'signature\':
> \'pP6GEHIbIDVHMxeYxAyQahpCxbI=\', \'response\':
> \'json\'}\ntest_26_add_nic_insufficient_permission
> (integration.component.test_add_remove_network.TestFailureScenariosAddNetworkToVM):
> DEBUG: Sending GET Cmd :
> updateNetworkOffering===\nrequests.packages.urllib3.connectionpool: INFO:
> Starting new HTTP connection (1):
> 10.220.153.217\nrequests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q&id=853b13be-4f75-4ca9-9f7c-3cf303d3cc2d&state=Disabled&command=updateNetworkOffering&signature=pP6GEHIbIDVHMxeYxAyQahpCxbI%3D&response=json
> HTTP/1.1" 200
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7137) [Automation] Fix the script "test_escalations_securitygroups.py" - Unable to execute API command deletesecuritygroup due to invalid value.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076881#comment-14076881 ] ASF subversion and git services commented on CLOUDSTACK-7137: - Commit 1ca9abd6dc8013dd1dc4e4f9ca1eabb71785cc37 in cloudstack's branch refs/heads/4.4 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1ca9abd ] CLOUDSTACK-7137: Resolving cleanup issue in test_escalations_securitygroups.py (cherry picked from commit 8d8190ea4e00edb0f7ce9665535adcc7a5b5097d) > [Automation] Fix the script "test_escalations_securitygroups.py" - Unable to > execute API command deletesecuritygroup due to invalid value. > -- > > Key: CLOUDSTACK-7137 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7137 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Ashutosk Kelkar >Priority: Critical > Fix For: 4.5.0 > > > > Error Message: > > test_01_list_securitygroups_pagination > (integration.component.test_escalations_securitygroups.TestSecurityGroups): > DEBUG: Sending GET Cmd : deleteSecurityGroup=== > requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection > (1): 10.220.135.73 > requests.packages.urllib3.connectionpool: DEBUG: "GET > /client/api?apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA&response=json&command=deleteSecurityGroup&signature=JB2or4xVThMUY0Pob4shmnqTe5s%3D&id=66eeb3b4-3b3d-4037-8483-7ed1a1485893 > HTTP/1.1" 431 370 > test_01_list_securitygroups_pagination > (integration.component.test_escalations_securitygroups.TestSecurityGroups): > ERROR: Exception:['Traceback (most recent call last):\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 308, in __parseAndGetResponse\nresponse_cls)\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 150, in getResultObj\nraise > cloudstackException.CloudstackAPIException(respname, errMsg)\n', > 'CloudstackAPIException: Execute cmd: deletesecuritygroup failed, due to: > errorCode: 431, errorText:Unable to execute API command deletesecuritygroup > due to invalid value. Invalid parameter id > value=66eeb3b4-3b3d-4037-8483-7ed1a1485893 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class.\n'] > Traceback (most recent call last): > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 308, in __parseAndGetResponse > response_cls) > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 150, in getResultObj > raise cloudstackException.CloudstackAPIException(respname, errMsg) > CloudstackAPIException: Execute cmd: deletesecuritygroup failed, due to: > errorCode: 431, errorText:Unable to execute API command deletesecuritygroup > due to invalid value. Invalid parameter id > value=66eeb3b4-3b3d-4037-8483-7ed1a1485893 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class. > test_01_list_securitygroups_pagination > (integration.component.test_escalations_securitygroups.TestSecurityGroups): > ERROR: marvinRequest : CmdName: > 0x276fa90> Exception: ['Traceback (most recent call last):\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 375, in marvinRequest\nraise self.__lastError\n', > 'CloudstackAPIException: Execute cmd: deletesecuritygroup failed, due to: > errorCode: 431, errorText:Unable to execute API command deletesecuritygroup > due to invalid value. Invalid parameter id > value=66eeb3b4-3b3d-4037-8483-7ed1a1485893 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class.\n'] > Traceback (most recent call last): > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 375, in marvinRequest > raise self.__lastError > CloudstackAPIException: Execute cmd: deletesecuritygroup failed, du
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076875#comment-14076875 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 4a99cf851966512ae90633b7ed7d7954b6d0ac9a in cloudstack's branch refs/heads/4.4 from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a99cf8 ] CLOUDSTACK-5674:Fixed pep8 errors in python files in marvin folder Signed-off-by: SrikanteswaraRao Talluri (cherry picked from commit 4f1f182cba5579da2fc7ce1f02019a0afa00efeb) Conflicts: tools/marvin/marvin/lib/base.py > [Automation]: Enhancements to accommodate multiple regression runs on a > single CS server > > > Key: CLOUDSTACK-5674 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. Currently, we will not be able to run multiple regression runs on a given > CS server either sequentially\parallelly reason being few hard codings done > at various places. > 2. So, the idea is to run complete regression\automation test suites at one > stretch on a given setup post deployDC. We deploy multiple zones with > different hypervisor type in each zone. > 3. Tests should cut down time and run across multiple zones with different > hypervisor type in each zone, post deployment > 3. The fixes and new changes should incorporate to take care to run suites > parallelly if we wanted or sequentially for various test suites like > vmware,xen,kvm etc on single CS machine without disturbing\redeploying and > installing the new CS instance. > Phase1: We will make framework\marvin changes. > Phase2: Incorporate test module changes for these. > Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7196) listVpcOfferings/listNetworkOfferings/listVpcs - a) pagination is broken b) "count" parameter doesn't return the actual count, but requested pageSize
Alena Prokharchyk created CLOUDSTACK-7196: - Summary: listVpcOfferings/listNetworkOfferings/listVpcs - a) pagination is broken b) "count" parameter doesn't return the actual count, but requested pageSize Key: CLOUDSTACK-7196 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7196 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.5.0 a) For listVpcOfferings/listNetworkOfferings/listVpcs we do some post processing after requesting the data from the db based on search parameters. This post processing breaks pagination. b) "count" parameter doesn't return the actual number of entries satisfying the search criteria, but rather returns the requested page size. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6623) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-6623: -- Fix Version/s: (was: 4.4.0) 4.5.0 > Register template does not work as expected, when deploying simulator and xen > zones simultaneously on a single management server. > - > > Key: CLOUDSTACK-6623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > when we setup simulator and xenserver both in separate zones on a single > management server, The register template always behaves as if it is executing > on the simulator. i.e. register template is always successful and it dose not > initiate the actual download when calling the register template API against > xen-zone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6623) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076868#comment-14076868 ] edison su commented on CLOUDSTACK-6623: --- Move to 4.5, as it doesn't impact any real deployment. > Register template does not work as expected, when deploying simulator and xen > zones simultaneously on a single management server. > - > > Key: CLOUDSTACK-6623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > when we setup simulator and xenserver both in separate zones on a single > management server, The register template always behaves as if it is executing > on the simulator. i.e. register template is always successful and it dose not > initiate the actual download when calling the register template API against > xen-zone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5997) Template state changes side affects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076579#comment-14076579 ] ASF subversion and git services commented on CLOUDSTACK-5997: - Commit acc9c793708083290cfeee66ea0f7f03651a24de in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=acc9c79 ] CLOUDSTACK-5997: Make template view changes for someone who missed the view changes in 4.3 since these changes were made after 4.3 was released. Since these are idempotent there shouldnt be any issue > Template state changes side affects > --- > > Key: CLOUDSTACK-5997 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6980) UI for RegisterTemplate API does not expose requireshvm parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076564#comment-14076564 ] ASF subversion and git services commented on CLOUDSTACK-6980: - Commit 32e8fda965252322eccda01e14f854051d665ed0 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=32e8fda ] Fixed CLOUDSTACK-6980: UI for RegisterTemplate API does not expose requireshvm parameter > UI for RegisterTemplate API does not expose requireshvm parameter > - > > Key: CLOUDSTACK-6980 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6980 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > > requireshvm parameter should be false for LXC templates. > UI does not provide option to set this parameter to false for > RegisterTemplate API -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7186:
---
Assignee: Sheng Yang
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,181 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 2-4214524826288652385: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7195) security_group.py should log exceptions instead of discarding them
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076543#comment-14076543 ] Vincent Bernat commented on CLOUDSTACK-7195: A first step here: https://reviews.apache.org/r/23991/ Most try/except should only catch CalledProcessError. It would be easy to catch an unwanted exception otherwise... > security_group.py should log exceptions instead of discarding them > -- > > Key: CLOUDSTACK-7195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.3.0 >Reporter: Vincent Bernat > > security_group.py discards exceptions with a vague message. This is > troublesome and hide some other bugs. See for example CLOUDSTACK-7193. Any > try/except should at least log the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5212) [UI]Need Support for the LXC for the Report sockets CS-4908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076514#comment-14076514 ] ASF subversion and git services commented on CLOUDSTACK-5212: - Commit f1039b782e5fdef8129088929c42fdf2f2909b5a in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f1039b7 ] Fixed CLOUDSTACK-5212: [UI]Need Support for the LXC for the Report sockets > [UI]Need Support for the LXC for the Report sockets CS-4908 > --- > > Key: CLOUDSTACK-5212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5212 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Kiran Koneti >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > For the report sockets feature we need to provide support for the LXC > hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7195) security_group.py should log exceptions instead of discarding them
Vincent Bernat created CLOUDSTACK-7195: -- Summary: security_group.py should log exceptions instead of discarding them Key: CLOUDSTACK-7195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7195 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Vincent Bernat security_group.py discards exceptions with a vague message. This is troublesome and hide some other bugs. See for example CLOUDSTACK-7193. Any try/except should at least log the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7167) DATA Volume does not expunge
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076449#comment-14076449 ] Aneel Dadani commented on CLOUDSTACK-7167: -- >From Section 13.4.7 Volume Deletion and Garbage Collection, it states "When a >VM is destroyed, data disk volumes that are attached to the VM are not >deleted.Volumes are permanently destroyed using a garbage collection process. >The global configuration variables expunge.delay and expunge.interval >determine when the physical deletion of volumes will occur." However, it does >not state whether the volumes that are permanently destroyed part of the >garbage collection process includes the DATA volume. > DATA Volume does not expunge > > > Key: CLOUDSTACK-7167 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7167 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.2.1 > Environment: CentOS, XenServer 6.2 >Reporter: Aneel Dadani >Priority: Minor > > When an instance is expunged, the ROOT volume is expunged, but the DATA > volume remains. The expunge.delay and expunge.interval is set to run every 24 > hours. We have to manually delete the DATA volumes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076338#comment-14076338
]
Vincent Bernat commented on CLOUDSTACK-7193:
Bugfix here: https://reviews.apache.org/r/23985/
> Rebooting a VM doesn't update iptables rules
>
>
> Key: CLOUDSTACK-7193
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: Ubuntu Lucid 12.04 and more recent
>Reporter: Vincent Bernat
>
> Hi!
> Rebooting a VM doesn't update the iptables rules despite the change on the
> interface name. To reproduce:
> 1. Starts two VM
> 2. Stop the first one.
> 3. Reboot the second one. It will use the vnet device of the first one.
> 4. Checks that the iptables rules for the second one are still referencing
> the old interface.
> The defect seems to be in security_group.py. The periodic
> "get_rule_logs_for_vm" which also handles rebooted VM fails because of the
> following traceback:
> {code}
> 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
> Traceback (most recent call last):
> File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
> line 705, in get_rule_logs_for_vms
> network_rules_for_rebooted_vm(name)
> File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
> line 637, in network_rules_for_rebooted_vm
> [curr_domid, old_domid] = check_domid_changed(vm_name)
> File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
> line 619, in check_domid_changed
> if (curr_domid is None) or (not curr_domid.isdigit()):
> AttributeError: 'int' object has no attribute 'isdigit'
> {code}
> This exception is catched by some try...except.
> On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8.
> I also checked that this is still the case with libvirt 1.2.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7194) deployvirtualmachine command hypervisor argument inconsistent
Alex Brett created CLOUDSTACK-7194:
--
Summary: deployvirtualmachine command hypervisor argument
inconsistent
Key: CLOUDSTACK-7194
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7194
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Environment: Observed running basic BVT against KVM hosts
Reporter: Alex Brett
The deployvirtualmachine API command takes a hypervisor argument. When used
with an ISO, this argument has an effect and restricts which type of hypervisor
the instance gets deployed to.
When used with a template however, it is the hypervisor type of the template
that matters. As such you can call deployvirtualmachine giving it a hypervisor
argument of "XenServer", but a template that is deployed against a KVM host,
and the resulting instance will be running on KVM. In fact you can even give it
an argument of "XenServer" when you don't have any XenServer hosts, and it will
still work properly.
There is however some validation performed on the hypervisor argument - for
example if you attempt to deploy a virtual machine from a KVM based template,
specifying a hypervisor type of "XenServer", and attempt to specify a
rootdisksize override (as in the integration.smoke.test_deploy_vm_root_resize
automated tests), you get this error back:
{noformat}
Hypervisor XenServer does not support rootdisksize override
{noformat}
This is very inconsistent - my suggestion to make this more sensible therefore
would be to do one of the following:
* Validate the hypervisor argument against the hypervisor of the template, and
return an error if they differ
* Ignore (or perhaps don't accept) the hypervisor argument when deploying from
a template, and ensure all validation etc is performed using the hypervisor
parameter of the template
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7194) deployvirtualmachine command hypervisor argument inconsistent
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett updated CLOUDSTACK-7194:
---
Affects Version/s: 4.5.0
> deployvirtualmachine command hypervisor argument inconsistent
> -
>
> Key: CLOUDSTACK-7194
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7194
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.5.0
> Environment: Observed running basic BVT against KVM hosts
>Reporter: Alex Brett
>
> The deployvirtualmachine API command takes a hypervisor argument. When used
> with an ISO, this argument has an effect and restricts which type of
> hypervisor the instance gets deployed to.
> When used with a template however, it is the hypervisor type of the template
> that matters. As such you can call deployvirtualmachine giving it a
> hypervisor argument of "XenServer", but a template that is deployed against a
> KVM host, and the resulting instance will be running on KVM. In fact you can
> even give it an argument of "XenServer" when you don't have any XenServer
> hosts, and it will still work properly.
> There is however some validation performed on the hypervisor argument - for
> example if you attempt to deploy a virtual machine from a KVM based template,
> specifying a hypervisor type of "XenServer", and attempt to specify a
> rootdisksize override (as in the integration.smoke.test_deploy_vm_root_resize
> automated tests), you get this error back:
> {noformat}
> Hypervisor XenServer does not support rootdisksize override
> {noformat}
> This is very inconsistent - my suggestion to make this more sensible
> therefore would be to do one of the following:
> * Validate the hypervisor argument against the hypervisor of the template,
> and return an error if they differ
> * Ignore (or perhaps don't accept) the hypervisor argument when deploying
> from a template, and ensure all validation etc is performed using the
> hypervisor parameter of the template
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules
Vincent Bernat created CLOUDSTACK-7193:
--
Summary: Rebooting a VM doesn't update iptables rules
Key: CLOUDSTACK-7193
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Environment: Ubuntu Lucid 12.04 and more recent
Reporter: Vincent Bernat
Hi!
Rebooting a VM doesn't update the iptables rules despite the change on the
interface name. To reproduce:
1. Starts two VM
2. Stop the first one.
3. Reboot the second one. It will use the vnet device of the first one.
4. Checks that the iptables rules for the second one are still referencing the
old interface.
The defect seems to be in security_group.py. The periodic
"get_rule_logs_for_vm" which also handles rebooted VM fails because of the
following traceback:
{code}
2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
Traceback (most recent call last):
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 705, in get_rule_logs_for_vms
network_rules_for_rebooted_vm(name)
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 637, in network_rules_for_rebooted_vm
[curr_domid, old_domid] = check_domid_changed(vm_name)
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 619, in check_domid_changed
if (curr_domid is None) or (not curr_domid.isdigit()):
AttributeError: 'int' object has no attribute 'isdigit'
{code}
This exception is catched by some try...except.
On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. I
also checked that this is still the case with libvirt 1.2.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7022) [Automation] AttributeError: type object 'TestVpnUsage' has no attribute 'sevice_offering'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076323#comment-14076323
]
ASF subversion and git services commented on CLOUDSTACK-7022:
-
Commit e33d4a5732e81f590489f37b7fbcc947d2929de6 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e33d4a5 ]
CLOUDSTACK-7022: Fixed typo
(cherry picked from commit 967b82f16b93bf1df4473b7ce8dd314f015098e8)
> [Automation] AttributeError: type object 'TestVpnUsage' has no attribute
> 'sevice_offering'
> --
>
> Key: CLOUDSTACK-7022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7022
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> ===
> Bug in Script:
> ===
> cls.service_offering = ServiceOffering.create(
> cls.api_client,
> cls.services["service_offering"]
> )
> cls._cleanup.append(cls.sevice_offering) ---> BUG: Typo in the
> "service_offering" variable name
> cls.virtual_machine = VirtualMachine.create(
> cls.api_client,
> cls.services["server"],
> templateid=template.id,
> accountid=cls.account.name,
> domainid=cls.account.domainid,
> serviceofferingid=cls.service_offering.id
> )
> cls.public_ip = PublicIPAddress.create(
>cls.api_client,
>
> accountid=cls.virtual_machine.account,
>zoneid=cls.virtual_machine.zoneid,
>
> domainid=cls.virtual_machine.domainid,
>services=cls.services["server"]
>)
> return
> =
> Exception:
> =
> test_01_volume_usage (integration.component.test_usage.TestVolumeUsage):
> CRITICAL: EXCEPTION: test_01_volume_usage: ['Traceback (most recent call
> last):\n', ' File "/usr/local/lib/python2.7/dist-packages/nose/suite.py",
> line 208, in run\nself.setUp()\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 291, in setUp\n
> self.setupContext(ancestor)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 314, in
> setupContext\ntry_run(context, names)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in try_run\n
>return func()\n', ' File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_usage.py",
> line 1482, in setUpClass\ncls._cleanup.append(cls.sevice_offering)\n',
> "AttributeError: type object 'TestVpnUsage' has no attribute
> 'sevice_offering'\n"]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 208, in
> run
> self.setUp()
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 291, in
> setUp
> self.setupContext(ancestor)
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 314, in
> setupContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in
> try_run
> return func()
> File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_usage.py",
> line 1482, in setUpClass
> cls._cleanup.append(cls.sevice_offering)
> 'type object \'TestVpnUsage\' has no attribute
> \'sevice_offering\'\n >> begin captured logging <<
> \ntest_01_volume_usage
> (integration.component.test_usage.TestVolumeUsage): DEBUG: Payload:
> {\'signature\': \'aZ6mt3aURCG51ejqTw7v2/RuQFQ=\', \'apiKey\':
> u\'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q\',
> \'command\': \'deleteServiceOffering\', \'id\':
> u\'3a72e88f-7886-42d3-be1a-99fd15908112\', \'response\':
> \'json\'}\ntest_01_volume_usage
> (integration.component.test_usage.TestVolumeUsage): DEBUG: Sending
> GET Cmd :
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6909) Marvin fails to handle SMB credentials in deployDataCenter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076322#comment-14076322 ] ASF subversion and git services commented on CLOUDSTACK-6909: - Commit 2fdf789a28ce01571eabd5ccb8edfea72624ea3c in cloudstack's branch refs/heads/4.4 from [~johnmdilley] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2fdf789 ] CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage Signed-off-by: Daan Hoogland (cherry picked from commit 477a812a6f7aaab74122c11488713f417dfe4d89) (cherry picked from commit 2498f65683bd529b2b03bac9a6cfd2fdbf65aca2) > Marvin fails to handle SMB credentials in deployDataCenter > -- > > Key: CLOUDSTACK-6909 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6909 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test Tools >Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1 >Reporter: John Dilley > > Marvin fails to correctly handle SMB credentials in primary and secondary > storage. > This is because > - For primary storage, the details field is passed to the API as a JSONLoader > object > - For secondary storage, the details field is only used for S3 and Swift > storage. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6943) Skip VM Snapshot test cases for KVM hypervisor type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076320#comment-14076320 ] ASF subversion and git services commented on CLOUDSTACK-6943: - Commit b848c02aa7a3bf4384e664c7db5f66b2482e4e7d in cloudstack's branch refs/heads/4.4 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b848c02 ] CLOUDSTACK-6943: Skip VM snapshot tests on KVM (cherry picked from commit 9563db7a6d9d89558abc09e4ff786accfc0a9513) > Skip VM Snapshot test cases for KVM hypervisor type > --- > > Key: CLOUDSTACK-6943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6943 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Girish Shilamkar >Assignee: Girish Shilamkar > Labels: automation > Fix For: 4.4.0 > > > VM snapshot feature is not enabled for KVM hypervisor, hence following test > cases need to be disabled for KVM. > integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snapshots > integration.smoke.test_vm_snapshots.TestVmSnapshot.test_02_revert_vm_snapshots > integration.smoke.test_vm_snapshots.TestVmSnapshot.test_03_delete_vm_snapshots -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076318#comment-14076318 ] ASF subversion and git services commented on CLOUDSTACK-6887: - Commit 8c37e46807b92ac32c63cd36d33ca5d68bb75f30 in cloudstack's branch refs/heads/4.4 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c37e46 ] CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases (cherry picked from commit b849b7ee3d9b4a141c2eb3fd689d197ed20c4581) > [Automation] Test cases not deleting account after complete the test > - > > Key: CLOUDSTACK-6887 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye > Fix For: 4.4.0, 4.5.0 > > > Still there are test cases not deleting account after complete the test, i > can see below account exist in management server , after complete regression, > As per management server log,these account are not even tried to delete the > account > 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7 > 2) test-TestAccountSnapshotClean-C1M23S > 3) test-TestSnapshotLimit-XWVZAT > 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK > 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP > 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2 > 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK > 8) > test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL > 9) > test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69 > 10) > test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6 > 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF > 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP > 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y > 14) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-9MLF0N > 15) test-TestVPC-test_15_deploy_vm_2-1I5L2M > 16) DoA-TestVPC-test_18_create_net_for_user_diff_domain_by_doadmin-80A4XM > 17) test-TestUserLogin-test_01_non_root_admin_Privileges-MCQ3HG > 18) > test-TestProjectSuspendActivate-test_08_cleanup_after_project_delete-MT8L6G -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6873) [Automation] Ability to execute tests in sequence
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076317#comment-14076317 ] ASF subversion and git services commented on CLOUDSTACK-6873: - Commit 75d2a331ee5876c3c456c8a3c12258c3b8f07f00 in cloudstack's branch refs/heads/4.4 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75d2a33 ] CLOUDSTACK-6873: Tagged tests based on the limitation described in the bug (cherry picked from commit 89a03c7099fb5f0d6a3a892b036d064bfc2acb71) > [Automation] Ability to execute tests in sequence > - > > Key: CLOUDSTACK-6873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6873 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Koushik Das >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > Currently BVT/regression tests are executed in parallel by the test > infrastructure. It needs to be enhanced to add capability to execute a > selective set of tests in sequence. > Specific scenario is tests that uses simulator mocks. These mocks are scoped > to a zone, pod, cluster or host. Once defined any tests targeting a specific > host will execute as per the mocks defined. Now in the current framework it > is not possible to prevent existing tests from going to a specific host. As a > result there needs to be a capability to execute a specific set of test cases > in sequence. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6504) [hyper-v] remove unnecessary warnings while building hyper-v agent code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076307#comment-14076307 ] ASF subversion and git services commented on CLOUDSTACK-6504: - Commit 8fb89cdc8e2dff60d49fecd3e51a9bf997061035 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8fb89cd ] CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code (cherry picked from commit 66f8e0e1b5c81cbfde926c0c65c4d5969767cab9) Conflicts: plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs > [hyper-v] remove unnecessary warnings while building hyper-v agent code > --- > > Key: CLOUDSTACK-6504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > There are some unnecessary warnings in building hyper-v agent code. Like > field is never used etc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6470) [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076299#comment-14076299 ] ASF subversion and git services commented on CLOUDSTACK-6470: - Commit 48f9453a74c0dea9e3c57ab61515e29121c4d2d7 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=48f9453 ] CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first trying to shutdown it gracefully before turning it off forcefully (cherry picked from commit 4a85e2226436c62e781db3449d262cb385b977c1) Conflicts: plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs > [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown > > > Key: CLOUDSTACK-6470 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6470 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > When we stop VM in case of hyper-v, then it is always force shutdowned i.e. > turn off. Even if the integartion services are istalled in hyper-v. Directly > turning of VM may result in corruption of disk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076283#comment-14076283
]
Alex Brett commented on CLOUDSTACK-7173:
This is causing automation failures on KVM, specifically:
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail
integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> Resizing of data volume is throwing java NPE
>
>
> Key: CLOUDSTACK-7173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: log.tar.gz
>
>
> Repro steps :
> 1. Create a Vm with data disk
> 2 . try to resize the data disk
> Bug :
> Resize will fail Ms log shows :
> 2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
> AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
> java.lang.NullPointerException
> at
> com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
> 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:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
> 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:601)
> 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 $Proxy183.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImp
[jira] [Created] (CLOUDSTACK-7192) BVT tests which don't apply to Hyper-V should be skipped
John Dilley created CLOUDSTACK-7192: --- Summary: BVT tests which don't apply to Hyper-V should be skipped Key: CLOUDSTACK-7192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7192 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, marvin Affects Versions: 4.5.0 Reporter: John Dilley If a test is run through nose which doesn't apply to the hypervisor under test, the test should be skipped. In particular, there are many Hyper-V tests which this applies to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7125) [Automation] Fix test_blocker_bugs script to wait for the Snapshot to be backedup before creating a Template from it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076244#comment-14076244
]
ASF subversion and git services commented on CLOUDSTACK-7125:
-
Commit 724c8dc7c98574dcdf669c0c2d7549981667ab77 in cloudstack's branch
refs/heads/4.4 from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=724c8dc ]
CLOUDSTACK-7125: Fixed test_blocker_bugs.py, added code to wait for snapshots
to be in 'BackedU' state
(cherry picked from commit 4395308bd8b469fb02fc71d1e22f25c7d89b6dff)
> [Automation] Fix test_blocker_bugs script to wait for the Snapshot to be
> backedup before creating a Template from it
>
>
> Key: CLOUDSTACK-7125
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7125
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Failed to create Template as Snapshot is not BackedUp yet
> =
> Error:
> =
> CloudstackAPIException: Execute cmd: createtemplate failed, due to:
> errorCode: 431, errorText:Snapshot id=3 is not in BackedUp state yet and
> can't be used for template creation
> test_02_check_size_snapshotTemplate
> (integration.component.test_blocker_bugs.TestTemplates): CRITICAL: EXCEPTION:
> test_02_check_size_snapshotTemplate: ['Traceback (most recent call last):\n',
> ' File "/usr/lib/python2.7/unittest/case.py", line 332, in run\n
> testMethod()\n', ' File
> "/home/jenkins/workspace/xenrt-reg-basic-xs/cloudstack.git/test/integration/component/test_blocker_bugs.py",
> line 891, in test_02_check_size_snapshotTemplate\n
> self.services["template"]\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/lib/base.py",
> line 1164, in create_from_snapshot\nreturn
> Template(apiclient.createTemplate(cmd).__dict__)\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 794, in createTemplate\nresponse =
> self.connection.marvinRequest(command, response_type=response,
> method=method)\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
> line 380, in marvinRequest\nraise e\n', "CloudstackAPIException: Execute
> cmd: createtemplate failed, due to: errorCode: 431, errorText:Snapshot id=3
> is not in BackedUp state yet and can't be used for template creation\n"]
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File
> "/home/jenkins/workspace/xenrt-reg-basic-xs/cloudstack.git/test/integration/component/test_blocker_bugs.py",
> line 891, in test_02_check_size_snapshotTemplate
> self.services["template"]
> File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/lib/base.py",
> line 1164, in create_from_snapshot
> return Template(apiclient.createTemplate(cmd).__dict__)
> File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 794, in createTemplate
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
> line 380, in marvinRequest
> raise e
> 'Execute cmd: createtemplate failed, due to: errorCode: 431,
> errorText:Snapshot id=3 is not in BackedUp state yet and can\'t be used for
> template creation\n >> begin captured stdout <<
> -\n=== TestName: test_02_check_size_snapshotTemplate |
> Status : EXCEPTION ===\n\n\n- >> end captured stdout <<
> --\n >> begin captured logging <<
> \ntest_02_check_size_snapshotTemplate
> (integration.component.test_blocker_bugs.TestTemplates): DEBUG:
> STARTED : TC: test_02_check_size_snapshotTemplate
> :::\ntest_02_check_size_snapshotTemplate
> (integration.component.test_blocker_bugs.TestTemplates): DEBUG: Payload:
> {\'account\': u\'test-TestTemplates-test_01_create_template-PV1LCJ\',
> \'domainid\': u\'7ccbf6bc-08ed-11e4-887d-928d578f5db8\', \'v
[jira] [Commented] (CLOUDSTACK-7127) Fix test_regions.py script - addregion failed, Region with id: 1 already exists
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076245#comment-14076245
]
ASF subversion and git services commented on CLOUDSTACK-7127:
-
Commit d5220a88a085385ebc4b783a40f27d128ea7d28f in cloudstack's branch
refs/heads/4.4 from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d5220a8 ]
CLOUDSTACK-7127: Fix for addRegion failure, avoiding regionid 1 while creating
new region through test case
(cherry picked from commit ca59f01602823a6d6fe84233f3a3d3ea499efa06)
> Fix test_regions.py script - addregion failed, Region with id: 1 already
> exists
>
>
> Key: CLOUDSTACK-7127
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7127
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> ===
> Code Snippet from test_regions.py:
> ===
>def setUp(self):
> pseudo_random_int = choice(xrange(1, 200)) <-- BUG: Region with ID=1
> already exists on the CloudStack Setup. In case if 1 is chosen the testsuite
> fails to execute.
> self.services["region"]["regionid"] = pseudo_random_int
> self.services["region"]["regionname"] = "region" +
> str(pseudo_random_int)
> self.services["region"]["regionendpoint"] = "http://region"; +
> str(pseudo_random_int) + ":8080/client"
> self.region = Region.create(self.api_client,
> self.services["region"]
> )
> Secondly, setup method code should be placed in try and catch blocks
> =
> Test Error:
> =
> Error Message:
> Execute cmd: addregion failed, due to: errorCode: 431, errorText:Region with
> id: 1 already exists
> >> begin captured stdout << -
> === TestName: test_createRegionWithExistingRegionName | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_createRegionWithExistingRegionName
> (integration.component.test_regions.TestRegions): DEBUG: STARTED
> : TC: test_createRegionWithExistingRegionName :::
> test_createRegionWithExistingRegionName
> (integration.component.test_regions.TestRegions): DEBUG: Payload:
> {'endpoint': 'http://region1:8080/client', 'name': 'region1', 'id': 1,
> 'apiKey':
> u'Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA',
> 'command': 'addRegion', 'signature': 'jZQivyHVubuotqAzSjRPxUJmAn4=',
> 'response': 'json'}
> test_createRegionWithExistingRegionName
> (integration.component.test_regions.TestRegions): DEBUG: Sending GET
> Cmd : addRegion===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.135.73
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?endpoint=http%3A%2F%2Fregion1%3A8080%2Fclient&name=region1&id=1&apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA&command=addRegion&signature=jZQivyHVubuotqAzSjRPxUJmAn4%3D&response=json
> HTTP/1.1" 431 123
> test_createRegionWithExistingRegionName
> (integration.component.test_regions.TestRegions): ERROR:
> Exception:['Traceback (most recent call last):\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
> line 308, in __parseAndGetResponse\nresponse_cls)\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py",
> line 150, in getResultObj\nraise
> cloudstackException.CloudstackAPIException(respname, errMsg)\n',
> 'CloudstackAPIException: Execute cmd: addregion failed, due to: errorCode:
> 431, errorText:Region with id: 1 already exists\n']
> Traceback (most recent call last):
> File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
> line 308, in __parseAndGetResponse
> response_cls)
> File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py",
> line 150, in getResultObj
> raise cloudstackException.CloudstackAPIException(respname, errMsg)
> CloudstackAPIException: Execute cmd: addregion failed, due to: errorCode:
> 431, errorText:Region with id: 1 already exists
> test_createRegionWithExistingRe
[jira] [Commented] (CLOUDSTACK-7014) [Automation] type object 'TestAffinityGroupsAdminUser' has no attribute '_TestAffinityGroupsAdminUser__cleanup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076243#comment-14076243
]
ASF subversion and git services commented on CLOUDSTACK-7014:
-
Commit e9d658e16edbe55a380aefa779c89d690b368d24 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e9d658e ]
CLOUDSTACK-7014: Resolving test script related to affinity groups tests
(cherry picked from commit 1cc6317b5e744afb74b63af6600af32bdfedb888)
> [Automation] type object 'TestAffinityGroupsAdminUser' has no attribute
> '_TestAffinityGroupsAdminUser__cleanup
> ---
>
> Key: CLOUDSTACK-7014
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7014
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> ==
> Bug in test script:
> ==
> @classmethod
> def tearDownClass(cls):
> try:
> cls.api_client = super(TestAffinityGroupsAdminUser,
> cls).getClsTestClient().getApiClient()
> #Clean up, terminate the created templates
> cleanup_resources(cls.api_client, cls.__cleanup) > BUG: It
> should be cls._cleanup
> except Exception as e:
> raise Exception("Warning: Exception during cleanup : %s" % e)
>
> Test Script Failure:
>
> Warning: Exception during cleanup : type object 'TestAffinityGroupsAdminUser'
> has no attribute '_TestAffinityGroupsAdminUser__cleanup'
> >> begin captured logging <<
> test_07_delete_aff_grp_of_other_user
> (integration.component.test_affinity_groups.TestAffinityGroupsAdminUser):
> CRITICAL: EXCEPTION: test_07_delete_aff_grp_of_other_user: ['Traceback (most
> recent call last):\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 227, in run\n
> self.tearDown()\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 350, in
> tearDown\nself.teardownContext(ancestor)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 366, in
> teardownContext\ntry_run(context, names)\n', ' File
> "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in try_run\n
>return func()\n', ' File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_affinity_groups.py",
> line 1501, in tearDownClass\nraise Exception("Warning: Exception during
> cleanup : %s" % e)\n', "Exception: Warning: Exception during cleanup : type
> object 'TestAffinityGroupsAdminUser' has no attribute
> '_TestAffinityGroupsAdminUser__cleanup'\n"]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 227, in
> run
> self.tearDown()
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 350, in
> tearDown
> self.teardownContext(ancestor)
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 366, in
> teardownContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in
> try_run
> return func()
> File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_affinity_groups.py",
> line 1501, in tearDownClass
> raise Exception("Warning: Exception during cleanup : %s" % e)
> 'Warning: Exception during cleanup : type object
> \'TestAffinityGroupsAdminUser\' has no attribute
> \'_TestAffinityGroupsAdminUser__cleanup\'\n >> begin
> captured logging <<
> \ntest_07_delete_aff_grp_of_other_user
> (integration.component.test_affinity_groups.TestAffinityGroupsAdminUser):
> CRITICAL: EXCEPTION: test_07_delete_aff_grp_of_other_user: [\'Traceback (most
> recent call last):\\n\', \' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 227, in run\\n
> self.tearDown()\\n\', \' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 350, in
> tearDown\\nself.teardownContext(ancestor)\\n\', \' File
> "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 366, in
> teardownContext\\ntry_run(context, names)\\n\', \' File
> "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in
> try_run\\nreturn func()\\n\', \' File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack
[jira] [Commented] (CLOUDSTACK-7025) [Automation] Failed to deply virtual machine: 'TestAddNetworkToVirtualMachine' object has no attribute 'defaultNetworkId'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076241#comment-14076241
]
ASF subversion and git services commented on CLOUDSTACK-7025:
-
Commit 843e60475798a2cb06daeaa00708c816fb819650 in cloudstack's branch
refs/heads/4.4 from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=843e604 ]
CLOUDSTACK-7025: Resolving test script issue
(cherry picked from commit 33fdfbc83407037b45624ca84ca436fab72e59ab)
> [Automation] Failed to deply virtual machine:
> 'TestAddNetworkToVirtualMachine' object has no attribute 'defaultNetworkId'
> -
>
> Key: CLOUDSTACK-7025
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7025
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Ashutosk Kelkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> ===
> Bug in Script:
> ===
> try:
> virtual_machine = VirtualMachine.create(
> self.api_client, self.services["virtual_machine"],
> accountid=self.account.name, domainid=self.account.domainid,
> serviceofferingid=self.service_offering.id,
> mode=self.zone.networktype,
> networkids=[self.defaultNetworkId]) --> BUG: There is no
> reference to defaultNetworkId specified anywhere before this code in the
> "TestAddNetworkToVirtualMachine" class
> self.cleanup.append(virtual_machine)
> except Exception as e:
> self.fail("Failed to deply virtual machine: %s" % e)
>
> Error Message:
>
> Failed to deply virtual machine: 'TestAddNetworkToVirtualMachine' object has
> no attribute 'defaultNetworkId'
> >> begin captured stdout << -
> === TestName: test_03_add_nw_multiple_times_1_isolated | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_03_add_nw_multiple_times_1_isolated
> (integration.component.test_add_remove_network.TestAddNetworkToVirtualMachine):
> DEBUG: STARTED : TC: test_03_add_nw_multiple_times_1_isolated
> :::
> test_03_add_nw_multiple_times_1_isolated
> (integration.component.test_add_remove_network.TestAddNetworkToVirtualMachine):
> CRITICAL: FAILED: test_03_add_nw_multiple_times_1_isolated: ['Traceback
> (most recent call last):\n', ' File "/usr/lib/python2.7/unittest/case.py",
> line 332, in run\ntestMethod()\n', ' File
> "/usr/local/lib/python2.7/dist-packages/ddt.py", line 114, in wrapper\n
> return func(self, *args, **kwargs)\n', ' File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_add_remove_network.py",
> line 408, in test_03_add_nw_multiple_times\nself.fail("Failed to deply
> virtual machine: %s" % e)\n', ' File "/usr/lib/python2.7/unittest/case.py",
> line 413, in fail\nraise self.failureException(msg)\n', "AssertionError:
> Failed to deply virtual machine: 'TestAddNetworkToVirtualMachine' object has
> no attribute 'defaultNetworkId'\n"]
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/usr/local/lib/python2.7/dist-packages/ddt.py", line 114, in wrapper
> return func(self, *args, **kwargs)
> File
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_add_remove_network.py",
> line 408, in test_03_add_nw_multiple_times
> self.fail("Failed to deply virtual machine: %s" % e)
> File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Failed to deply virtual machine: \'TestAddNetworkToVirtualMachine\' object
> has no attribute \'defaultNetworkId\'\n >> begin captured
> stdout << -\n=== TestName:
> test_03_add_nw_multiple_times_1_isolated | Status : FAILED
> ===\n\n\n- >> end captured stdout <<
> --\n >> begin captured logging <<
> \ntest_03_add_nw_multiple_times_1_isolated
> (integration.component.test_add_remove_network.TestAddNetworkToVirtualMachine):
> DEBUG: STARTED : TC: test_03_add_nw_multiple_times_1_isolated
> :::\ntest_03_add_nw_multiple_times_1_isolated
> (integration.componen
[jira] [Commented] (CLOUDSTACK-7186) [Automation] Router programming fails while calling SetupGuestNetworkCommand and VM deployment fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076196#comment-14076196
]
Saksham Srivastava commented on CLOUDSTACK-7186:
The issue is happening because of failure during comparison of mac address of
vpc router in nics table and the mac address of the router on the hypervisor.
In a Xenserver setup, CitrixResourceBase.java:
prepareNetworkElementCommand(SetNetworkACLCommand cmd)
NicTO nic = cmd.getNic();
VIF vif = getVifByMac(conn, router, nic.getMac());
//vif turns out to be null.
Similarly in
prepareNetworkElementCommand(SetupGuestNetworkCommand cmd)
String mac = nic.getMac();
VIF domrVif = null;
for (VIF vif : vm.getVIFs(conn)) {
String lmac = vif.getMAC(conn);
if (lmac.equals(mac)) {
domrVif = vif;
break;
}
}
if (domrVif == null) {
return new ExecutionResult(false, "Can not find vif with mac "
+ mac + " for VM " + domrName);
}
lmac and mac do not match and null value is returned and hence the NPE.
> [Automation] Router programming fails while calling SetupGuestNetworkCommand
> and VM deployment fails
>
>
> Key: CLOUDSTACK-7186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7186
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM (not verified with other hyper-visors)
> Master
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation run, failed to configure VR after
> deploying the VM , observed below error
> Failed to prepare VR command due to Can not find nic with mac
> 02:00:7d:56:00:02 for VM r-16-VM
> Agent log
> Can not find nic with mac 02:00:7d:56:00:02
> 2014-07-25 16:25:38,061 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Request:Seq 2-4214524826288652384: {
> Cmd , MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,062 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,071 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-1:null) Failed to prepare VR command due to Can not
> find nic with mac 02:00:7d:56:00:02 for VM r-16-VM
> 2014-07-25 16:25:38,071 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 2-4214524826288652384: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Can not find nic
> with mac 02:00:7d:56:00:02 for VM r-16-VM","wait":0}}] }
> 2014-07-25 16:25:38,171 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 2-4214524826288652385: { Cmd ,
> MgmtId: 29066118877352, via: 2, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","networkDomain":"vpc.vpn","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false,"pxeDisable":true,"nicUuid":"bad86d37-eedb-4c0b-8752-0631d5e74f1a","uuid":"b34acc98-77d7-4aa6-9a97-4417b1d1f579","ip":"10.1.1.1","netmask":"255.255.255.192","gateway":"10.1.1.1","mac":"02:00:7d:56:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2352","isolationUri":"vlan://2352","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","guest.vlan.tag":"2352","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.63","router.ip":"169.254.2.226","router.name":"r-16-VM"},"wait":0}}]
> }
> 2014-07-25 16:25:38,172 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.SetupGuestNetworkCommand
> 2014-07-25 16:25:38,180 ERROR
> [resource.virtualnetwork.VirtualRoutingResource]
> (age
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076195#comment-14076195 ] Daan Hoogland commented on CLOUDSTACK-7184: --- after investigation of /opt/cloud/bin/xenheartbeat.sh: xen(server).heartbeat.interval is being used as timout in the scripts. CloudStack passes two parameters and leaves out the second (instead of the third). During a heartbeat event Cloudstack honors no timeout before respinning any vms on the absent host. This gives the host no chance to fence. We need to add a timeout to pass to the heartbeat script and to let cloudstack postpone starting HA jobs that are the result of the absent host. > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076162#comment-14076162 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 1e9e53039150f3f3743bb343e0d06e05aafb5b84 in cloudstack's branch refs/heads/4.4 from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e9e530 ] CLOUDSTACK-6170 (VMware root-disk support for managed storage) (cherry picked from commit a542b6fd825da1d3582a282bcc0e67abd62964bf) > Support managed storage for root disks > -- > > Key: CLOUDSTACK-6170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: I expect to support managed storage for root disks on > XenServer and ESX (KVM is targeted for 4.5). >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.0 > > > Cloud environments have a need for guaranteed storage performance. By this I > mean having the ability to specify a minimum and maximum number of IOPS on a > volume-by-volume basis. > I added support for this for XenServer and ESX in 4.2 for data disks. > I added support for this for KVM in 4.3 for data disks. > It is my intent to add support for this for XenServer and ESX in 4.4 for root > disks (with subsequent support for root disks on KVM expected in 4.5). > The main changes are expected to occur in CloudStack logic that controls > hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6445) Simulator enhancements
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076160#comment-14076160 ] ASF subversion and git services commented on CLOUDSTACK-6445: - Commit 25b4159723fc6e3c169f2fcaf009e579fa4e5874 in cloudstack's branch refs/heads/4.4 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25b4159 ] CLOUDSTACK-6445: Simulator enhancements Refer FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enhancements (cherry picked from commit 617826d16b4d5220bb3b51ed511b3c065d0e8926) > Simulator enhancements > -- > > Key: CLOUDSTACK-6445 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6445 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Simulator >Affects Versions: 4.4.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enhancements -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7191) On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-7191. -- Resolution: Fixed For the networks with VR as the only provider, restarting the network will not result in the clean up of the rules even if restartNetwork is called with cleanup=true option. VR should get destroyed immediately followed by recreating the VR followed by reprogramming the rules. > On restartNetwork destroy the VR immediatley, instead of cleanup the rules > then destroy > --- > > Key: CLOUDSTACK-7191 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7191 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.5.0 > > > RestartNetwork is implemented with below logical steps > >- clean up network rules on the provider (implemented by > shutdownNetworkResources) > - shutdown the providers for the network > - implement all providers for the network > - reprogram the rules > step #1 is unnecessary in case the provider is appliance based like virtual > router. so at present even for the VR significant amount of time is consumed > to clean up the rules. This step is unnecessary as appliance will get > destroyed any ways in next step. > During upgrades in an environments with large number of networks with VR as > the only provider, it will take significant time. > This bug should ensure cleanup of rules is done only if required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7191) On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076150#comment-14076150 ] ASF subversion and git services commented on CLOUDSTACK-7191: - Commit 67876b215ef5217b3d306b3642a38a3708a30494 in cloudstack's branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=67876b2 ] CLOUDSTACK-7191:On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy fix adds a provision to specify if cleanup is needed on network on shutdown. VR is marked as to not to require network rules clean up on network shutdown as the VR is destroyed and recreated. ran the simulator tests that test network life cycle > On restartNetwork destroy the VR immediatley, instead of cleanup the rules > then destroy > --- > > Key: CLOUDSTACK-7191 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7191 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.5.0 > > > RestartNetwork is implemented with below logical steps > >- clean up network rules on the provider (implemented by > shutdownNetworkResources) > - shutdown the providers for the network > - implement all providers for the network > - reprogram the rules > step #1 is unnecessary in case the provider is appliance based like virtual > router. so at present even for the VR significant amount of time is consumed > to clean up the rules. This step is unnecessary as appliance will get > destroyed any ways in next step. > During upgrades in an environments with large number of networks with VR as > the only provider, it will take significant time. > This bug should ensure cleanup of rules is done only if required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7191) On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-7191: - Description: RestartNetwork is implemented with below logical steps - clean up network rules on the provider (implemented by shutdownNetworkResources) - shutdown the providers for the network - implement all providers for the network - reprogram the rules step #1 is unnecessary in case the provider is appliance based like virtual router. so at present even for the VR significant amount of time is consumed to clean up the rules. This step is unnecessary as appliance will get destroyed any ways in next step. During upgrades in an environments with large number of networks with VR as the only provider, it will take significant time. This bug should ensure cleanup of rules is done only if required. was: RestartNetwork is implemented with below logical steps - clean up network rules on the provider (implemented by shutdownNetworkResources) - shutdown the providers for the network - implement all providers for the network - reprogram the rules step #1, is unnecessary in case the provide is appliance based like virtual router. so at present even for VR, significant amount is consumed to clean up the rules. this step is unnecessary as appliance with get destroyed any ways in next step. During upgrades in an environments with large number of networks with VR as the only provider, it will take significant time. This bug should ensure only cleanup rules is done only if required. > On restartNetwork destroy the VR immediatley, instead of cleanup the rules > then destroy > --- > > Key: CLOUDSTACK-7191 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7191 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.5.0 > > > RestartNetwork is implemented with below logical steps > >- clean up network rules on the provider (implemented by > shutdownNetworkResources) > - shutdown the providers for the network > - implement all providers for the network > - reprogram the rules > step #1 is unnecessary in case the provider is appliance based like virtual > router. so at present even for the VR significant amount of time is consumed > to clean up the rules. This step is unnecessary as appliance will get > destroyed any ways in next step. > During upgrades in an environments with large number of networks with VR as > the only provider, it will take significant time. > This bug should ensure cleanup of rules is done only if required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7190) Marvin tests on Hyper-V need to go via management server rather than host to access System VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076144#comment-14076144
]
ASF subversion and git services commented on CLOUDSTACK-7190:
-
Commit 57ee142dede5be035a4501dcfb0816c9bfb8ddaa in cloudstack's branch
refs/heads/master from [~johnmdilley]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=57ee142 ]
CLOUDSTACK-7190: Fix Hyper-V issue when attempting SSH to System VMs
> Marvin tests on Hyper-V need to go via management server rather than host to
> access System VMs
> --
>
> Key: CLOUDSTACK-7190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: marvin
>Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1
>Reporter: John Dilley
>
> Marvin tests that try to access the system VMs try and SSH to a Hyper-V host,
> as is done for XenServer and KVM, rather than opening an SSH connection to
> the management server, as is done for VMWare (which is the correct behaviour
> for Hyper-V)
> This is because the test code has a lot of conditions like this:
> {noformat}
> if self.hypervisor.lower() == 'vmware':
> #SSH into SSVMs is done via management server for Vmware
> {noformat}
> That need to also include Hyper-V
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076130#comment-14076130 ] John Dilley commented on CLOUDSTACK-7188: - Please reject as duplicate of above bug > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > - > > Key: CLOUDSTACK-7188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest master build >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests > require ssh access to ssvm/cpvm. Right now the tests have ssh access > mechanism supported only for vmware,xen and kvm. > This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076117#comment-14076117 ] John Dilley commented on CLOUDSTACK-7189: - Please reject as duplicate of above bug > [Automation]Add hyper-v support for test_routers.py suite in BVT > > > Key: CLOUDSTACK-7189 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest build from master >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_routers.py suite in BVT > Few tests in test_routers.py suite file require ssh access to VR. Need to add > support for hyper-v similar to vmware in accessing VR via ssh. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7191) On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy
Murali Reddy created CLOUDSTACK-7191: Summary: On restartNetwork destroy the VR immediatley, instead of cleanup the rules then destroy Key: CLOUDSTACK-7191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7191 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0, 4.1.0, 4.3.0, 4.4.0, 4.5.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.5.0 RestartNetwork is implemented with below logical steps - clean up network rules on the provider (implemented by shutdownNetworkResources) - shutdown the providers for the network - implement all providers for the network - reprogram the rules step #1, is unnecessary in case the provide is appliance based like virtual router. so at present even for VR, significant amount is consumed to clean up the rules. this step is unnecessary as appliance with get destroyed any ways in next step. During upgrades in an environments with large number of networks with VR as the only provider, it will take significant time. This bug should ensure only cleanup rules is done only if required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7190) Marvin tests on Hyper-V need to go via management server rather than host to access System VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076067#comment-14076067
]
John Dilley commented on CLOUDSTACK-7190:
-
Patch for review at https://reviews.apache.org/r/23976/
> Marvin tests on Hyper-V need to go via management server rather than host to
> access System VMs
> --
>
> Key: CLOUDSTACK-7190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: marvin
>Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1
>Reporter: John Dilley
>
> Marvin tests that try to access the system VMs try and SSH to a Hyper-V host,
> as is done for XenServer and KVM, rather than opening an SSH connection to
> the management server, as is done for VMWare (which is the correct behaviour
> for Hyper-V)
> This is because the test code has a lot of conditions like this:
> {noformat}
> if self.hypervisor.lower() == 'vmware':
> #SSH into SSVMs is done via management server for Vmware
> {noformat}
> That need to also include Hyper-V
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7190) Marvin tests on Hyper-V need to go via management server rather than host to access System VMs
John Dilley created CLOUDSTACK-7190:
---
Summary: Marvin tests on Hyper-V need to go via management server
rather than host to access System VMs
Key: CLOUDSTACK-7190
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7190
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: marvin
Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1
Reporter: John Dilley
Marvin tests that try to access the system VMs try and SSH to a Hyper-V host,
as is done for XenServer and KVM, rather than opening an SSH connection to the
management server, as is done for VMWare (which is the correct behaviour for
Hyper-V)
This is because the test code has a lot of conditions like this:
{noformat}
if self.hypervisor.lower() == 'vmware':
#SSH into SSVMs is done via management server for Vmware
{noformat}
That need to also include Hyper-V
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT
Sanjeev N created CLOUDSTACK-7189: - Summary: [Automation]Add hyper-v support for test_routers.py suite in BVT Key: CLOUDSTACK-7189 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Latest build from master Reporter: Sanjeev N [Automation]Add hyper-v support for test_routers.py suite in BVT Few tests in test_routers.py suite file require ssh access to VR. Need to add support for hyper-v similar to vmware in accessing VR via ssh. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7188: -- Issue Type: Test (was: Bug) > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > - > > Key: CLOUDSTACK-7188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest master build >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests > require ssh access to ssvm/cpvm. Right now the tests have ssh access > mechanism supported only for vmware,xen and kvm. > This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
Sanjeev N created CLOUDSTACK-7188: - Summary: [Automation]Add hyper-v support for test_ssvm.py suite in BVT Key: CLOUDSTACK-7188 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 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: Latest master build Reporter: Sanjeev N [Automation]Add hyper-v support for test_ssvm.py suite in BVT 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests require ssh access to ssvm/cpvm. Right now the tests have ssh access mechanism supported only for vmware,xen and kvm. This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
