[jira] [Created] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-9069:


 Summary: Newly added project is not showing in the drop down until 
the browser is refreshed.
 Key: CLOUDSTACK-9069
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Kumar Maharana


Steps to reproduce:
1.Login as admin and navigate to Projects page.
2.Add one project and navigate to Dashboard.
3.Check for newly added project in Project drop down.

Actual behaviour:
New project is showing in drop down only after refreshing the browser.

Expected behaviour:
New project should be shown in drop down without refreshing the browser also.



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

[jira] [Created] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9067:


 Summary: As I developer I want to remove all the unused 
router-shell scripts from ACS
 Key: CLOUDSTACK-9067
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9067
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues






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

[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9015:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1070#issuecomment-157373768
  
Ping @remibergsma 

Are the tests still running?

Cheers,
Wilder


> Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
> --
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Created] (CLOUDSTACK-9066) update testpath to delete account after deleting VM's of that account

[Priti Sarap (JIRA)]

Priti Sarap created CLOUDSTACK-9066:
---

 Summary: update testpath to delete account after deleting VM's of 
that account 
 Key: CLOUDSTACK-9066
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9066
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Reporter: Priti Sarap


In testpath_snapshot_hardning.py testpath account was getting cleared prior to 
VM's of that account hence while cleaning up the account the VM's in that 
account also gets deleted hence while clearing VM's it gives exception as "No 
VM found".



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

[jira] [Commented] (CLOUDSTACK-9066) update testpath to delete account after deleting VM's of that account

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9066:


GitHub user pritisarap12 opened a pull request:

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

CLOUDSTACK-9066: Update testpath to delete account after deleting VM's of 
that account 

In testpath_snapshot_hardning.py testpath account was getting cleared prior 
to VM's of that account hence while cleaning up the account the VM's in that 
account also gets deleted hence while clearing VM's it gives exception as "No 
VM found".

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

$ git pull https://github.com/pritisarap12/cloudstack 
CLOUDSTACK-9066-update-testpath-to-delete-account-after-deleting-VMs-of-that-account

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

https://github.com/apache/cloudstack/pull/1078.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 #1078


commit a8e60499fe7a895f03d875e27105e017fcc2e615
Author: Priti Sarap 
Date:   2015-11-17T11:55:23Z

CLOUDSTACK-9066: Update testpath to delete account after deleting VMs of 
that account




> update testpath to delete account after deleting VM's of that account 
> --
>
> Key: CLOUDSTACK-9066
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9066
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Priti Sarap
>
> In testpath_snapshot_hardning.py testpath account was getting cleared prior 
> to VM's of that account hence while cleaning up the account the VM's in that 
> account also gets deleted hence while clearing VM's it gives exception as "No 
> VM found".



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-admin/pull/30


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user nlivens commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-157371668
  
Thanks @remibergsma, much appreciated!


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157418520
  
No, we don't run any xen and I have to use spare time as a matter of 
professional integrity when doing things on that platform. We don't have our 
own bubble yet (closing in on it) and I will advocate supporting 'other' 
hypervisors in it when we do.


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose commented on the pull request:

https://github.com/apache/cloudstack/pull/1062#issuecomment-157418578
  
Closing this pull request now that it has been created against the 4.6 
branch in PR #1079 


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose closed the pull request at:

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


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


GitHub user dsclose opened a pull request:

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

CLOUDSTACK-9058 - Respond with "saved_password" if no password is to be 
issued.

The password server on the virtual router should respond with 
"saved_password" if no password is to be issued. This allows for backwards 
compatibility with Windows Guest VMs which require the "saved_password" 
response.

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

$ git pull https://github.com/dsclose/cloudstack CLOUDSTACK-9058

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

https://github.com/apache/cloudstack/pull/1079.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 #1079


commit 8a7deefe64cab0b3c49ebc510c6524b1fad1f884
Author: dsclose 
Date:   2015-11-12T08:05:57Z

CLOUDSTACK-9058

Respond with "saved_password" if no password is to be issued.




> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose commented on the pull request:

https://github.com/apache/cloudstack/pull/1079#issuecomment-157416663
  
@wilderrodrigues no, i was asked to open this pull request by @remibergsma 


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load



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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin13

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

https://github.com/apache/cloudstack/pull/1080.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 #1080


commit 1f53f2a93ea57c33b29b641b156b1e16df9dddff
Author: Remi Bergsma 
Date:   2015-11-15T17:48:59Z

Updating pom.xml version numbers for release 4.7.0-SNAPSHOT

Signed-off-by: Remi Bergsma 

commit 6536992671f37967f1abb764feb7e3a4d9b959fb
Author: Remi Bergsma 
Date:   2015-11-15T18:11:50Z

implement upgrade paths from 4.6.0/4.6.1 to 4.7.0

commit 704cbe0ec62697a36dea5f121a21745026dc00f9
Author: Remi Bergsma 
Date:   2015-11-15T20:29:08Z

Add 4.7.0-SNAPSHOT to Debian changelog

commit ea7c2d95b28e442df64607e914f66bd4517f2e03
Author: Remi Bergsma 
Date:   2015-11-16T07:46:13Z

Merge pull request #1068 from remibergsma/460_470_upgrade_path

Make master 4.7.0-SNAPSHOT and implement upgrade paths towards itThis bumps 
all pom.xml versions to 4.7.0-SNAPSHOT. It also implements upgrade paths from 
4.6.0 and the upcoming 4.6.1 (branch 4.6 is now on 4.6.1-SNAPSHOT) towards 
4.7.0.

I will be doing some upgrade tests, will post back results soon.

* pr/1068:
  Add 4.7.0-SNAPSHOT to Debian changelog
  implement upgrade paths from 4.6.0/4.6.1 to 4.7.0
  Updating pom.xml version numbers for release 4.7.0-SNAPSHOT

Signed-off-by: Remi Bergsma 

commit 17219dfe791320f331c325d54efd01af97ceeb1a
Author: Rajani Karuturi 
Date:   2015-11-16T10:13:08Z

Merge release branch 4.6 to master

* 4.6:
  more poms didn't get updated with script
  implemented upgrade path from 4.6.0 to 4.6.1
  checkstyle pom didn't get updated with script
  debian: add 4.6.1-snapshot to changelog
  Updating pom.xml version numbers for release 4.6.1-SNAPSHOT
  Updating pom.xml version numbers for release 4.6.0

commit 9ed8151169b95656c8ce2fac50745af49cf48169
Author: Rajani Karuturi 
Date:   2015-11-16T10:26:59Z

Fixed version number in build/replace.properties

commit bf0c4f2ecb425201e7cad4762c27d654f7cb9996
Author: Remi Bergsma 
Date:   2015-11-17T08:25:45Z

Merge pull request #1071 from karuturi/merge-46-to-master

Merge 4.6 release branch to masterInitial merge of 4.6 to master
ignored pom.xml version number changes and changes to debian/changelog and 
engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java

Following commands were executed
```
1. git checkout 4.6
2. git pull --rebase
3. git checkout master
4. git pull --rebase
5. git fwd-merge 4.6
6. git diff --name-only | grep pom.xml | xargs git checkout --ours
7. git diff --name-only | grep pom.xml | xargs git add
8. git checkout --ours 
engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java
9. git add engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java
10. git checkout --ours debian/changelog
11. git add debian/changelog
12. # manually edited version number in tools/marvin/marvin/deployAndRun.py 
and tools/marvin/setup.py
13. git commit
14. git checkout -b "merge-46-to-master"
```

