[jira] [Commented] (CLOUDSTACK-9584) Increase component tests coverage in Travis run

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701218#comment-15701218
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9584:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1755
  
@abhinandanprateek @murali-reddy @jburwell @serg38 @nvazquez @syed 
@koushik-das @karuturi @milamberspace @wido @JayapalUradi @K0zka 
@rafaelweingartner @yvsubhash -- ping, please help review this.
This will add some existing (800+ test cases) component tests to Travis 
run, with aim to (1) finish each Travis sub-job within 45 mins, (2) run RAT 
related checks and build with `-Dnoredist` in the first job.


> Increase component tests coverage in Travis run
> ---
>
> Key: CLOUDSTACK-9584
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9584
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> Increase component tests in Travis for PRs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware

2016-11-27 Thread Sateesh Chodapuneedi (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701193#comment-15701193
 ] 

Sateesh Chodapuneedi commented on CLOUDSTACK-9624:
--

*+Solution+*
Fix is to update incorrect guest_os_name field value in DB table 
cloud.guest_os_hypervisor.
Query is
{noformat}
UPDATE IGNORE `cloud`.`guest_os_hypervisor` SET guest_os_name = 
'windows7Server64Guest' WHERE guest_os_id IN (SELECT id FROM guest_os WHERE 
display_name LIKE 'windows%2008%r2%64%') AND hypervisor_type = 'VMware' AND 
hypervisor_version != 'default';
{noformat}
After running above query, the 6 updated rows looks like
{noformat}
UPDATE IGNORE `cloud`.`guest_os_hypervisor` SET guest_os_name = 
'windows7Server64Guest' WHERE guest_os_id IN (SELECT id FROM guest_os WHERE 
display_name LIKE 'windows%2008%r2%64%') AND hypervisor_type = 'VMware' AND 
hypervisor_version != 'default';
Query OK, 6 rows affected (0.01 sec)
Rows matched: 6  Changed: 6  Warnings: 0

mysql> select * from guest_os_hypervisor where guest_os_id in (select id from 
guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type = 
'VMware' and hypervisor_version != 'default';
+--+-+---+-++--+-+-+-+
| id   | hypervisor_type | guest_os_name | guest_os_id | 
hypervisor_version | uuid | created 
| removed | is_user_defined |
+--+-+---+-++--+-+-+-+
| 1307 | VMware  | windows7Server64Guest |  54 | 4.0
| 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|
   0 |
| 1448 | VMware  | windows7Server64Guest |  54 | 4.1
| 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
   0 |
| 1589 | VMware  | windows7Server64Guest |  54 | 5.0
| 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
   0 |
| 1730 | VMware  | windows7Server64Guest |  54 | 5.1
| 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
   0 |
| 1871 | VMware  | windows7Server64Guest |  54 | 5.5
| 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
   0 |
| 2381 | VMware  | windows7Server64Guest |  54 | 6.0
| 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|
   0 |
+--+-+---+-++--+-+-+-+
6 rows in set (0.01 sec)
{noformat}

> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on 
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0, 
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest 
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other 
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
> ++-+--+--+-+-+-+-+
> | id | category_id | name | uuid | 
> display_name| created | removed | 
> is_user_defined |
> ++-+--+--+-+-+-+-+
> | 54 |   6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows 
> Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL|   0 |
> ++-+--+--+-+--

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701176#comment-15701176
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1623
  
@abhinandanprateek @murali-reddy ping


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9558) Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701172#comment-15701172
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9558:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1722
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is 
> expunged
> -
>
> Key: CLOUDSTACK-9558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9558
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: Xen Server
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Steps to reproduce the issue
> ===
> i) Deploy a new VM in CCP on Xenserver
> ii) Create a snapshot for the volume created in step i) from CCP. This step 
> will create a snapshot on the primary storage and keeps it on storage as we 
> use it as reference for the incremental snapshots
> iii) Now destroy and expunge the VM created in step i)
> You will notice that the volume for the VM ( created in step i) is deleted 
> from the primary storage. However the snapshot created on primary ( as part 
> of step ii)) still exists on the primary and this needs to be deleted 
> manually by the admin.
> Snapshot exists on the primary storage even after deleting the Volume.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701173#comment-15701173
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1706
  
@murali-reddy can you help review this? thanks.


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9612) Restart Network with clean up fails for networks whose offering has been changed from Isolated -> RVR

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701169#comment-15701169
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9612:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1781
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Restart Network with clean up fails for networks whose offering has been 
> changed from Isolated -> RVR
> -
>
> Key: CLOUDSTACK-9612
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9612
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
> Deploy a network N1 with " Offering for Isolated networks with Source Nat 
> service enabled" . Ensure both vm and vr are UP .
> Create a RVR offering and edit the network offering from the current to 
> RVR ofefring .
> Ensure both Master and Backup are up and running.
> Now restart the network with clean up option enabled.
> Observations :
> Restarting the nw with clean up is creating is failing with the below error.
> {noformat}
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Start completed for VM VM[DomainRouter|r-21-QA]
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Done executing VM work job: 
> com.cloud.vm.VmWorkStart{"dcId":0,"rawParams":{"RestartNetwork":"rO0ABXNyABFqYXZhLmxhbmcuQm9vbGVhbs0gcoDVnPruAgABWgAFdmFsdWV4cAE"},"userId":2,"accountId":2,"vmId":21,"handlerName":"VirtualMachineManagerImpl"}
> 2016-11-24 15:49:32,432 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Complete async job-104, jobStatus: SUCCEEDED, resultCode: 0, 
> result: null
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Publish async job-104 complete on message bus
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs related to job-104
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Update db status for job-104
> 2016-11-24 15:49:32,435 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs joined with job-104 and disjoin all subjobs 
> created from job- 104
> 2016-11-24 15:49:32,446 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done with 
> run of VM work job: com.cloud.vm.VmWorkStart for VM 21, job origin: 99
> 2016-11-24 15:49:32,446 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done 
> executing com.cloud.vm.VmWorkStart for job-104
> 2016-11-24 15:49:32,448 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Remove 
> job-104 from job monitoring
> 2016-11-24 15:49:32,455 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-10:ctx-d835fe9f job-99 ctx-2cd2b41c) (logid:fb2d5b7b) 
> Failed to implement network Ntwk[204|Guest|16] elements and resources as a 
> part of network restart due to 
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Can't find all necessary running routers!
>   at 
> com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:226)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1132)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2740)
>   at 
> com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1907)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)