* pr/1071:
  Fixed version number in build/replace.properties
  more poms didn't get updated with script
  implemented upgrade path from 4.6.0 to 4.6.1
  checkstyle pom didn't get updated with script
  debian: add 4.6.1-snapshot to changelog
  Updating pom.xml version numbers for release 4.6.1-SNAPSHOT
  Updating pom.xml version numbers for release 4.6.0

Signed-off-by: Remi Bergsma 

commit 3aa63dc76ac1869d62ce42d8e5dc2752ebe71601
Author: Nitin Kumar Maharana 
Date:   2015-11-17T11:57:26Z

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load

For setting the width of each data item for each row of portforwarding 
rules, it was processing all rules.
Basically for each data item, it was searching in all rules, which is 
un-necessary.
If there are N-Rules, It was processing N-times.

Now, it only processes one time by taking all N-rules at a 

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157417603
  
@DaanHoogland ... can't the guys at LeaseWeb help with testing against xen 
or are you the only one with a bubble?

No need to close it due to test environment issues, I can run it tomorrow 
(PR test day). I was just wondering if you try to create the xenserver as I 
told in the email.

Cheers,
Wilder


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1079#issuecomment-157421231
  
@wilderrodrigues I want to merge this to 4.6, so the one against master 
should be closed. As we merge forward now, we need bug fixes against 4.6. 
Otherwise it will not make it to 4.6


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1062#issuecomment-157410651
  
LGTM, based on a set of tests that I run on this branch (which I rebased 
myself first):

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py

```

Result:

```
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : 
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and 
check default routes ... === TestName: test_02_redundant_VPC_default_routes | 
Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: 
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok
Test for port forwarding on source NAT ... === TestName: 
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName: 
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for 

[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9054:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1060#issuecomment-157411442
  
@DaanHoogland FYI test results:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py

```

Result:

```
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : 
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and 
check default routes ... === TestName: test_02_redundant_VPC_default_routes | 
Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: 
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok
Test for port forwarding on source NAT ... === TestName: 
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName: 
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: 

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose commented on the pull request:

https://github.com/apache/cloudstack/pull/1062#issuecomment-157411446
  
I've created the PR against 4.6 now.

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


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose commented on the pull request:

https://github.com/apache/cloudstack/pull/1079#issuecomment-157411634
  
This is a duplicate of PR https://github.com/apache/cloudstack/pull/1062


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9054:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1060#issuecomment-157415551
  
tnx @remibergsma . It can be merged but more important is for it to be a 
coding policy so I'll link it on dev@
@miguelaferreira Or should we consider going to the java 1.8 implementation?


> countIp6InRange(final String ip6Range) does not handle open range
> -
>
> Key: CLOUDSTACK-9054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>
> in case of '-1::0' or "0::0-" errors are thrown while the meaning of the 
> range is clear
> In the testcase for this method an exception is thrown because of this:
> 2015-11-11 10:20:57,997 ERROR [utils.net.NetUtils] (main:) Failed to convert 
> a string to an IPv6 address
> java.lang.IllegalArgumentException: can not parse []
>   at 
> com.googlecode.ipv6.IPv6Address.tryParseStringArrayIntoLongArray(IPv6Address.java:94)
>   at com.googlecode.ipv6.IPv6Address.fromString(IPv6Address.java:80)
>   at com.cloud.utils.net.NetUtils.countIp6InRange(NetUtils.java:1332)
>   at 
> com.cloud.utils.net.NetUtilsTest.testCountIp6InRangeWithNullStart(NetUtilsTest.java:153)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1079#issuecomment-157416121
  
Should it be closed then?


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user nitin-maharana closed the pull request at:

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


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Created] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-9068:


 Summary: Listing Port Forwarding Rules take too much time to load
 Key: CLOUDSTACK-9068
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Kumar Maharana


ISSUE
==
The performance of listPortForwardingRules slows down dramatically as the 
number of rules for an IP increases. If there are 100 rules for an IP and it 
takes over a minute to respond.

REPRODUCE STEPS
==
1) Create many port forwarding rules (75-100) for a particular IP.
2) View the port forwarding rules for the IP in the UI or directly with the 
listPortForwardingRules API command.
3) Notice the slowness.

EXPECTED BEHAVIOR
==
listPortForwardingRules should always respond in a reasonable time.

ACTUAL BEHAVIOR
==
listPortForwardingRules responds very slowly even with less than 100 rules 
configured.



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

[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9069:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9069: Newly added project is not showing in the drop down until 
the browser is refreshed.


The created or deleted project was added to/deleted from the list but it 
was not being updated.
Now it updates the list at the same time.

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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin14

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

https://github.com/apache/cloudstack/pull/1077.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 #1077


commit 14cb46cfbb25538b394f7f7070be114ae1ab7506
Author: Nitin Kumar Maharana 
Date:   2015-11-17T12:08:48Z

CLOUDSTACK-9069: Newly added project is not showing in the drop down until 
the browser is refreshed.

The created or deleted project was added to/deleted from the list but it 
was not being updated.
Now it updates the list at the same time.




> Newly added project is not showing in the drop down until the browser is 
> refreshed.
> ---
>
> Key: CLOUDSTACK-9069
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Steps to reproduce:
> 1.Login as admin and navigate to Projects page.
> 2.Add one project and navigate to Dashboard.
> 3.Check for newly added project in Project drop down.
> Actual behaviour:
> New project is showing in drop down only after refreshing the browser.
> Expected behaviour:
> New project should be shown in drop down without refreshing the browser also.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user DaanHoogland commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1076#discussion_r45052092
  
--- Diff: ui/scripts/ui/widgets/multiEdit.js ---
@@ -279,7 +279,7 @@
 }
 
 // Align width to main header
-_medit.refreshItemWidths($multi);
+//_medit.refreshItemWidths($multi);
--- End diff --

can you delete code instead of commenting out, please.


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1062#issuecomment-157393161
  
How did you test it, @dsclose? 

Cheers,
Wilder


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user abhinandanprateek commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-157399076
  
@runseb  @pdion891  This did not make it into 4.6, will be merged with 
master.

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


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user pdion891 commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-157404633
  
thanks, I've looked into Jira, and rollback the publishing of quotas in 4.6 
documentation. still merge in master, master branch is not published on RTD.  
So we are all good I think.

Thanks for rising this @runseb 


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user nitin-maharana commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1076#discussion_r45074032
  
--- Diff: ui/scripts/ui/widgets/multiEdit.js ---
@@ -279,7 +279,7 @@
 }
 
 // Align width to main header
-_medit.refreshItemWidths($multi);
+//_medit.refreshItemWidths($multi);
--- End diff --

Sure @DaanHoogland. Thanks.


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157392000
  
Hi @DaanHoogland,

I run integration tests before creating the PRs and that's not manually and 
I do have only 1 bubble. I just do:

* build code/RPMs
* run MS
* deploy DC
* run tests

I could do that before the bubble as well... remember my endless iptables 
list? ;)

I only feel comfortable with creating a PR if I know the system is still 
working. I have been fixing problems before due to PRs that were not tested and 
broke master. With me it only happened 2 times, but it took me 4 weeks to find 
out which commit - not mine - broke it. I am just trying to avoid that again.

Concerning the inline get calls, you don't have to change it. It would 
improve readability, but that's not a blocker. However, the PR needs to be 
tested against XenServer at least by 1 reviewer - or a CI that tests something 
(not against a simulator). 

Cheers,
Wilder


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user runseb commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-157396108
  
@pdion891 let me check with @abhinandanprateek I might be wrong


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-9055) NPE in update Redundant State of VPC networks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9055:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1073#issuecomment-157409023
  
LGTM, based on a set of tests that I run on this branch (which I rebased 
myself first):

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py

```

Result:

```
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : 
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and 
check default routes ... === TestName: test_02_redundant_VPC_default_routes | 
Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: 
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok
Test for port forwarding on source NAT ... === TestName: 
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName: 
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for 

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user dsclose commented on the pull request:

https://github.com/apache/cloudstack/pull/1062#issuecomment-157409534
  
This was tested situationally. Not perfect, but we don't have the 
Cloudstack test-suite setup yet. Not sure I will have time to do that now.

The following steps were taken on a Cloudstack 4.5 router:

1. Demonstrate default response when no password is to be issued.
1. Open a session on a linux VM
2. Use the arp table to get the IP address of the master virtual router 
(10.2.13.58 in my case)
3. Query the router for a password and save the result in pass.txt:
wget -t 3 -T 20 -O pass.txt --header 'DomU_Request: 
send_my_password' 10.2.13.58:8080
4. Verify that pass.txt is empty, delete pass.txt
2. Demonstrate correct response when there is a password to be issued.
1. Obtain the IP address of a VM you want to issue a password for 
(10.2.13.22 in my case)
2. Set up the router to serve a password.
1. Open a session on the router.
2. Save a password for the VM with the value of “test_password”:
1. /opt/cloud/bin/savepassword.sh –v 10.2.13.22 –p test_password
1. Verify that the password has been saved:
cat /var/cache/cloud/passwords-10.2.13.58
10.2.13.22=test
3. Query the router:
1. Open a session on the linux VM
2. Run the same query command as above:
wget -t 3 -T 20 -O pass.txt --header 'DomU_Request: 
send_my_password' 10.2.13.58:8080
3. pass.txt should now contain test_password

Those same steps were followed for a Cloudstack 4.3 router (we upgraded 
from 4.3 to 4.5). It was observed that the Cloudstack 4.3 router replied with 
"saved_password" when there was no password to be served.

Once we established the difference in behaviour we implemented the given 
fix, rebuilt the systemvm.iso and pushed it out to our hypervisors.

The solution was initially tested:

1. By rebuilding a test network, repeating the steps above to verify that 
we got the expected behaviour.
2. By reproducing the password reset issue on a Windows guest VM running on 
a network that used the Cloudstack 4.5 system VM. We then rebuilt that network 
and observed that the Windows VM maintained its password.
1. We also observed that the windows VM repeatedly queried the password 
server for 30 minutes.
2. This has been seen each time a network is rebuilt so far.
3. We restarted the cloud service on Windows Guest VMs to see if that would 
cause the password to be lost. The password was maintained.
4. We manually set the administrative password on a windows guest VM and 
then rebooted. The password was maintained.
5. We triggered a password reset on a windows guest VM, a new password was 
assigned and adopted by the VM.
6. We repeated steps 4 and 5 on a linux VM. The Linux VM behaved as 
expected.

Subsequent to this, we rebuilt all of our networks with the fixed router. 
This rebuilt several-hundred virtual routers. There are several-hundred Windows 
guests. Whereas we were getting alerted by our clients regularly about password 
issues connected with reboots before the fix, we have not seen a repeat of the 
behaviour since this fixed was rolled out.


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've 

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1076#issuecomment-157409637
  
Hi @nitin-maharana thanks for the fix! Please make this pull request 
against 4.6, so it can be fixed there as well. Once merged, it will be forward 
merged to master. Thanks!


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157406551
  
@wilderrodrigues i have a habbit of -1'ing my own PR at times!

this time for instance. I ran this against the bubble and it failed. It was 
the reason i asked you (off-line) about xen in the bubble. If I don't find time 
soon to validate it I will close the PR.


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user runseb commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-157389188
  
@pdion this should be on the master branch not in the 4.6 branch since 
quota have not yet been merged...correct ?


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-9055) NPE in update Redundant State of VPC networks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9055:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1073#issuecomment-157389878
  
Hi @ustcweizhou,

Okay, I understood. Have you prepared a test to cover it? I mean, we need a 
test that deploys a DC, creates a redundant VPC, adds 1 tier, deploys 1 VM, 
destroys/stop/disconnect the host then when the router check runs we don't get 
a NPE.

In case writing an integration test for that is too much, perhaps would be 
nice to write some unit tests.

Do you have a test environment? If so, could you please run the following 
tests against KVM?

* requires HW
  * component/test_vpc_redundant.py
* doesn't require HW (but just run against KVM, it's fine)
* component/test_vpc_offerings.py

Cheers,
Wilder


> NPE in update Redundant State of VPC networks
> -
>
> Key: CLOUDSTACK-9055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9055
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> 2015-11-11 08:32:48,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 4 routers to update status.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 0 networks to update RvR status.
> 2015-11-11 08:32:48,705 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-7:ctx-195132c6) Seq 22-1391893759834266981: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:32:58,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) Begin cleanup expired async-jobs
> 2015-11-11 08:32:58,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) End cleanup expired async-jobs
> 2015-11-11 08:33:06,370 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-ab0d6092) Zone 1 is ready to launch console proxy
> 2015-11-11 08:33:06,435 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-2b4d78f6) Zone 1 is ready to launch secondary storage VM
> 2015-11-11 08:33:08,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) Begin cleanup expired async-jobs
> 2015-11-11 08:33:08,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) End cleanup expired async-jobs
> 2015-11-11 08:33:15,441 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-6:ctx-bba99e59) HostStatsCollector is running...
> 2015-11-11 08:33:17,649 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-c64bf7b6) AutoScaling Monitor is running...
> 2015-11-11 08:33:18,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) Begin cleanup expired async-jobs
> 2015-11-11 08:33:18,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) End cleanup expired async-jobs
> 2015-11-11 08:33:18,660 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 4 routers to update status.
> 2015-11-11 08:33:18,663 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:33:18,664 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,673 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-5:ctx-db2e782d) Seq 22-1391893759834266982: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:33:18,674 DEBUG [c.c.a.m.AgentAttache] 
> (RedundantRouterStatusMonitor-10:ctx-7afb35e1) Seq 22-1391893759834266980: 
> Waiting some more time because this is the current command
> 2015-11-11 08:33:18,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 4 routers to update status.
> 2015-11-11 08:33:18,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 1 VPC 

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user pdion891 commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-157391102
  
hum, ok, I will roll it back from 4.6 docs.


> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Created] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[Udo Rader (JIRA)]

Udo Rader created CLOUDSTACK-9070:
-

 Summary: 4.5.x source downloads from apache.org fail gpg integrity 
test
 Key: CLOUDSTACK-9070
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.5.2, 4.5.1
Reporter: Udo Rader


as described in 

http://markmail.org/message/37udf7djizul5xuf 

the currently available source downloads fail the gpg integrity check because 
the key used to sign the packages is missing from 
http://www.apache.org/dist/cloudstack/KEYS