[jira] [Commented] (CLOUDSTACK-9558) Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701171#comment-15701171
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9558:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1722
  
@blueorangutan package


> Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is 
> expunged
> -
>
> Key: CLOUDSTACK-9558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9558
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: Xen Server
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Steps to reproduce the issue
> ===
> i) Deploy a new VM in CCP on Xenserver
> ii) Create a snapshot for the volume created in step i) from CCP. This step 
> will create a snapshot on the primary storage and keeps it on storage as we 
> use it as reference for the incremental snapshots
> iii) Now destroy and expunge the VM created in step i)
> You will notice that the volume for the VM ( created in step i) is deleted 
> from the primary storage. However the snapshot created on primary ( as part 
> of step ii)) still exists on the primary and this needs to be deleted 
> manually by the admin.
> Snapshot exists on the primary storage even after deleting the Volume.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9612) Restart Network with clean up fails for networks whose offering has been changed from Isolated -> RVR

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701167#comment-15701167
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9612:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1781
  
@jayapalu this looks useful, can you change PR's base branch to 4.9? Thanks.
@blueorangutan package


> Restart Network with clean up fails for networks whose offering has been 
> changed from Isolated -> RVR
> -
>
> Key: CLOUDSTACK-9612
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9612
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
> Deploy a network N1 with " Offering for Isolated networks with Source Nat 
> service enabled" . Ensure both vm and vr are UP .
> Create a RVR offering and edit the network offering from the current to 
> RVR ofefring .
> Ensure both Master and Backup are up and running.
> Now restart the network with clean up option enabled.
> Observations :
> Restarting the nw with clean up is creating is failing with the below error.
> {noformat}
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Start completed for VM VM[DomainRouter|r-21-QA]
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Done executing VM work job: 
> com.cloud.vm.VmWorkStart{"dcId":0,"rawParams":{"RestartNetwork":"rO0ABXNyABFqYXZhLmxhbmcuQm9vbGVhbs0gcoDVnPruAgABWgAFdmFsdWV4cAE"},"userId":2,"accountId":2,"vmId":21,"handlerName":"VirtualMachineManagerImpl"}
> 2016-11-24 15:49:32,432 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Complete async job-104, jobStatus: SUCCEEDED, resultCode: 0, 
> result: null
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Publish async job-104 complete on message bus
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs related to job-104
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Update db status for job-104
> 2016-11-24 15:49:32,435 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs joined with job-104 and disjoin all subjobs 
> created from job- 104
> 2016-11-24 15:49:32,446 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done with 
> run of VM work job: com.cloud.vm.VmWorkStart for VM 21, job origin: 99
> 2016-11-24 15:49:32,446 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done 
> executing com.cloud.vm.VmWorkStart for job-104
> 2016-11-24 15:49:32,448 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Remove 
> job-104 from job monitoring
> 2016-11-24 15:49:32,455 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-10:ctx-d835fe9f job-99 ctx-2cd2b41c) (logid:fb2d5b7b) 
> Failed to implement network Ntwk[204|Guest|16] elements and resources as a 
> part of network restart due to 
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Can't find all necessary running routers!
>   at 
> com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:226)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1132)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2740)
>   at 
> com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1907)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>

[jira] [Commented] (CLOUDSTACK-9617) Enabling Remote access Vpn Fails when there is a portforwarding rule of the reserved ports ( 1701 , 500 , 4500) under TCP protocol.

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701166#comment-15701166
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9617:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1782
  
@murali-reddy can you help review this?
@jayapalu this looks useful, can you rebase against 4.9 and change PR's 
base branch to 4.9?


> Enabling Remote access Vpn Fails when there is a portforwarding rule of the 
> reserved ports ( 1701 , 500 , 4500) under TCP protocol.
> ---
>
> Key: CLOUDSTACK-9617
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9617
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
> Navigate to Network -> Configuration -> Portforwarding
> Create a new rule 1701 under both private and public ports for TCP Protocol 
> and assign a VM.
> Now Enable Remote access VPN on the Network .
> observation :
> Enabling VPN acess is failing with the following error "The range 
> specified, 1701-1701, conflicts with rule 53 which has 1701-1701 "
> Expected Result :
> Enabling VPN should be sucessful , as the port forwarding rule added is TCP 
> protocol , and the firewall rules populated when VPN is enabled is UDP 
> protocol.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9615) Ingress Firewall Rules with blank start and End ports doesnt get applied

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701163#comment-15701163
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9615:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1783
  
@jayapalu can you rebase against 4.9 and change PR's base branch to 4.9? 
Thanks.
@murali-reddy can you help review this?


> Ingress Firewall Rules with blank start and End ports doesnt get applied
> 
>
> Key: CLOUDSTACK-9615
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9615
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
>1.  Navigate to Network -> view ip adress -> Source Nat -> Configuration 
> -> Firewall.
>2.  Add new TCp rule without giving any start port or end port.
>3. The rule creation is success in API, but its not applied in VR .
>4.  Only when specific port are provided the rule is applied .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware

2016-11-27 Thread Sateesh Chodapuneedi (JIRA)

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

Sateesh Chodapuneedi updated CLOUDSTACK-9624:
-
Description: 
Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os 
at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008 
(64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which 
would not represent the guest OS accurately on hypervisor.
The current (4.9) mappings in database looks as below,
{noformat}
mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
++-+--+--+-+-+-+-+
| id | category_id | name | uuid | display_name 
   | created | removed | is_user_defined |
++-+--+--+-+-+-+-+
| 54 |   6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows 
Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL|   0 |
++-+--+--+-+-+-+-+
1 row in set (0.00 sec)

mysql> select * from guest_os_hypervisor where guest_os_id in (select id from 
guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type = 
'VMware' and hypervisor_version != 'default';
+--+-++-++--+-+-+-+
| id   | hypervisor_type | guest_os_name  | guest_os_id | 
hypervisor_version | uuid | created 
| removed | is_user_defined |
+--+-++-++--+-+-+-+
| 1307 | VMware  | winLonghorn64Guest |  54 | 4.0   
 | 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|   
0 |
| 1448 | VMware  | winLonghorn64Guest |  54 | 4.1   
 | 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|   
0 |
| 1589 | VMware  | winLonghorn64Guest |  54 | 5.0   
 | 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|   
0 |
| 1730 | VMware  | winLonghorn64Guest |  54 | 5.1   
 | 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|   
0 |
| 1871 | VMware  | winLonghorn64Guest |  54 | 5.5   
 | 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|   
0 |
| 2381 | VMware  | winLonghorn64Guest |  54 | 6.0   
 | 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|   
0 |
+--+-++-++--+-+-+-+
6 rows in set (0.01 sec)
{noformat}

  was:
Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os 
at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008 
(64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which 
would not represent the guest OS accurately on hypervisor.



> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on 
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0, 
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest 
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other 
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
> ++-+--+-

[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701150#comment-15701150
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
Trillian test result (tid-466)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 28617 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1638-t466-kvm-centos7.zip
Test completed. 46 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_VPC_nics_after_destroy | `Failure` | 846.90 | 
test_vpc_router_nics.py
test_02_vpc_privategw_static_routes | `Failure` | 917.78 | 
test_privategw_acl.py
test_assign_and_removal_lb | `Failure` | 166.80 | test_loadbalance.py
test_02_create_lb_rule_non_nat | `Failure` | 166.91 | test_loadbalance.py
test_01_create_lb_rule_src_nat | `Failure` | 207.28 | test_loadbalance.py
test_01_vpc_site2site_vpn | Success | 154.38 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 85.91 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 265.11 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 281.60 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 542.59 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1315.82 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 578.06 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 780.50 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1365.40 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.46 | test_volumes.py
test_08_resize_volume | Success | 15.29 | test_volumes.py
test_07_resize_fail | Success | 20.36 | test_volumes.py
test_06_download_detached_volume | Success | 15.27 | test_volumes.py
test_05_detach_volume | Success | 100.26 | test_volumes.py
test_04_delete_attached_volume | Success | 10.15 | test_volumes.py
test_03_download_attached_volume | Success | 15.23 | test_volumes.py
test_02_attach_volume | Success | 73.75 | test_volumes.py
test_01_create_volume | Success | 712.57 | test_volumes.py
test_deploy_vm_multiple | Success | 302.73 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.64 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.16 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 40.68 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.08 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 130.70 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 130.66 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.14 | test_vm_life_cycle.py
test_01_stop_vm | Success | 45.28 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 90.56 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 5.12 | test_templates.py
test_03_delete_template | Success | 5.08 | test_templates.py
test_02_edit_template | Success | 90.11 | test_templates.py
test_01_create_template | Success | 55.38 | test_templates.py
test_10_destroy_cpvm | Success | 166.71 | test_ssvm.py
test_09_destroy_ssvm | Success | 168.59 | test_ssvm.py
test_08_reboot_cpvm | Success | 136.73 | test_ssvm.py
test_07_reboot_ssvm | Success | 138.65 | test_ssvm.py
test_06_stop_cpvm | Success | 137.00 | test_ssvm.py
test_05_stop_ssvm | Success | 168.82 | test_ssvm.py
test_04_cpvm_internals | Success | 1.22 | test_ssvm.py
test_03_ssvm_internals | Success | 3.32 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.10 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_01_snapshot_root_disk | Success | 11.02 | test_snapshots.py
test_04_change_offering_small | Success | 244.41 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py
test_01_create_service_offering | Success | 0.07 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.10 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.13 | test_secondary_storage.py
test_09_reboot_router | Success | 40.25 | test_routers.py
test_08_start_ro

[jira] [Created] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware

2016-11-27 Thread Sateesh Chodapuneedi (JIRA)
Sateesh Chodapuneedi created CLOUDSTACK-9624:


 Summary: Incorrect hypervisor mapping of guest os Windows 2008 
Server R2 (64-bit) on VMware
 Key: CLOUDSTACK-9624
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.9.0
 Environment: VMware 6.0, 
ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
 Fix For: 4.10.0.0


Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os 
at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008 
(64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which 
would not represent the guest OS accurately on hypervisor.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9623) Deploying virtual machine fails due to "Couldn't find vlanId" in Basic Zone

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701125#comment-15701125
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9623:


GitHub user nitin-maharana opened a pull request:

https://github.com/apache/cloudstack/pull/1792

CLOUDSTACK-9623: Deploying virtual machine fails due to "Couldn't find 
vlanId" in Basic Zone

In Basic zone, while deploying a VM it fails with an unexpected exception.
This is reproducible only when java asserts are enabled.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nitin-maharana/CloudStack-Nitin nitin4

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1792.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1792


commit f01778a1ddc9c2daeaf0f0a3c1eed7194d696ea4
Author: Nitin Kumar Maharana 
Date:   2016-11-28T06:41:41Z

CLOUDSTACK-9623: Deploying virtual machine fails due to "Couldn't find 
vlanId" in Basic Zone




> Deploying virtual machine fails due to "Couldn't find vlanId" in Basic Zone
> ---
>
> Key: CLOUDSTACK-9623
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9623
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nitin Kumar Maharana
>
> In Basic zone, while deploying a VM it fails with an unexpected exception.
> This is reproducible only when java asserts are enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-9623) Deploying virtual machine fails due to "Couldn't find vlanId" in Basic Zone

2016-11-27 Thread Nitin Kumar Maharana (JIRA)
Nitin Kumar Maharana created CLOUDSTACK-9623:


 Summary: Deploying virtual machine fails due to "Couldn't find 
vlanId" in Basic Zone
 Key: CLOUDSTACK-9623
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9623
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Reporter: Nitin Kumar Maharana


In Basic zone, while deploying a VM it fails with an unexpected exception.

This is reproducible only when java asserts are enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700568#comment-15700568
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Trillian test result (tid-464)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 28781 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1659-t464-kvm-centos7.zip
Test completed. 44 look ok, 4 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_redundant_VPC_default_routes | `Failure` | 920.96 | 
test_vpc_redundant.py
test_router_dhcp_opts | `Failure` | 21.30 | test_router_dhcphosts.py
test_04_rvpc_privategw_static_routes | `Failure` | 406.87 | 
test_privategw_acl.py
test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 255.61 | 
test_privategw_acl.py
test_02_vpc_privategw_static_routes | `Failure` | 296.51 | 
test_privategw_acl.py
test_04_extract_template | `Error` | 5.12 | test_templates.py
test_01_vpc_site2site_vpn | Success | 161.06 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 91.39 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 321.88 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 285.18 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 574.36 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 528.63 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1394.26 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 565.28 | test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1318.80 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.88 | test_volumes.py
test_08_resize_volume | Success | 15.55 | test_volumes.py
test_07_resize_fail | Success | 20.50 | test_volumes.py
test_06_download_detached_volume | Success | 15.36 | test_volumes.py
test_05_detach_volume | Success | 100.23 | test_volumes.py
test_04_delete_attached_volume | Success | 10.21 | test_volumes.py
test_03_download_attached_volume | Success | 15.33 | test_volumes.py
test_02_attach_volume | Success | 73.83 | test_volumes.py
test_01_create_volume | Success | 711.70 | test_volumes.py
test_deploy_vm_multiple | Success | 283.93 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.65 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 81.24 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.81 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.92 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.18 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.35 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 85.73 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.19 | test_templates.py
test_01_create_template | Success | 60.56 | test_templates.py
test_10_destroy_cpvm | Success | 161.80 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.80 | test_ssvm.py
test_08_reboot_cpvm | Success | 131.81 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.75 | test_ssvm.py
test_06_stop_cpvm | Success | 131.92 | test_ssvm.py
test_05_stop_ssvm | Success | 133.90 | test_ssvm.py
test_04_cpvm_internals | Success | 1.27 | test_ssvm.py
test_03_ssvm_internals | Success | 3.54 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.15 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.38 | test_snapshots.py
test_04_change_offering_small | Success | 239.68 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.09 | test_service_offerings.py
test_01_create_service_offering | Success | 0.12 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.17 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.20 | test_secondary_storage.py
test_09_reboot_router | Success | 40.34 | test_routers.py

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700510#comment-15700510
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + xenserver-65sp1) has 
been kicked to run smoke tests


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-1

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700508#comment-15700508
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@blueorangutan test centos7 xenserver-65sp1


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 |1 |  95 | 2016-10-

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700472#comment-15700472
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
Trillian test result (tid-462)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 26823 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1710-t462-kvm-centos7.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_redundant_VPC_default_routes | `Failure` | 873.43 | 
test_vpc_redundant.py
test_router_dhcp_opts | `Failure` | 20.89 | test_router_dhcphosts.py
test_01_vpc_site2site_vpn | Success | 144.25 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 65.83 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 229.84 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 278.50 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 542.32 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 499.58 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1400.05 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 532.40 | test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1273.02 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 10.36 | test_volumes.py
test_08_resize_volume | Success | 15.30 | test_volumes.py
test_07_resize_fail | Success | 20.35 | test_volumes.py
test_06_download_detached_volume | Success | 15.34 | test_volumes.py
test_05_detach_volume | Success | 100.26 | test_volumes.py
test_04_delete_attached_volume | Success | 10.16 | test_volumes.py
test_03_download_attached_volume | Success | 15.26 | test_volumes.py
test_02_attach_volume | Success | 73.79 | test_volumes.py
test_01_create_volume | Success | 651.67 | test_volumes.py
test_deploy_vm_multiple | Success | 282.83 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.70 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.17 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 30.62 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.09 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.68 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.69 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.15 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.27 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 110.75 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 5.22 | test_templates.py
test_03_delete_template | Success | 5.08 | test_templates.py
test_02_edit_template | Success | 90.16 | test_templates.py
test_01_create_template | Success | 45.34 | test_templates.py
test_10_destroy_cpvm | Success | 161.56 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.55 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.51 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.00 | test_ssvm.py
test_06_stop_cpvm | Success | 106.78 | test_ssvm.py
test_05_stop_ssvm | Success | 133.15 | test_ssvm.py
test_04_cpvm_internals | Success | 1.20 | test_ssvm.py
test_03_ssvm_internals | Success | 2.92 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.09 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.10 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.05 | test_snapshots.py
test_04_change_offering_small | Success | 239.42 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
test_01_create_service_offering | Success | 0.08 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.11 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.13 | test_secondary_storage.py
test_09_reboot_router | Success | 40.27 | test_routers.py
test_08_start_router | Success | 30.22 | test_routers.py
test_07_stop_router | Success | 10.13 | test_routers.py
test_06_router_advanced | Success | 0.04 | test_routers.py
test_05_router_basic | Success | 0.03 | test_routers.py
test_04_restart

[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700461#comment-15700461
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700459#comment-15700459
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
@blueorangutan test


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700328#comment-15700328
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9595:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1762
  
@serg38, it is great that you found one of the methods that cause the 
deadlock problem 
“com.cloud.host.dao.HostDaoImpl.findAndUpdateDirectAgentToLoad(long, Long, 
long)”.

This method surely is problematic. I would first start asking, (i) does it 
need to manually open a transaction (at line 512)? Isn’t that the goal of “@DB” 
annotation? (ii) what is the objective of the method 
(“findAndUpdateDirectAgentToLoad”)? It is looking too complicated, with too 
many accesses to the DB.

The method “resetHosts” at line 517 looks for hosts that are “managed” by 
the current MS and are “Disconnected” to mark them as unmanaged by any MS. That 
means, it updates the “managementServerId = null” of hosts marked as 
“Disconnect”.

Would not it be better to have a specific method/transaction only for the 
aforementioned process?  If we extract that chunk of code to an isolated 
method, could not we have an atomic access to the DB without locking? “update 
set managementServerId = null from hosts where ……”; If the method is isolated I 
do not see reasons for locks here.

A little further, there is another method which could be isolated, lines 
527 – 546. This block of code looks for clusters being managed by the current 
MS. Then, it searches for hosts of clusters that are managed by the current MS, 
which are not being managed by the current MS (or not managed at all?)? I did 
not understand that because I have seen in some other piece of code that we 
have a balancing approach; meaning that, we try to balance the number of hosts 
managed by an MS.  This piece of code seems to remove the balancing process.

Then, at line 551 and forward (if the number of hosts is less than the 
limit), it tries to look for hosts of clusters not being managed by any MS. 
This block could also be an isolated one. And again, we might be able to do 
this process without using locks.

My final comment, even if we choose not to refactor and improve this piece 
of code, there is one thing that is very strange for me. The method 
“findAndUpdateDirectAgentToLoad”  is annotated with “@DB”, and also opens and 
tries to manage a transaction manually. Then, we have all of the pieces of code 
I mentioned, all of them call other methods that also are annotated with “@DB”. 
Can this cause a problem?

For instance, when I use Spring, methods from a service layer (the place 
where I configure my pattern of transactions) call one another, they will all 
use/share the same transaction opened when the first method of the service 
layer was called, unless specified otherwise. How will it work here in ACS?



> Transactions are not getting retried in case of database deadlock errors
> 
>
> Key: CLOUDSTACK-9595
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9595
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Customer is seeing occasional error 'Deadlock found when trying to get lock; 
> try restarting transaction' messages in their management server logs.  It 
> happens regularly at least once a day.  The following is the error seen 
> 2015-12-09 19:23:19,450 ERROR [cloud.api.ApiServer] 
> (catalina-exec-3:ctx-f05c58fc ctx-39c17156 ctx-7becdf6e) unhandled exception 
> executing api command: [Ljava.lang.String;@230a6e7f
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74f134e3: DELETE FROM 
> instance_group_vm_map WHERE instance_group_vm_map.instance_id = 941374
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1209)
>   at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
>   at 
> org.springframework.aop

[jira] [Closed] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread Milamber (JIRA)

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

Milamber closed CLOUDSTACK-9621.

Resolution: Fixed

Thanks Rohit.

> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread Milamber (JIRA)

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

Milamber closed CLOUDSTACK-9622.

Resolution: Fixed

Thanks Rohit.

> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699941#comment-15699941
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699939#comment-15699939
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@blueorangutan test


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699922#comment-15699922
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1791


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699921#comment-15699921
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699926#comment-15699926
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699919#comment-15699919
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699924#comment-15699924
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699923#comment-15699923
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit 0522d0df934e9dea13315735ef5f111ec610b510 in cloudstack's branch 
refs/heads/master from [~milamber]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0522d0d ]

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699925#comment-15699925
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699920#comment-15699920
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit bc846b13730460a71dc5d1b5908d60aa4ca0918f in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc846b1 ]

Merge pull request #1791 from milamberspace/CLOUDSTACK-9622_Fix_Project_Not_L10N

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI[Base 4.9, 
forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:
![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:
![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd

* pr/1791:
  CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

Signed-off-by: Rohit Yadav 


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699918#comment-15699918
 ] 

ASF subversion and git services commented on CLOUDSTACK-9622:
-

Commit 0522d0df934e9dea13315735ef5f111ec610b510 in cloudstack's branch 
refs/heads/4.9 from [~milamber]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0522d0d ]

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699915#comment-15699915
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1791
  
LGTM, tested manually similar changes as seen in screenshots from 
@milamberspace 
I'll proceed with merging this now.


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699911#comment-15699911
 ] 

ASF subversion and git services commented on CLOUDSTACK-9621:
-

Commit c238b12cd83a501d2f85beeea40cba70f52ff4e9 in cloudstack's branch 
refs/heads/master from [~milamber]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c238b12 ]