---CUT-
[udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
0EE3D884
gpg: Can't check signature: public key not found
---CUT-

applies to 4.5.1 and 4.5.2 at least. 

At least to me this makes the integrity of the source downloads dubious ...



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

[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9069:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9069: Newly added project is not showing in the drop down until 
the browser is refreshed.

The created or deleted project was added to/deleted from the list but it 
was not being updated.
Now it updates the list at the same time.

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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin16

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

https://github.com/apache/cloudstack/pull/1082.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 #1082


commit 24f57a9bffb6e48c6c1a5f99eaa1334bbfcc7b1c
Author: Nitin Kumar Maharana 
Date:   2015-11-17T17:44:49Z

CLOUDSTACK-9069: Newly added project is not showing in the drop down until 
the browser is refreshed.

The created or deleted project was added to/deleted from the list but it 
was not being updated.
Now it updates the list at the same time.




> Newly added project is not showing in the drop down until the browser is 
> refreshed.
> ---
>
> Key: CLOUDSTACK-9069
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Steps to reproduce:
> 1.Login as admin and navigate to Projects page.
> 2.Add one project and navigate to Dashboard.
> 3.Check for newly added project in Project drop down.
> Actual behaviour:
> New project is showing in drop down only after refreshing the browser.
> Expected behaviour:
> New project should be shown in drop down without refreshing the browser also.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load

For setting the width of each data item for each row of Port Forwarding 
rules, it was processing all rules.

Basically for each data item, it was searching in all rules, which is 
un-necessary.
If there are N-Rules, It was processing N-times.

Now, it only processes one time by taking all N-rules at a time.
The previous solution was of O(NxN). Now its changed to O(N).

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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin15

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

https://github.com/apache/cloudstack/pull/1081.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 #1081


commit 48df255f71e9938cc9e0879cbc60d9a0a778d95a
Author: Nitin Kumar Maharana 
Date:   2015-11-17T17:32:55Z

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load

For setting the width of each data item for each row of Port Forwarding 
rules, it was processing all rules.

Basically for each data item, it was searching in all rules, which is 
un-necessary.
If there are N-Rules, It was processing N-times.

Now, it only processes one time by taking all N-rules at a time.
The previous solution was of O(NxN). Now its changed to O(N).




> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Updated] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed

[Carles Figuerola (JIRA)]

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

Carles Figuerola updated CLOUDSTACK-9071:
-
Description: 
After inputting a malformed uri (was missing the graphite://) and restarting 
the management service, the application stops at:

2015-11-17 11:06:42,861 INFO  [c.c.s.StatsCollector] 
(localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol 
for external statistics. No statistics will be send.

No more logs are output and tomcat is up but serving a completely blank page.

When the uri has this form: (graphite://metrics.dev.company.net:2013), the end 
result is very similar to the previous one

(also, the last word should be "sent")

  was:
After inputting a malformed uri (was missing the graphite://) and restarting 
the management service, the application stops at:

2015-11-17 11:06:42,861 INFO  [c.c.s.StatsCollector] 
(localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol 
for external statistics. No statistics will be send.

No more logs are output and tomcat is up but serving a completely blank page.

(also, the last word should be "sent")


> stats.output.uri stops the server from starting if the uri is malformed
> ---
>
> Key: CLOUDSTACK-9071
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Carles Figuerola
>
> After inputting a malformed uri (was missing the graphite://) and restarting 
> the management service, the application stops at:
> 2015-11-17 11:06:42,861 INFO  [c.c.s.StatsCollector] 
> (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol 
> for external statistics. No statistics will be send.
> No more logs are output and tomcat is up but serving a completely blank page.
> When the uri has this form: (graphite://metrics.dev.company.net:2013), the 
> end result is very similar to the previous one
> (also, the last word should be "sent")



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

[jira] [Created] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed

[Carles Figuerola (JIRA)]

Carles Figuerola created CLOUDSTACK-9071:


 Summary: stats.output.uri stops the server from starting if the 
uri is malformed
 Key: CLOUDSTACK-9071
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.0
Reporter: Carles Figuerola


After inputting a malformed uri (was missing the graphite://) and restarting 
the management service, the application stops at:

2015-11-17 11:06:42,861 INFO  [c.c.s.StatsCollector] 
(localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol 
for external statistics. No statistics will be send.

No more logs are output and tomcat is up but serving a completely blank page.

(also, the last word should be "sent")



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1076#issuecomment-157440647
  
Hi @remibergsma 
Actually 4.6 is nine commits behind this branch. So I am making one more 
pull request with different branch. Thanks.


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load

For setting the width of each data item for each row of Port Forwarding 
rules, it was processing all rules.

Basically for each data item, it was searching in all rules, which is 
un-necessary.
If there are N-Rules, It was processing N-times.

Now, it only processes one time by taking all N-rules at a time.
The previous solution was of O(NxN). Now its changed to O(N).

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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin13

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

https://github.com/apache/cloudstack/pull/1076.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 #1076


commit 3aa63dc76ac1869d62ce42d8e5dc2752ebe71601
Author: Nitin Kumar Maharana 
Date:   2015-11-17T11:57:26Z

CLOUDSTACK-9068: Listing Port Forwarding Rules take too much time to load

For setting the width of each data item for each row of portforwarding 
rules, it was processing all rules.
Basically for each data item, it was searching in all rules, which is 
un-necessary.
If there are N-Rules, It was processing N-times.

Now, it only processes one time by taking all N-rules at a time.
The previous solution was of O(NxN). Now its changed to O(N).




> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[John Kinsella (JIRA)]

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

John Kinsella commented on CLOUDSTACK-9070:
---

Udo - thanks for pointing this out. The release was signed by Rohit Yadiv, but 
it looks like his public key is not in 
http://www.apache.org/dist/cloudstack/KEYS.

I think it's just a simple mistake, not that there's a security risk.

Will see if we can get this straightened out fairly soon. Assigning over to 
Rohit...

> 4.5.x source downloads from apache.org fail gpg integrity test
> --
>
> Key: CLOUDSTACK-9070
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Udo Rader
>
> as described in 
> http://markmail.org/message/37udf7djizul5xuf 
> the currently available source downloads fail the gpg integrity check because 
> the key used to sign the packages is missing from 
> http://www.apache.org/dist/cloudstack/KEYS
> ---CUT-
> [udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
> gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
> gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
> 0EE3D884
> gpg: Can't check signature: public key not found
> ---CUT-
> applies to 4.5.1 and 4.5.2 at least. 
> At least to me this makes the integrity of the source downloads dubious ...



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

[jira] [Updated] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[John Kinsella (JIRA)]

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

John Kinsella updated CLOUDSTACK-9070:
--
Assignee: Rohit Yadav

> 4.5.x source downloads from apache.org fail gpg integrity test
> --
>
> Key: CLOUDSTACK-9070
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Udo Rader
>Assignee: Rohit Yadav
>
> as described in 
> http://markmail.org/message/37udf7djizul5xuf 
> the currently available source downloads fail the gpg integrity check because 
> the key used to sign the packages is missing from 
> http://www.apache.org/dist/cloudstack/KEYS
> ---CUT-
> [udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
> gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
> gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
> 0EE3D884
> gpg: Can't check signature: public key not found
> ---CUT-
> applies to 4.5.1 and 4.5.2 at least. 
> At least to me this makes the integrity of the source downloads dubious ...



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

[jira] [Commented] (CLOUDSTACK-9062) Upgrade AWS SDK to latest version.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9062:


GitHub user borisroman opened a pull request:

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

CLOUDSTACK-9062: Improve S3 implementation.

The S3 implementation is far from finished, this commit focuses on the 
bases.

 - Upgrade AWS SDK to latest version.
 - Rewrite S3 Template downloader.
 - Rewrite S3Utils utility class.
 - Improve addImageStoreS3 API command.
 - Split various classes for convenience.
 - Various minor improvements and code optimizations.

A side effect of the new AWS SDK is that it, by default, uses the V4 
signature. Therefore I added an option to specify the Signer, so it stays 
compatible with previous versions.

Please review thoroughly, both code inspection and (automated) integration 
tests. Currently no integration tests are available specifically for S3. 
Therefore the implementation is needed to be tested manually, for now...

What I tested:
 - Greenfield install -> will download latest systemvm template 
automatically to S3.
 - Upload a template/iso
 - Download a template/iso
- Restart of management server -> list available templates -> doesn't 
download them again if available.



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

$ git pull https://github.com/borisroman/cloudstack CLOUDSTACK-9062

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

https://github.com/apache/cloudstack/pull/1083.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 #1083


commit 8ca0d0730a5739a209dbf7f138ed5e5c482783d8
Author: Boris Schrijver 
Date:   2015-11-13T01:19:24Z

CLOUDSTACK-9062: Improve S3 implementation.

The S3 implementation is far from finished, this commit focusses on the 
bases.

 - Upgrade AWS SDK to latest version.
 - Rewrite S3 Template downloader.
 - Rewrite S3Utils utility class.
 - Improve addImageStoreS3 API command.
 - Split various classes for convenience.
 - Various minor improvements and code optimalisations.

A side effect of the new AWS SDK is that it, by default, uses the V4 
signature. Therefore I added an option to specify the Signer, so it stays 
compatible with previous versions.




> Upgrade AWS SDK to latest version.
> --
>
> Key: CLOUDSTACK-9062
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9062
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.6.0
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
>
> Upgrade AWS SDK to latest version.



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

[jira] [Commented] (CLOUDSTACK-9062) Upgrade AWS SDK to latest version.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9062:


Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/1083#issuecomment-157551229
  
Ping @wido @remibergsma @wilderrodrigues @karuturi


> Upgrade AWS SDK to latest version.
> --
>
> Key: CLOUDSTACK-9062
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9062
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.6.0
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
>
> Upgrade AWS SDK to latest version.



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

[jira] [Commented] (CLOUDSTACK-9055) NPE in update Redundant State of VPC networks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9055:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1073#issuecomment-157485350
  
@wilderrodrigues @remibergsma @DaanHoogland 
this issue indeed happened in my testing environment. After investigation, 
I found the node was shut down unexpectedly. If you ask me if I have reproduced 
it, th answer is no. I would not spent much time on this issue. The issue in 
the code is obvious and the fix is harmless, from my point of view.
The issue is not critical at all.  If you guys think this PR is not good, I 
will close this PR. 




> NPE in update Redundant State of VPC networks
> -
>
> Key: CLOUDSTACK-9055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9055
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> 2015-11-11 08:32:48,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 4 routers to update status.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 0 networks to update RvR status.
> 2015-11-11 08:32:48,705 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-7:ctx-195132c6) Seq 22-1391893759834266981: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:32:58,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) Begin cleanup expired async-jobs
> 2015-11-11 08:32:58,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) End cleanup expired async-jobs
> 2015-11-11 08:33:06,370 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-ab0d6092) Zone 1 is ready to launch console proxy
> 2015-11-11 08:33:06,435 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-2b4d78f6) Zone 1 is ready to launch secondary storage VM
> 2015-11-11 08:33:08,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) Begin cleanup expired async-jobs
> 2015-11-11 08:33:08,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) End cleanup expired async-jobs
> 2015-11-11 08:33:15,441 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-6:ctx-bba99e59) HostStatsCollector is running...
> 2015-11-11 08:33:17,649 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-c64bf7b6) AutoScaling Monitor is running...
> 2015-11-11 08:33:18,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) Begin cleanup expired async-jobs
> 2015-11-11 08:33:18,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) End cleanup expired async-jobs
> 2015-11-11 08:33:18,660 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 4 routers to update status.
> 2015-11-11 08:33:18,663 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:33:18,664 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,673 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-5:ctx-db2e782d) Seq 22-1391893759834266982: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:33:18,674 DEBUG [c.c.a.m.AgentAttache] 
> (RedundantRouterStatusMonitor-10:ctx-7afb35e1) Seq 22-1391893759834266980: 
> Waiting some more time because this is the current command
> 2015-11-11 08:33:18,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 4 routers to update status.
> 2015-11-11 08:33:18,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 1 VPC networks to update Redundant 
> State.
> /RedundantRouterStatusMonitor-10
> 2015-11-11 08:33:18,698 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 0 networks to update RvR 

[jira] [Created] (CLOUDSTACK-9072) Listing Networks under Project view is throwing error message due to accountid included in API

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-9072:


 Summary: Listing Networks under Project view is throwing error 
message due to accountid included in API
 Key: CLOUDSTACK-9072
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9072
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Kumar Maharana


Under Projects view when we click on Networks tab, it throws an error that says 
"“Account and projectId can't be specified together”

Steps
=
1. Create a project and add an account
2. Go to Project View and choose the Project created
3. Click on Networks tab



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user nitin-maharana closed the pull request at:

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


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-157311229
  
@KrisSterckx @nlivens Guys, we are ready to merge this into master/4.7 now. 
Since it was rebased last some weeks ago, I'll do a quick test run against 
current master and will then merge. Thanks all for the hard work!


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8956) NSX/Nicira Plugin does not support NSX v4.2.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8956:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/935#issuecomment-157321576
  
Couple of minor things that can go through now and be fixed after this is 
merged. @miguelaferreira has already tested the PR and showed that it works 
just fine. So, it has my LGTM as well :+1: 

Thanks a lot for your contribution, @nvazquez !

Cheers,
Wilder


> NSX/Nicira Plugin does not support NSX v4.2.1
> -
>
> Key: CLOUDSTACK-8956
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8956
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0, 4.5.0, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.4.4
> Environment: OS: RHEL 6.6
>Reporter: Nicolas Vazquez
> Fix For: 4.5.1, 4.6.0
>
>
> h3. Description of the problem:
> Prior to version 4.2. Nicira/VmWare NSX used a variation of Open vSwitch as 
> means of integrating SDN into hypervisor layer. Cloudstack NiciraNVP plugin 
> was written to support OVS as a bridge to NSX.
> In version 4.2 VMware introduced NSX vSwitch as a replacement for OVS in ESX 
> hypervisors. It is a fork of distributed vSwitch leveraging one of the recent 
> features of ESX called opaque networks. Because of that change the current 
> version of NiciraNVP plugin doesn’t support versions of NSX-MH above 4.2 
> specifically in Vsphere environment. Proposed fix will analyze a version of 
> NVP/NSX API and use proper support for ESX hypervisors.
> vSphere hypervisor mode operations when NV is deployed onto NSX managed 
> network changes:
> * Current mode. A portgroup = UUID of CS VM NIC is created on a local 
> standard switch of the Hypervisor where VM is starting. VM nic is attached to 
> that port group.
> * New mode. No additional port group is created on a HW. No port group 
> cleanup is needed after VM/NIC is destroyed. VM is attached to 1st port group 
> having the following attributes:
> ** opaqueNetworkId string "br-int”
> ** opaqueNetworkType string "nsx.network"
> If portgroup with such attributes is not found a deployment should fail with 
> exception.
> h3. VMware vSphere API version from 5.1 to 5.5:
> Since vSphere API version 5.5, 
> [OpaqueNetworks|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.OpaqueNetwork.html]
>  are introduced. 
> Its description says: 
> bq. This interface defines an opaque network, in the sense that the detail 
> and configuration of the network is unknown to vShpere and is managed by a 
> management plane outside of vSphere. However, the identifier and name of 
> these networks is made available to vSphere so that host and virtual machine 
> virtual ethernet device can connect to them.
> In order to connect a vm's virtual ethernet device to the proper opaque 
> network when deploying a vm into a NSX managed network, we first need to look 
> for a particular opaque network on hosts. This opaque network's id has to be 
> *"br-int"* and its type *"nsx.network"*.
> Since vSphere API version 5.5 
> [HostNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.NetworkInfo.html#opaqueNetwork]
>  introduces a list of available opaque networks for each host. 
> If NSX API version >= 4.2 we look for a 
> [OpaqueNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.OpaqueNetworkInfo.html]
>  which satisfies:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"
> If that opaque network is found, then we need to attach vm's NIC to a virtual 
> ethernet device which support this, so we use 
> [VirtualEthernetCardOpaqueNetworkBackingInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo.html]
>  setting:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"



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

[jira] [Commented] (CLOUDSTACK-9055) NPE in update Redundant State of VPC networks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9055:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1073#issuecomment-157320534
  
code review done: LGTM


> NPE in update Redundant State of VPC networks
> -
>
> Key: CLOUDSTACK-9055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9055
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> 2015-11-11 08:32:48,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 4 routers to update status.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 0 networks to update RvR status.
> 2015-11-11 08:32:48,705 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-7:ctx-195132c6) Seq 22-1391893759834266981: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:32:58,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) Begin cleanup expired async-jobs
> 2015-11-11 08:32:58,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) End cleanup expired async-jobs
> 2015-11-11 08:33:06,370 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-ab0d6092) Zone 1 is ready to launch console proxy
> 2015-11-11 08:33:06,435 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-2b4d78f6) Zone 1 is ready to launch secondary storage VM
> 2015-11-11 08:33:08,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) Begin cleanup expired async-jobs
> 2015-11-11 08:33:08,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) End cleanup expired async-jobs
> 2015-11-11 08:33:15,441 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-6:ctx-bba99e59) HostStatsCollector is running...
> 2015-11-11 08:33:17,649 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-c64bf7b6) AutoScaling Monitor is running...
> 2015-11-11 08:33:18,451 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) Begin cleanup expired async-jobs
> 2015-11-11 08:33:18,455 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) End cleanup expired async-jobs
> 2015-11-11 08:33:18,660 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 4 routers to update status.
> 2015-11-11 08:33:18,663 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 1 VPC networks to update Redundant 
> State.
> 2015-11-11 08:33:18,664 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,673 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-5:ctx-db2e782d) Seq 22-1391893759834266982: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:33:18,674 DEBUG [c.c.a.m.AgentAttache] 
> (RedundantRouterStatusMonitor-10:ctx-7afb35e1) Seq 22-1391893759834266980: 
> Waiting some more time because this is the current command
> 2015-11-11 08:33:18,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 4 routers to update status.
> 2015-11-11 08:33:18,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 1 VPC networks to update Redundant 
> State.
> /RedundantRouterStatusMonitor-10
> 2015-11-11 08:33:18,698 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-8466fef5) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,705 DEBUG [c.c.a.t.Request] 
> (RedundantRouterStatusMonitor-6:ctx-b997744e) Seq 22-1391893759834266983: 
> Sending  { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
>  }
> 2015-11-11 08:33:18,706 DEBUG [c.c.a.m.AgentAttache] 
> 