CLOUDSTACK-9621: Improve conversion Transifex's JSON format to CloudStack JS


> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699914#comment-15699914
 ] 

ASF subversion and git services commented on CLOUDSTACK-9621:
-

Commit 21209a06ad188ac55f9782221feb6bad2c25e9ef in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=21209a0 ]

Merge pull request #1789 from milamberspace/L10N-update-Master-20161124

Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0I've 
check manually the correct display of the UI foreach language.

Don't forget to merge this before 4.10 release.

cc @jburwell @rhtyd

* pr/1789:
  CLOUDSTACK-9621: Update L10N resource files with 4.10 strings from Transifex 
(20161127)
  CLOUDSTACK-9621: Improve conversion Transifex's JSON format to CloudStack JS

Signed-off-by: Rohit Yadav 


> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699912#comment-15699912
 ] 

ASF subversion and git services commented on CLOUDSTACK-9621:
-

Commit 32a70cb83abee0d8353d70d1a38e921320f05757 in cloudstack's branch 
refs/heads/master from [~milamber]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=32a70cb ]

CLOUDSTACK-9621: Update L10N resource files with 4.10 strings from Transifex 
(20161127)


> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699913#comment-15699913
 ] 

ASF subversion and git services commented on CLOUDSTACK-9621:
-

Commit 21209a06ad188ac55f9782221feb6bad2c25e9ef in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=21209a0 ]