[jira] [Commented] (CLOUDSTACK-8956) NSX/Nicira Plugin does not support NSX v4.2.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8956:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/935#discussion_r45038549
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 ---
@@ -2076,6 +2087,9 @@ private static void 
postNvpConfigBeforeStart(VirtualMachineMO vmMo, VirtualMachi
 } else if (backing instanceof 
VirtualEthernetCardNetworkBackingInfo) {
 // This NIC is connected to a Virtual Switch
 // Nothing to do
+} else if (backing instanceof 
VirtualEthernetCardOpaqueNetworkBackingInfo) {
+//if NSX API VERSION >= 4.2, connect to br-int 
(nsx.network), do not create portgroup else previous behaviour
+//OK, connected to OpaqueNetwork
--- End diff --

Those 2 else/if blocks should contain some logging in order to inform sys 
admins what is now comments in the code.

You can keep it for now, because it doesn't affect the feature that 
@miguelaferreira has already tested. Once this PR is merged, we can fix it.


> NSX/Nicira Plugin does not support NSX v4.2.1
> -
>
> Key: CLOUDSTACK-8956
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8956
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0, 4.5.0, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.4.4
> Environment: OS: RHEL 6.6
>Reporter: Nicolas Vazquez
> Fix For: 4.5.1, 4.6.0
>
>
> h3. Description of the problem:
> Prior to version 4.2. Nicira/VmWare NSX used a variation of Open vSwitch as 
> means of integrating SDN into hypervisor layer. Cloudstack NiciraNVP plugin 
> was written to support OVS as a bridge to NSX.
> In version 4.2 VMware introduced NSX vSwitch as a replacement for OVS in ESX 
> hypervisors. It is a fork of distributed vSwitch leveraging one of the recent 
> features of ESX called opaque networks. Because of that change the current 
> version of NiciraNVP plugin doesn’t support versions of NSX-MH above 4.2 
> specifically in Vsphere environment. Proposed fix will analyze a version of 
> NVP/NSX API and use proper support for ESX hypervisors.
> vSphere hypervisor mode operations when NV is deployed onto NSX managed 
> network changes:
> * Current mode. A portgroup = UUID of CS VM NIC is created on a local 
> standard switch of the Hypervisor where VM is starting. VM nic is attached to 
> that port group.
> * New mode. No additional port group is created on a HW. No port group 
> cleanup is needed after VM/NIC is destroyed. VM is attached to 1st port group 
> having the following attributes:
> ** opaqueNetworkId string "br-int”
> ** opaqueNetworkType string "nsx.network"
> If portgroup with such attributes is not found a deployment should fail with 
> exception.
> h3. VMware vSphere API version from 5.1 to 5.5:
> Since vSphere API version 5.5, 
> [OpaqueNetworks|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.OpaqueNetwork.html]
>  are introduced. 
> Its description says: 
> bq. This interface defines an opaque network, in the sense that the detail 
> and configuration of the network is unknown to vShpere and is managed by a 
> management plane outside of vSphere. However, the identifier and name of 
> these networks is made available to vSphere so that host and virtual machine 
> virtual ethernet device can connect to them.
> In order to connect a vm's virtual ethernet device to the proper opaque 
> network when deploying a vm into a NSX managed network, we first need to look 
> for a particular opaque network on hosts. This opaque network's id has to be 
> *"br-int"* and its type *"nsx.network"*.
> Since vSphere API version 5.5 
> [HostNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.NetworkInfo.html#opaqueNetwork]
>  introduces a list of available opaque networks for each host. 
> If NSX API version >= 4.2 we look for a 
> [OpaqueNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.OpaqueNetworkInfo.html]
>  which satisfies:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"
> If that opaque network is found, then we need to attach vm's NIC to a virtual 
> ethernet device which support this, so we use 
> 

[jira] [Commented] (CLOUDSTACK-9065) Packaging RPM: Add option for package release version, cleanup and lint

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9065:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1075#issuecomment-157320397
  
code lgtm and my testing is the same as Davis so as I think we want a wide 
range of users to have a go at this: @wido @remibergsma @resmo @karuturi @NuxRo 
@bhaisaab ?


> Packaging RPM: Add option for package release version, cleanup and lint
> ---
>
> Key: CLOUDSTACK-9065
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9065
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.6.0
>Reporter: David Amorim Faria
>Assignee: David Amorim Faria
>Priority: Trivial
>
> In RPM Packaging, add option for package release version.
> Also, code cleanup and some linting.



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

[jira] [Commented] (CLOUDSTACK-9065) Packaging RPM: Add option for package release version, cleanup and lint

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9065:


Github user NuxRo commented on the pull request:

https://github.com/apache/cloudstack/pull/1075#issuecomment-157328375
  
LGTM
I did a centos63 build and it worked as expected.


> Packaging RPM: Add option for package release version, cleanup and lint
> ---
>
> Key: CLOUDSTACK-9065
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9065
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.6.0
>Reporter: David Amorim Faria
>Assignee: David Amorim Faria
>Priority: Trivial
>
> In RPM Packaging, add option for package release version.
> Also, code cleanup and some linting.



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

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157303792
  
Wilder, I do run unit test always, but integration test only to the degree 
that they make sense. Even then it is way more convenient to use the check-pr 
script then to have to manually execute all the steps in it, so given low risk 
changes, especially when I don't expect a large number of iterations, it pays 
to create a PR first. Not every one has the luxury of such a splendid testbed 
as sbp has. I enjoy using a bubble but it is only one. Still working on 
creating my own.


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-8956) NSX/Nicira Plugin does not support NSX v4.2.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8956:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/935#issuecomment-157311867
  
Would be great to include this in 4.7, please ping me when you're ready!


> NSX/Nicira Plugin does not support NSX v4.2.1
> -
>
> Key: CLOUDSTACK-8956
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8956
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0, 4.5.0, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.4.4
> Environment: OS: RHEL 6.6
>Reporter: Nicolas Vazquez
> Fix For: 4.5.1, 4.6.0
>
>
> h3. Description of the problem:
> Prior to version 4.2. Nicira/VmWare NSX used a variation of Open vSwitch as 
> means of integrating SDN into hypervisor layer. Cloudstack NiciraNVP plugin 
> was written to support OVS as a bridge to NSX.
> In version 4.2 VMware introduced NSX vSwitch as a replacement for OVS in ESX 
> hypervisors. It is a fork of distributed vSwitch leveraging one of the recent 
> features of ESX called opaque networks. Because of that change the current 
> version of NiciraNVP plugin doesn’t support versions of NSX-MH above 4.2 
> specifically in Vsphere environment. Proposed fix will analyze a version of 
> NVP/NSX API and use proper support for ESX hypervisors.
> vSphere hypervisor mode operations when NV is deployed onto NSX managed 
> network changes:
> * Current mode. A portgroup = UUID of CS VM NIC is created on a local 
> standard switch of the Hypervisor where VM is starting. VM nic is attached to 
> that port group.
> * New mode. No additional port group is created on a HW. No port group 
> cleanup is needed after VM/NIC is destroyed. VM is attached to 1st port group 
> having the following attributes:
> ** opaqueNetworkId string "br-int”
> ** opaqueNetworkType string "nsx.network"
> If portgroup with such attributes is not found a deployment should fail with 
> exception.
> h3. VMware vSphere API version from 5.1 to 5.5:
> Since vSphere API version 5.5, 
> [OpaqueNetworks|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.OpaqueNetwork.html]
>  are introduced. 
> Its description says: 
> bq. This interface defines an opaque network, in the sense that the detail 
> and configuration of the network is unknown to vShpere and is managed by a 
> management plane outside of vSphere. However, the identifier and name of 
> these networks is made available to vSphere so that host and virtual machine 
> virtual ethernet device can connect to them.
> In order to connect a vm's virtual ethernet device to the proper opaque 
> network when deploying a vm into a NSX managed network, we first need to look 
> for a particular opaque network on hosts. This opaque network's id has to be 
> *"br-int"* and its type *"nsx.network"*.
> Since vSphere API version 5.5 
> [HostNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.NetworkInfo.html#opaqueNetwork]
>  introduces a list of available opaque networks for each host. 
> If NSX API version >= 4.2 we look for a 
> [OpaqueNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.OpaqueNetworkInfo.html]
>  which satisfies:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"
> If that opaque network is found, then we need to attach vm's NIC to a virtual 
> ethernet device which support this, so we use 
> [VirtualEthernetCardOpaqueNetworkBackingInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo.html]
>  setting:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"



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

[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9047:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1049#issuecomment-157306100
  
most network tests passed:
```
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : FAILED ===
FAIL
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : 
EXCEPTION ===
ERROR
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : 
EXCEPTION ===
ERROR
```
will look into those.

vpc tests:
```
--
Ran 42 tests in 11662.679s

OK
```


> rename enums to match best practice naming pattern
> --
>
> Key: CLOUDSTACK-9047
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>
> Enums should have a name starting with a capital according to java best 
> practices. Rename those that don't and add unit tests where relevant.



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

[jira] [Commented] (CLOUDSTACK-8956) NSX/Nicira Plugin does not support NSX v4.2.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8956:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/935#discussion_r45038824
  
--- Diff: 
plugins/network-elements/nicira-nvp/src/main/java/com/cloud/network/nicira/ControlClusterStatus.java
 ---
@@ -84,4 +89,17 @@ public int getActiveCount() {
 }
 
 }
+
+public class ClusterRoleConfig {
--- End diff --

Do those inner classes need to be public?

It's also something we can fix after the merge, unless there is a reason 
for that.


> NSX/Nicira Plugin does not support NSX v4.2.1
> -
>
> Key: CLOUDSTACK-8956
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8956
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0, 4.5.0, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.4.4
> Environment: OS: RHEL 6.6
>Reporter: Nicolas Vazquez
> Fix For: 4.5.1, 4.6.0
>
>
> h3. Description of the problem:
> Prior to version 4.2. Nicira/VmWare NSX used a variation of Open vSwitch as 
> means of integrating SDN into hypervisor layer. Cloudstack NiciraNVP plugin 
> was written to support OVS as a bridge to NSX.
> In version 4.2 VMware introduced NSX vSwitch as a replacement for OVS in ESX 
> hypervisors. It is a fork of distributed vSwitch leveraging one of the recent 
> features of ESX called opaque networks. Because of that change the current 
> version of NiciraNVP plugin doesn’t support versions of NSX-MH above 4.2 
> specifically in Vsphere environment. Proposed fix will analyze a version of 
> NVP/NSX API and use proper support for ESX hypervisors.
> vSphere hypervisor mode operations when NV is deployed onto NSX managed 
> network changes:
> * Current mode. A portgroup = UUID of CS VM NIC is created on a local 
> standard switch of the Hypervisor where VM is starting. VM nic is attached to 
> that port group.
> * New mode. No additional port group is created on a HW. No port group 
> cleanup is needed after VM/NIC is destroyed. VM is attached to 1st port group 
> having the following attributes:
> ** opaqueNetworkId string "br-int”
> ** opaqueNetworkType string "nsx.network"
> If portgroup with such attributes is not found a deployment should fail with 
> exception.
> h3. VMware vSphere API version from 5.1 to 5.5:
> Since vSphere API version 5.5, 
> [OpaqueNetworks|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.OpaqueNetwork.html]
>  are introduced. 
> Its description says: 
> bq. This interface defines an opaque network, in the sense that the detail 
> and configuration of the network is unknown to vShpere and is managed by a 
> management plane outside of vSphere. However, the identifier and name of 
> these networks is made available to vSphere so that host and virtual machine 
> virtual ethernet device can connect to them.
> In order to connect a vm's virtual ethernet device to the proper opaque 
> network when deploying a vm into a NSX managed network, we first need to look 
> for a particular opaque network on hosts. This opaque network's id has to be 
> *"br-int"* and its type *"nsx.network"*.
> Since vSphere API version 5.5 
> [HostNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.NetworkInfo.html#opaqueNetwork]
>  introduces a list of available opaque networks for each host. 
> If NSX API version >= 4.2 we look for a 
> [OpaqueNetworkInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.OpaqueNetworkInfo.html]
>  which satisfies:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"
> If that opaque network is found, then we need to attach vm's NIC to a virtual 
> ethernet device which support this, so we use 
> [VirtualEthernetCardOpaqueNetworkBackingInfo|https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo.html]
>  setting:
> * opaqueNetworkId = "br-int"
> * opaqueNetworkType = "nsx.netork"



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

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[haijiao (JIRA)]

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

haijiao commented on CLOUDSTACK-8746:
-

Is this will be included in ACS 4.7 ?   great feature

> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



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

[jira] [Commented] (CLOUDSTACK-9063) CitrixResourceBase refactor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9063:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1066#issuecomment-157634027
  
Building the environment to start testing this PR


> CitrixResourceBase refactor
> ---
>
> Key: CLOUDSTACK-9063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9063
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>
> https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity 
> report on the class is pretty bad. Some trivial changes can be done to 
> improve. miracles won't happen but improvements can be made.



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

[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9068:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1076#issuecomment-157498727
  
@nitin-maharana You can close this one. When the 4.6 one is merged, it will 
be forwarded merged to master automatically.


> Listing Port Forwarding Rules take too much time to load
> 
>
> Key: CLOUDSTACK-9068
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> ISSUE
> ==
> The performance of listPortForwardingRules slows down dramatically as the 
> number of rules for an IP increases. If there are 100 rules for an IP and it 
> takes over a minute to respond.
> REPRODUCE STEPS
> ==
> 1) Create many port forwarding rules (75-100) for a particular IP.
> 2) View the port forwarding rules for the IP in the UI or directly with the 
> listPortForwardingRules API command.
> 3) Notice the slowness.
> EXPECTED BEHAVIOR
> ==
> listPortForwardingRules should always respond in a reasonable time.
> ACTUAL BEHAVIOR
> ==
> listPortForwardingRules responds very slowly even with less than 100 rules 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9058:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1079#issuecomment-157619773
  
Okay, understood.

I just read the other PR and saw your details about the tests, how you did 
it, ando also saw that @remibergsma already tested the existing features: which 
are working fine.

So, given the tests description + the LGTM from @remibergsma based on the 
marvin tests results, I LGTM this PR.

@dsclose: do you have any experience writing marvin tests? We can help you 
out. We need a test to cover what you described.

Cheers,
Wilder


> Password server causes Windows VMs to switch to blank passwords after each 
> reboot
> -
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Virtual Router
>Affects Versions: 4.5.2
>Reporter: dsclose
>Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords. 
> In response to a "send_my_password" query, if no password was to be served, 
> the /opt/cloud/bin/serve_password.sh script would issue a response with 
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a 
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour 
> is different to the original serve_password.sh. In response to a 
> "send_my_password" query, if no password was to be served, the 
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init 
> script uses a case statement to ignore blank responses. I've not been able to 
> examine the code for the equivalent Windows guest service but it responds 
> very differently.
> If a Windows guest receives a blank response from the password server then it 
> assumes that the password needs to be blank. The log on the windows guest 
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :  
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't 
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with 
> response saved_password
> Because the password server is queried every time the windows service starts, 
> this will result in the guest adopting a blank password every time it is 
> rebooted or the service is restarted. It's probably unrealistic to consider 
> updating the Windows service in every guest currently running in cloudstack. 
> As such it looks like the password server's behaviour needs to be adjusted to 
> match the behaviour that guests expect.



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

[jira] [Commented] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9067:


GitHub user wilderrodrigues opened a pull request:

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

CLOUDSTACK-9067 - As I developer I want to remove all the unused 
router-shell scripts from ACS

This PR removes the unused shell scripts that were present in the ACS 
project. Those script were replaced by the.

Some of the scripts are used by the HyperV Resource, which were hardcoded. 
I took the opportunity to use the Java constants over there as well, so the 
next one touching the code will know they exist and won't hardcode anything.

The following task were applied:

* Remove the shell files and the Java constants that were mapping them;
* Apply the use of the Java constants to the HyperV Resource class;
* Wrap the String.format() method in the StringUtils so we can test the 
changes in the HyperV Resource class.

The last point was added because I do not have a HyperV test environment. 
Hence, I wanted to make sure the tiny code I changed is covered at least by 
unit tests.

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

$ git pull https://github.com/ekholabs/cloudstack 
improvement/remove_scripts-CLOUDSTACK-9067

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

https://github.com/apache/cloudstack/pull/1084.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 #1084


commit 6477bd8ff7f982e10d0d20a97857262897dc05ed
Author: Wilder Rodrigues 
Date:   2015-11-17T11:14:56Z

CLOUDSTACK-9067 - Remove old script file from the project

   - Java constants also removed
   - Project still compiling and all unit tests passing.

commit 1cf57f74d7e59d07a5c003a80b7dcc499dad9be8
Author: Wilder Rodrigues 
Date:   2015-11-17T11:19:52Z

CLOUDSTACK-9067 - Fomatting the code of HypervDirectConnectResource class

commit fdf826c5a139ea70f707f7732d5320e28ec9e704
Author: Wilder Rodrigues 
Date:   2015-11-17T14:01:39Z

CLOUDSTACK-9067 - Add format method to StringUtils class

   - String.format() method is being wrapped to ease the tests
   - Tests added to cover simple string formatting used for the HyperV 
Resource class.

commit 455926907c44193a6f5dd48f0123629e04adf79a
Author: Wilder Rodrigues 
Date:   2015-11-17T14:31:27Z

CLOUDSTACK-9067 - Replace script literal names by constant name.




> As I developer I want to remove all the unused router-shell scripts from ACS
> 
>
> Key: CLOUDSTACK-9067
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9067
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




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

[jira] [Commented] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9067:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1084#issuecomment-157625899
  
Ping @remibergsma @miguelaferreira @karuturi @DaanHoogland @borisroman 

Partial tests results, but I will still run some tests against XenServer 6.2

Cheers,
Wilder

:: Environment 1 ::

* Hardware required: TRUE
* Management Server + MySQL on CentOS 7.1
* One KVM Host on CentOS 7.1
* Agent + Common RPMs built from source


:: Tests Suites Executed ::

```
nosetests --with-marvin 
--marvin-config=/data/shared/marvin/mct-zone1-kvm1-ISOLATED.cfg -s -a 
tags=advanced,required_hardware=true component/test_vpc_redundant.py 
component/test_routers_iptables_default_policy.py 
component/test_routers_network_ops.py component/test_vpc_router_nics.py 
component/test_password_server.py component/test_router_dhcphosts.py 
smoke/test_loadbalance.py smoke/test_internal_lb.py smoke/test_ssvm.py 
smoke/test_vpc_vpn.py smoke/test_network.py
```

:: Environment 2 ::

* Hardware required: FALSE
* Management Server + MySQL on CentOS 7.1
* One KVM Host on CentOS 7.1
* Agent + Common RPMs built from source


:: Tests Suites Executed ::

```
nosetests --with-marvin 
--marvin-config=/data/shared/marvin/mct-zone1-kvm1-ISOLATED.cfg -s -a 
tags=advanced,required_hardware=false smoke/test_routers.py 
smoke/test_reset_vm_on_reboot.py smoke/test_vm_life_cycle.py 
component/test_vpc_routers.py smoke/test_service_offerings.py 
component/test_vpc_offerings.py smoke/test_network_acl.py 
smoke/test_privategw_acl.py smoke/test_network.py
```

:: Summary ::

* Tests executes: 75
* Successfull tests: 74
* Skipped tests: 1(*)
* Failed tests: 0

(*) VM migration, I had only 1 host.

:: Test results for Environment 1 ::

```
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : 
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and 
check default routes ... === TestName: test_02_redundant_VPC_default_routes | 
Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: 
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... ===