Merge pull request #1789 from milamberspace/L10N-update-Master-20161124

Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0I've 
check manually the correct display of the UI foreach language.

Don't forget to merge this before 4.10 release.

cc @jburwell @rhtyd

* pr/1789:
  CLOUDSTACK-9621: Update L10N resource files with 4.10 strings from Transifex 
(20161127)
  CLOUDSTACK-9621: Improve conversion Transifex's JSON format to CloudStack JS

Signed-off-by: Rohit Yadav 


> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699868#comment-15699868
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699866#comment-15699866
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
Failure wrt debian pkg was due to an env issue.
@blueorangutan test



> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 | 

[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699808#comment-15699808
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9611:


Github user rajesh-battala commented on the issue:

https://github.com/apache/cloudstack/pull/1771
  
Gone through the patch. LGTM.


> Dedicating a Guest VLAN range to Project does not work
> --
>
> Key: CLOUDSTACK-9611
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Trying to dedicate a guest VLAN range to an account fails. If we pass both 
> account and projectid parameters to the dedicateGuestVlanRange (which are not 
> mentioned as mutually exclusive in API description) the API layer throws 
> error saying both are mutually exclusive.
> Steps to Reproduce:
> 
> Create an account. Create a project in that account.
> Go to admin account and change view to the above project.
> Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate 
> Guest VLAN range.
> Try to dedicate the guest VLAN range from the project view for the account 
> associated with the project.
> It fails with Error saying accountName and projectId are mutually exclusive.
> Expected:
> 
> The VLAN range should get dedicated to the project account.
> Notes:
> =
> If we do the dedication from default view then it works fine as no projectid 
> is associated over there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699619#comment-15699619
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/1592
  
Closing this PR as its shadow PR #1785 got merged into 4.9/master


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699618#comment-15699618
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user prashanthvarma closed the pull request at:

https://github.com/apache/cloudstack/pull/1592


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699589#comment-15699589
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-266


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699590#comment-15699590
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-262


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 |1 |  

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699588#comment-15699588
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-263


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699552#comment-15699552
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1791
  
LGTM.


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread Milamber (JIRA)

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

Milamber updated CLOUDSTACK-9622:
-
Fix Version/s: (was: 4.9.2.0)
   4.9.1.0

> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread Milamber (JIRA)

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

Milamber updated CLOUDSTACK-9622:
-
Fix Version/s: 4.9.2.0

> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699542#comment-15699542
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


GitHub user milamberspace opened a pull request:

https://github.com/apache/cloudstack/pull/1791

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

[Base 4.9, forward to 4.10 too]

The label Project isn't localized.

Sample with chinese UI:
Current:

![selection_457](https://cloud.githubusercontent.com/assets/3995882/20648086/56e54cfe-b495-11e6-9e78-3590a24302d1.png)

With this PR:

![selection_456](https://cloud.githubusercontent.com/assets/3995882/20648088/6090960a-b495-11e6-9dc0-eb24e16dcdc6.png)

cc @rhtyd 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/milamberspace/cloudstack 
CLOUDSTACK-9622_Fix_Project_Not_L10N

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1791.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1791


commit 0522d0df934e9dea13315735ef5f111ec610b510
Author: Milamber 
Date:   2016-11-27T10:47:25Z

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI




> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699539#comment-15699539
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699538#comment-15699538
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
@blueorangutan package


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699519#comment-15699519
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user milamberspace closed the pull request at:

https://github.com/apache/cloudstack/pull/1790


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699505#comment-15699505
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1790
  
LGTM.


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699507#comment-15699507
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1790
  
@milamberspace can you change the base branch of the PR to 4.9, this looks 
useful for 4.9 as well.


> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699502#comment-15699502
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9622:


GitHub user milamberspace opened a pull request:

https://github.com/apache/cloudstack/pull/1790

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI

The label Project isn't localized.

Sample with chinese UI:
Current:

![selection_457](https://cloud.githubusercontent.com/assets/3995882/20647939/6aa555ee-b491-11e6-8f7d-51a7f16e9bb5.png)

With this PR:

![selection_456](https://cloud.githubusercontent.com/assets/3995882/20647948/7504f134-b491-11e6-8864-aee065259406.png)


cc: @rhtyd 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/milamberspace/cloudstack Fix_Project_Not_L10N

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1790.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1790


commit 57c00f102d417cc80ad824fc38b431ec919cf26f
Author: Milamber 
Date:   2016-11-27T10:47:25Z

CLOUDSTACK-9622 Localisation for 'Project' label on the top of Web UI




> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread Milamber (JIRA)

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

Milamber reassigned CLOUDSTACK-9622:


Assignee: Milamber

> Localisation for 'Project' label on the top of Web UI
> -
>
> Key: CLOUDSTACK-9622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Milamber
>Assignee: Milamber
>Priority: Trivial
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread Milamber (JIRA)

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

Milamber updated CLOUDSTACK-9621:
-
Assignee: (was: Milamber)

> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI

2016-11-27 Thread Milamber (JIRA)
Milamber created CLOUDSTACK-9622:


 Summary: Localisation for 'Project' label on the top of Web UI
 Key: CLOUDSTACK-9622
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Milamber
Priority: Trivial
 Fix For: 4.10.0.0


The label "Project" isn't translate on the top of UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread Milamber (JIRA)

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

Milamber reassigned CLOUDSTACK-9621:


Assignee: Milamber

> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Assignee: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9613) Unable to set NAT rules on any interfaces except first interface of VM.

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699479#comment-15699479
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9613:


Github user nitin-maharana closed the pull request at:

https://github.com/apache/cloudstack/pull/1778


> Unable to set NAT rules on any interfaces except first interface of VM.
> ---
>
> Key: CLOUDSTACK-9613
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9613
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> VMs have multiple network interfaces.
> It is not possible to set a NAT rule on any of the interfaces except the 
> first interface of the VM from UI. Because the UI only lists the IPs of the 
> first interface.
> The rules can only be set on the "default" interface but even after setting 
> the secondary as the default interface the outcome is still the same. Only 
> the first interface is listed in the UI as available for setting NAT rules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699473#comment-15699473
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9621:


Github user milamberspace commented on the issue:

https://github.com/apache/cloudstack/pull/1789
  
@rhtyd Done: CLOUDSTACK-9621

https://issues.apache.org/jira/browse/CLOUDSTACK-9621


> Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
> --
>
> Key: CLOUDSTACK-9621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Priority: Minor
>  Labels: easytest
> Fix For: 4.10.0.0
>
>
> Update the localization files (new format JSON) with the latest translation 
> files from Transifex CloudStack project.
> See PR #1789
> https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0

2016-11-27 Thread Milamber (JIRA)
Milamber created CLOUDSTACK-9621:


 Summary: Update L10N files from Transifex (2016-11-27) for the new 
release 4.10.0.0
 Key: CLOUDSTACK-9621
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.10.0.0
Reporter: Milamber
Priority: Minor
 Fix For: 4.10.0.0


Update the localization files (new format JSON) with the latest translation 
files from Transifex CloudStack project.

See PR #1789
https://github.com/apache/cloudstack/pull/1789



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9613) Unable to set NAT rules on any interfaces except first interface of VM.

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699465#comment-15699465
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9613:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1778
  
Thanks @nitin-maharana a similar fix was merged with #1785 since it was for 
4.9. Please close this PR.


> Unable to set NAT rules on any interfaces except first interface of VM.
> ---
>
> Key: CLOUDSTACK-9613
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9613
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> VMs have multiple network interfaces.
> It is not possible to set a NAT rule on any of the interfaces except the 
> first interface of the VM from UI. Because the UI only lists the IPs of the 
> first interface.
> The rules can only be set on the "default" interface but even after setting 
> the secondary as the default interface the outcome is still the same. Only 
> the first interface is listed in the UI as available for setting NAT rules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699459#comment-15699459
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit 094c4cf02bf75ed3e5bd227f7b4cfe614f386871 in cloudstack's branch 
refs/heads/master from [~nlivens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=094c4cf ]

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUI


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699461#comment-15699461
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit f78e9463497e00efcc4d8af19af4a6771dbb569a in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f78e946 ]

Merge pull request #1785 from prashanthvarma/4.9

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUIBug in ACS master GUI: Enabling Static NAT on an 
associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due 
to a wrong (default) Guest VM IP being selected in the GUI.

ERROR:
INFO  [c.c.a.ApiServer](catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) VM ip 
10.10.2.163 address not belongs to the vm

ACS GUI before the bug fix:

![network1](https://cloud.githubusercontent.com/assets/3722369/16091177/cff63836-3332-11e6-8854-c7e8222a7c67.png)
![network2](https://cloud.githubusercontent.com/assets/3722369/16091186/d7118ba2-3332-11e6-9143-ae0a5cd96235.png)

As you can see in the above attached ACS GUI screen shots, same (default) guest 
VM IP is being selected in the ACS GUI for both the NICs (networks) of the 
multi-NIC VM while enabling Static NAT on the corresponding associated Public 
IPs. Thus, we hit this issue.

ACS GUI after this bug fix:

![fixed_network1](https://cloud.githubusercontent.com/assets/3722369/16091242/1c1b3252--11e6-82e5-071bd05a7edb.png)
![fixed_network2](https://cloud.githubusercontent.com/assets/3722369/16091245/1fd52696--11e6-8f96-3f9ca0019af6.png)

As you can see in the above attached ACS GUI screen shots, this bug fix 
resolves the above mentioned issue.

* pr/1785:
  CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of 
the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM 
IP being selected in the GUI

Signed-off-by: Rohit Yadav 


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699460#comment-15699460
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit f78e9463497e00efcc4d8af19af4a6771dbb569a in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f78e946 ]

Merge pull request #1785 from prashanthvarma/4.9

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUIBug in ACS master GUI: Enabling Static NAT on an 
associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due 
to a wrong (default) Guest VM IP being selected in the GUI.

ERROR:
INFO  [c.c.a.ApiServer](catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) VM ip 
10.10.2.163 address not belongs to the vm

ACS GUI before the bug fix:

![network1](https://cloud.githubusercontent.com/assets/3722369/16091177/cff63836-3332-11e6-8854-c7e8222a7c67.png)
![network2](https://cloud.githubusercontent.com/assets/3722369/16091186/d7118ba2-3332-11e6-9143-ae0a5cd96235.png)

As you can see in the above attached ACS GUI screen shots, same (default) guest 
VM IP is being selected in the ACS GUI for both the NICs (networks) of the 
multi-NIC VM while enabling Static NAT on the corresponding associated Public 
IPs. Thus, we hit this issue.

ACS GUI after this bug fix:

![fixed_network1](https://cloud.githubusercontent.com/assets/3722369/16091242/1c1b3252--11e6-82e5-071bd05a7edb.png)
![fixed_network2](https://cloud.githubusercontent.com/assets/3722369/16091245/1fd52696--11e6-8f96-3f9ca0019af6.png)

As you can see in the above attached ACS GUI screen shots, this bug fix 
resolves the above mentioned issue.

* pr/1785:
  CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of 
the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM 
IP being selected in the GUI

Signed-off-by: Rohit Yadav 


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699455#comment-15699455
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit f78e9463497e00efcc4d8af19af4a6771dbb569a in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f78e946 ]

Merge pull request #1785 from prashanthvarma/4.9

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUIBug in ACS master GUI: Enabling Static NAT on an 
associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due 
to a wrong (default) Guest VM IP being selected in the GUI.

ERROR:
INFO  [c.c.a.ApiServer](catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) VM ip 
10.10.2.163 address not belongs to the vm

ACS GUI before the bug fix:

![network1](https://cloud.githubusercontent.com/assets/3722369/16091177/cff63836-3332-11e6-8854-c7e8222a7c67.png)
![network2](https://cloud.githubusercontent.com/assets/3722369/16091186/d7118ba2-3332-11e6-9143-ae0a5cd96235.png)

As you can see in the above attached ACS GUI screen shots, same (default) guest 
VM IP is being selected in the ACS GUI for both the NICs (networks) of the 
multi-NIC VM while enabling Static NAT on the corresponding associated Public 
IPs. Thus, we hit this issue.

ACS GUI after this bug fix:

![fixed_network1](https://cloud.githubusercontent.com/assets/3722369/16091242/1c1b3252--11e6-82e5-071bd05a7edb.png)
![fixed_network2](https://cloud.githubusercontent.com/assets/3722369/16091245/1fd52696--11e6-8f96-3f9ca0019af6.png)

As you can see in the above attached ACS GUI screen shots, this bug fix 
resolves the above mentioned issue.

* pr/1785:
  CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of 
the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM 
IP being selected in the GUI

Signed-off-by: Rohit Yadav 


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
>

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699454#comment-15699454
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit 094c4cf02bf75ed3e5bd227f7b4cfe614f386871 in cloudstack's branch 
refs/heads/4.9 from [~nlivens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=094c4cf ]

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUI


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699456#comment-15699456
 ] 

ASF subversion and git services commented on CLOUDSTACK-9416:
-

Commit f78e9463497e00efcc4d8af19af4a6771dbb569a in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f78e946 ]

Merge pull request #1785 from prashanthvarma/4.9

CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of the 
NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
being selected in the GUIBug in ACS master GUI: Enabling Static NAT on an 
associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due 
to a wrong (default) Guest VM IP being selected in the GUI.

ERROR:
INFO  [c.c.a.ApiServer](catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) VM ip 
10.10.2.163 address not belongs to the vm

ACS GUI before the bug fix:

![network1](https://cloud.githubusercontent.com/assets/3722369/16091177/cff63836-3332-11e6-8854-c7e8222a7c67.png)
![network2](https://cloud.githubusercontent.com/assets/3722369/16091186/d7118ba2-3332-11e6-9143-ae0a5cd96235.png)

As you can see in the above attached ACS GUI screen shots, same (default) guest 
VM IP is being selected in the ACS GUI for both the NICs (networks) of the 
multi-NIC VM while enabling Static NAT on the corresponding associated Public 
IPs. Thus, we hit this issue.

ACS GUI after this bug fix:

![fixed_network1](https://cloud.githubusercontent.com/assets/3722369/16091242/1c1b3252--11e6-82e5-071bd05a7edb.png)
![fixed_network2](https://cloud.githubusercontent.com/assets/3722369/16091245/1fd52696--11e6-8f96-3f9ca0019af6.png)

As you can see in the above attached ACS GUI screen shots, this bug fix 
resolves the above mentioned issue.

* pr/1785:
  CLOUDSTACK-9416 : Enabling Static NAT on an associated Public IP to one of 
the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM 
IP being selected in the GUI

Signed-off-by: Rohit Yadav 


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
>

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699458#comment-15699458
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1785


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699451#comment-15699451
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1785
  
LGTM, this fixes the same issue as #1778. Since this is a pure UI change, 
manual testing with screenshot confirm the fix. I'll move with the merge now. 
The failure at Travis is not due to this change but intermittent/env issue.


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Fix For: 4.9.2.0
>
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&ipaddressid=36262bcc-282a-46c2-8a80-472e2a24ab5e&virtualmachineid=af160cde-6762-4756-b97f-f3829f6d9802&vmguestip=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult&jobId=7850c125-54a2-4e99-ab78-9f0e3578c304&response=json&sessionkey=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699447#comment-15699447
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699445#comment-15699445
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@blueorangutan package


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699443#comment-15699443
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@blueorangutan package


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 |1 |  95 | 2016-10-12 10:17:08 | NULL   

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

2016-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15699444#comment-15699444
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:1