[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10310:
-

DaanHoogland commented on a change in pull request #2472: CLOUDSTACK-10310 Fix 
KVM reboot on storage issue
URL: https://github.com/apache/cloudstack/pull/2472#discussion_r171781559
 
 

 ##
 File path: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAMonitor.java
 ##
 @@ -115,22 +115,33 @@ protected void runInContext() {
 }
 
 String result = null;
-for (int i = 0; i < 5; i++) {
+// Try 3 times, but sleep in between tries to ensure it 
isn't a short lived transient error
+for (int i = 1; i <= 4; i++) {
 
 Review comment:
   the comment says try three times but i count 4 iterations. either the 
comment or the loop-control needs to change


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KVM hosts reboot if there is a short transient storage error
> 
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus 
> taking down all VMs running on it.  The code does try 5x times before the 
> reboot, but the there is not a delay between the retires, so they are 5 
> simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just 
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between 
> tries so it isn't 5x almost simultaneous tries.  Plus, instead of rebooting, 
> the cloudstack-agent could just be stopped on the host instead.  This will 
> cause alerts to be issued and if the host is disconnected long-enough, 
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10310:
-

DaanHoogland commented on a change in pull request #2472: CLOUDSTACK-10310 Fix 
KVM reboot on storage issue
URL: https://github.com/apache/cloudstack/pull/2472#discussion_r171781689
 
 

 ##
 File path: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAMonitor.java
 ##
 @@ -115,22 +115,33 @@ protected void runInContext() {
 }
 
 String result = null;
-for (int i = 0; i < 5; i++) {
+// Try 3 times, but sleep in between tries to ensure it 
isn't a short lived transient error
+for (int i = 1; i <= 4; i++) {
 Script cmd = new Script(s_heartBeatPath, 
_heartBeatUpdateTimeout, s_logger);
 cmd.add("-i", primaryStoragePool._poolIp);
 cmd.add("-p", primaryStoragePool._poolMountSourcePath);
 cmd.add("-m", primaryStoragePool._mountDestPath);
 cmd.add("-h", _hostIP);
 result = cmd.execute();
 if (result != null) {
-s_logger.warn("write heartbeat failed: " + result 
+ ", retry: " + i);
+s_logger.warn("write heartbeat failed: " + result 
+ ", retry: " + i + " of 4");
 
 Review comment:
   if this 4 in the log message is the same one as the one in the control 
statement you want to extract to a constant/field/variable


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KVM hosts reboot if there is a short transient storage error
> 
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus 
> taking down all VMs running on it.  The code does try 5x times before the 
> reboot, but the there is not a delay between the retires, so they are 5 
> simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just 
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between 
> tries so it isn't 5x almost simultaneous tries.  Plus, instead of rebooting, 
> the cloudstack-agent could just be stopped on the host instead.  This will 
> cause alerts to be issued and if the host is disconnected long-enough, 
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


DaanHoogland commented on issue #23: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: https://github.com/apache/cloudstack-docs/pull/23#issuecomment-369847490
 
 
   and these ...


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


DaanHoogland closed pull request #23: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: https://github.com/apache/cloudstack-docs/pull/23
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/rtd/source/ansible.rst b/rtd/source/ansible.rst
index 6be0134..0493923 100644
--- a/rtd/source/ansible.rst
+++ b/rtd/source/ansible.rst
@@ -294,7 +294,7 @@ For the management server role we create a main.yml task 
like this:
 
- name: Ensure vhdutil is in correct location
 
-     get\_url: url=http://download.cloud.com.s3.amazonaws.com/tools/vhd-util 
dest=/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/vhd-util 
mode=0755
+     get\_url: url=https://download.cloudstack.org/tools/vhd-util 
dest=/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/vhd-util 
mode=0755
 
 
 Save this as `/etc/ansible/roles/cloudstack-management/tasks/main.yml`
@@ -355,13 +355,13 @@ storage.  The playbook for this would look as follows:
 
- name: Seed secondary storage
  command:
-   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
 -h kvm -F
+   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
https://download.cloudstack.org/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
 -h kvm -F
 
  command:
-   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2
 -h xenserver -F
+   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
https://download.cloudstack.org/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2
 -h xenserver -F
 
  command:
-   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ov -h vmware -F
+   
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m {{ tmp\_nfs\_path }} -u 
https://download.cloudstack.org/templates/4.2/systemvmtemplate-4.2-vh7.ov -h 
vmware -F
 
 
 Save this as `/etc/ansible/roles/cloudstack-manager/tasks/seedstorage.yml`


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10310:
-

Slair1 commented on a change in pull request #2472: CLOUDSTACK-10310 Fix KVM 
reboot on storage issue
URL: https://github.com/apache/cloudstack/pull/2472#discussion_r171780920
 
 

 ##
 File path: scripts/vm/hypervisor/kvm/kvmheartbeat.sh
 ##
 @@ -155,10 +155,10 @@ then
   exit 0
 elif [ "$cflag" == "1" ]
 then
-  /usr/bin/logger -t heartbeat "kvmheartbeat.sh rebooted system because it was 
unable to write the heartbeat to the storage."
+  /usr/bin/logger -t heartbeat "kvmheartbeat.sh stopped cloudstack-agent 
because it was unable to write the heartbeat to the storage."
   sync &
   sleep 5
-  echo b > /proc/sysrq-trigger
+  systemctl stop cloudstack-agent
 
 Review comment:
   Good thought, I can change that to “service” for older version compatibility 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KVM hosts reboot if there is a short transient storage error
> 
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus 
> taking down all VMs running on it.  The code does try 5x times before the 
> reboot, but the there is not a delay between the retires, so they are 5 
> simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just 
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between 
> tries so it isn't 5x almost simultaneous tries.  Plus, instead of rebooting, 
> the cloudstack-agent could just be stopped on the host instead.  This will 
> cause alerts to be issued and if the host is disconnected long-enough, 
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


DaanHoogland closed pull request #49: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: https://github.com/apache/cloudstack-docs-admin/pull/49
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/source/locale/fr/LC_MESSAGES/templates.po 
b/source/locale/fr/LC_MESSAGES/templates.po
index 4f606f3..6c90872 100644
--- a/source/locale/fr/LC_MESSAGES/templates.po
+++ b/source/locale/fr/LC_MESSAGES/templates.po
@@ -1556,11 +1556,11 @@ msgstr "Télécharger le fichier du script 
cloud-set-guest-password :"
 
 #: ../../templates/_password.rst:51
 msgid ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in "
-"`_"
+"`https://download.cloudstack.org/templates/4.2/bindir/cloud-set-guest-password.in
 "
+"`_"
 msgstr ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in "
-"`_"
+"`https://download.cloudstack.org/templates/4.2/bindir/cloud-set-guest-password.in
 "
+"`_"
 
 #: ../../templates/_password.rst:54
 msgid "Rename the file:"
diff --git a/source/locale/fr/LC_MESSAGES/templates/_password.po 
b/source/locale/fr/LC_MESSAGES/templates/_password.po
index 6862aa6..48e3a3f 100644
--- a/source/locale/fr/LC_MESSAGES/templates/_password.po
+++ b/source/locale/fr/LC_MESSAGES/templates/_password.po
@@ -102,11 +102,11 @@ msgstr "Télécharger le fichier du script 
cloud-set-guest-password :"
 
 #: ../../templates/_password.rst:51
 msgid ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in "
-"`_"
+"`https://download.cloudstack.org/templates/4.2/bindir/cloud-set-guest-password.in
 "
+"`_"
 msgstr ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in "
-"`_"
+"`https://download.cloudstack.org/templates/4.2/bindir/cloud-set-guest-password.in
 "
+"`_"
 
 #: ../../templates/_password.rst:54
 msgid "Rename the file:"
diff --git a/source/locale/zh_CN/LC_MESSAGES/systemvm.po 
b/source/locale/zh_CN/LC_MESSAGES/systemvm.po
index 3bcfb1d..34f19b2 100644
--- a/source/locale/zh_CN/LC_MESSAGES/systemvm.po
+++ b/source/locale/zh_CN/LC_MESSAGES/systemvm.po
@@ -953,18 +953,18 @@ msgstr "如果有需要，管理员可以登录到辅助存储VM上。"
 
 # 6ea0f846b0a34711b7c0090cb48d8c32
 #~ msgid ""
-#~ 
"http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
+#~ 
"https://download.cloudstack.org/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
 #~ "-master-xen.vhd.bz2"
 #~ msgstr ""
-#~ 
"http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
+#~ 
"https://download.cloudstack.org/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
 #~ "-master-xen.vhd.bz2"
 
 # fe251bca2b854129890cba8e7ac9bbbf
 #~ msgid ""
-#~ 
"http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
+#~ 
"https://download.cloudstack.org/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
 #~ "-master-kvm.qcow2.bz2"
 #~ msgstr ""
-#~ 
"http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
+#~ 
"https://download.cloudstack.org/templates/4.2/64bit/systemvmtemplate64-2013-07-15;
 #~ "-master-kvm.qcow2.bz2"
 
 # 7be31349d45949dfa61f79105ade746f
diff --git a/source/locale/zh_CN/LC_MESSAGES/templates.po 
b/source/locale/zh_CN/LC_MESSAGES/templates.po
index 6d5502d..d762c6e 100644
--- a/source/locale/zh_CN/LC_MESSAGES/templates.po
+++ b/source/locale/zh_CN/LC_MESSAGES/templates.po
@@ -1350,12 +1350,12 @@ msgstr "下载cloud-set-guest-password脚本文件："
 
 #: ../../templates/_password.rst:51
 msgid ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-;
-"password.in `_"
 msgstr ""
-"`http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-;
-"password.in 

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


DaanHoogland commented on issue #49: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: 
https://github.com/apache/cloudstack-docs-admin/pull/49#issuecomment-369847191
 
 
   sorry, i didn't take these into account when doing the change in the code 
@chiradeep . LGTM


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10310:
-

borisstoyanov commented on a change in pull request #2472: CLOUDSTACK-10310 Fix 
KVM reboot on storage issue
URL: https://github.com/apache/cloudstack/pull/2472#discussion_r171776284
 
 

 ##
 File path: scripts/vm/hypervisor/kvm/kvmheartbeat.sh
 ##
 @@ -155,10 +155,10 @@ then
   exit 0
 elif [ "$cflag" == "1" ]
 then
-  /usr/bin/logger -t heartbeat "kvmheartbeat.sh rebooted system because it was 
unable to write the heartbeat to the storage."
+  /usr/bin/logger -t heartbeat "kvmheartbeat.sh stopped cloudstack-agent 
because it was unable to write the heartbeat to the storage."
   sync &
   sleep 5
-  echo b > /proc/sysrq-trigger
+  systemctl stop cloudstack-agent
 
 Review comment:
   @Slair1 are you sure this will work with CentOS6 and debian KVM hosts? Same 
goes with the change above


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KVM hosts reboot if there is a short transient storage error
> 
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus 
> taking down all VMs running on it.  The code does try 5x times before the 
> reboot, but the there is not a delay between the retires, so they are 5 
> simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just 
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between 
> tries so it isn't 5x almost simultaneous tries.  Plus, instead of rebooting, 
> the cloudstack-agent could just be stopped on the host instead.  This will 
> cause alerts to be issued and if the host is disconnected long-enough, 
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


chiradeep opened a new pull request #23: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: https://github.com/apache/cloudstack-docs/pull/23
 
 
   prep for download.cloud.com shutdown


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


chiradeep opened a new pull request #49: CLOUDSTACK-9408 fix docs to remove 
references to download.cloud.com
URL: https://github.com/apache/cloudstack-docs-admin/pull/49
 
 
   download.cloud.com is being shutdown


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10246) VM HA issues

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10246:
-

Slair1 opened a new pull request #2474: CLOUDSTACK-10246 Fix Host HA and VM HA 
issues
URL: https://github.com/apache/cloudstack/pull/2474
 
 
   The HA logic just does not work.  VM's with HA enabled would never restart 
after a host failure.  Had to re-do most of that logic.  There are comments 
inline with the code, but here is the general updated logic.  Sorry for the 
long notes...
   
   We are running KVM FYI.
   
   - If host-agent is unreachable, handleDisconnectWithInvestigation() is 
called as always.
   - The investigators are called to see what happened, which is one of the 
following two scenarios.  (If it isn't one of the two below, then the host just 
came back UP, or another status was returned and that is also logged.  But the 
two scenarios below are what needed updated the most)
   
   **If the investigators find the host is UP, but just the agent is 
unreachable**
   The host is put into DISCONNECTED status.  It will stay in this status and 
the PingTimeouts will continue to call handleDisconnectWithoutInvestigation() 
periodically.  It will stay in DISCONNECTED status until the AlertWait config 
option expires.  If the AlertWait time eventually is hit, and the investigators 
are still just reporting that the host is DISCONNECTED and not DOWN.  Then 
we'll put the host into ALERT state and we'll stay there until the 
investigators say the host is UP or the investigators say the host is DOWN.  If 
the host goes DOWN, then VM HA will be initiated.
   
   **If the investigators find the host is DOWN**
   Then VM HA is initiated...
   
   **VirtualNetworkApplianceManagerImpl.java**
   The file VirtualNetworkApplianceManagerImpl.java is edited for a related VM 
HA problem.  When a Host is determined to be DOWN, CloudStack attempts to VM HA 
any affected routers.  The problem is, when the host is determined to be down, 
by code referenced above, the host may not actually be DOWN.  On KVM for 
example, the host is considered DOWN if the agent is stopped on the KVM host 
for too long.  In that case, the VMs could still be running just fine...  
However when we think the host is DOWN, VM HA runs on the router and as part of 
that it unallocates/cleans-up the router and it's 169.x.x.x control IP is 
unallocated.  Then after it cleans it up, it tries to power on the router on 
another host, and as part of that it allocates a NEW 169.x.x.x control IP and 
writes that to the DB.  However, since the router isn't actually down (we just 
think the host is down) the VM HA fails as the vRouter is currently still 
running on the problem host.  
   
   Next, in this example, when the host agent is back online again, it sends a 
power report to the mgmt servers, and the management servers think the router 
was powered-on OOB.  However, the GUI will not show a control IP for the 
vRouter, and the DB will have the NEW control IP it tried to allocated during 
the failed VM HA event.  Thus, leaving us unable to communicate with the 
vRouter.
   
   This PR does a simple check that we can still communicate with the vRouter 
after any OOB power-on occurs.  If we can, then we have the correct control IP 
in the DB and we're good - so we do nothing.  If we can't communicate with the 
vRouter after the OOB power-on, we do a reboot of the vRouter to fix it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> VM HA issues
> 
>
> Key: CLOUDSTACK-10246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.11.0.0
> Environment: My setup is CentOS 7 Management server with 3 CentOS 7 
> KVM HVs, NFS as primary and secondary storages.
>Reporter: Nux
>Priority: Major
>
> VM HA fails to kick in when one of the hypervisors goes down.
> It even fails to restart the system VMs which remain down along with the 
> instances until the affected HV comes back online.
> When I crash or power off the HV the system marks it in the hosts list as 
> "Alert" or "Disconnected" respectively. It should get changed to "Down" after 
> that, but this never happens.
>  
> I have tried various combinations of setups (Adv, Basic), none succeeded.
>  
> My instances use HA enabled offerings.
> Management server DEBUG logs here:
> 

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

Slair1 opened a new pull request #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473
 
 
   When a user shuts down their VM from the guest OS (and VM HA is enabled), 
the VM just powers itself back on.  Our environment is on KVM hosts.
   
   CloudStack does not know the difference between a VM failing or being 
shutdown from within the guest OS.
   
   This is a major pain point for all our users - especially since they don't 
pay for VMs when they are shutoff.  It is not intuitive for end-users to 
understand why they can't shutdown VMs from within the guest OS.  Especially 
when they all come from (non-cloudstack) VMware and Hyper-V environments where 
this is not an issue.
   
   However, if a host fails, we need VM HA to still work.
   
   This PR that creates a configuration option "ha.vm.restart.hostup".  With 
this option set to false, if CloudStack sees a VM shutdown out-of-band, but the 
host it was on is still *online*, then it won't power the VM back on.  The 
logic is that since the host is online, it was most likely shutdown from the 
guest OS.
   
   For when a host actually fails, standard VM HA logic takes over and powers 
on VMs (if they have VM HA enabled) if the host they were on fails.
   
   If that "ha.vm.restart.hostup" option is true (the default to match current 
functionality), it works like always, and even in-guest shutdowns of VMs causes 
CloudStack to power back on the VM.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10310:
-

Slair1 opened a new pull request #2472: CLOUDSTACK-10310 Fix KVM reboot on 
storage issue
URL: https://github.com/apache/cloudstack/pull/2472
 
 
   If the KVM heartbeat file can't be written to, the host is rebooted, and 
thus taking down all VMs running on it.  The code does try 5x times before the 
reboot, but the there is not a delay between the retires, so they are 5 
simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
or quick network blip could cause this reboot to occur.
   
   Some discussions on the dev mailing list revealed that some people are just 
commenting out the reboot line in their version of the CloudStack source.
   
   A better option would be have it sleep between tries so it isn't 5x almost 
simultaneous tries.  Plus, instead of rebooting, the cloudstack-agent could 
just be stopped on the host instead.  This will cause alerts to be issued and 
if the host is disconnected long-enough, depending on the HA code in use, VM HA 
could handle the host failure.
   
   The built-in reboot of the host seemed drastic


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KVM hosts reboot if there is a short transient storage error
> 
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus 
> taking down all VMs running on it.  The code does try 5x times before the 
> reboot, but the there is not a delay between the retires, so they are 5 
> simultaneous retries, which doesn't help.  Standard SAN storage HA operations 
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just 
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between 
> tries so it isn't 5x almost simultaneous tries.  Plus, instead of rebooting, 
> the cloudstack-agent could just be stopped on the host instead.  This will 
> cause alerts to be issued and if the host is disconnected long-enough, 
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10311:
-

Slair1 opened a new pull request #2471: CLOUDSTACK-10311 Agent Log Rotate 
variable replace bug
URL: https://github.com/apache/cloudstack/pull/2471
 
 
   PR2094 made the log path a variable.  The cloudstack-agent was modified to 
use the @AGENTLOG@ variable entry, but the pom.xml file was not correct to do 
the replacement of the @AGENTLOG@.
   
   Line 62 of the pom.xml handles the replacement with the rename in place


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9677:


khos2ow commented on issue #2412: CLOUDSTACK-9677: Adding storage policy 
support for swift as secondary…
URL: https://github.com/apache/cloudstack/pull/2412#issuecomment-369710850
 
 
   Yes @rafaelweingartner , I will, soon.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Swift Storage Policy support for Secondary Storage
> --
>
> Key: CLOUDSTACK-9677
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Patrick D.
>Assignee: Patrick D.
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[JIRA]

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

Rafael Weingärtner resolved CLOUDSTACK-10259.
-
   Resolution: Fixed
Fix Version/s: 4.12

> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
> Fix For: 4.12
>
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF subversion and git services (JIRA)]

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

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

Commit 9aa34c409269b1c22cab1f894bbd6539d56141c6 in cloudstack's branch 
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9aa34c4 ]

Merge pull request #2439 from rafaelweingartner/CLOUDSTACK-10259

[CLOUDSTACK-10259] Missing float part of secondary storage data in listAccounts 
method

> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10259:
-

rafaelweingartner closed pull request #2439: [CLOUDSTACK-10259] Missing float 
part of secondary storage data in listAccounts method
URL: https://github.com/apache/cloudstack/pull/2439
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/api/src/main/java/com/cloud/configuration/Resource.java 
b/api/src/main/java/com/cloud/configuration/Resource.java
index 0fd51dc2f17..76f2930e615 100644
--- a/api/src/main/java/com/cloud/configuration/Resource.java
+++ b/api/src/main/java/com/cloud/configuration/Resource.java
@@ -38,8 +38,8 @@
 private ResourceOwnerType[] supportedOwners;
 private int ordinal;
 public static final long bytesToKiB = 1024;
-public static final long bytesToMiB = 1024 * 1024;
-public static final long bytesToGiB = 1024 * 1024 * 1024;
+public static final long bytesToMiB = bytesToKiB * 1024;
+public static final long bytesToGiB = bytesToMiB * 1024;
 
 ResourceType(String name, int ordinal, ResourceOwnerType... 
supportedOwners) {
 this.name = name;
diff --git 
a/api/src/main/java/org/apache/cloudstack/api/response/AccountResponse.java 
b/api/src/main/java/org/apache/cloudstack/api/response/AccountResponse.java
index 7b48a1ea8a1..18b11f10bd1 100644
--- a/api/src/main/java/org/apache/cloudstack/api/response/AccountResponse.java
+++ b/api/src/main/java/org/apache/cloudstack/api/response/AccountResponse.java
@@ -29,7 +29,6 @@
 import com.cloud.serializer.Param;
 import com.cloud.user.Account;
 
-@SuppressWarnings("unused")
 @EntityReference(value = Account.class)
 public class AccountResponse extends BaseResponse implements 
ResourceLimitAndCountResponse {
 @SerializedName(ApiConstants.ID)
@@ -222,7 +221,7 @@
 
 @SerializedName("secondarystoragetotal")
 @Param(description = "the total secondary storage space (in GiB) owned by 
account", since = "4.2.0")
-private Long secondaryStorageTotal;
+private float secondaryStorageTotal;
 
 @SerializedName("secondarystorageavailable")
 @Param(description = "the total secondary storage space (in GiB) available 
to be used for this account", since = "4.2.0")
@@ -501,7 +500,7 @@ public void setSecondaryStorageLimit(String 
secondaryStorageLimit) {
 }
 
 @Override
-public void setSecondaryStorageTotal(Long secondaryStorageTotal) {
+public void setSecondaryStorageTotal(float secondaryStorageTotal) {
 this.secondaryStorageTotal = secondaryStorageTotal;
 }
 
diff --git 
a/api/src/main/java/org/apache/cloudstack/api/response/DomainResponse.java 
b/api/src/main/java/org/apache/cloudstack/api/response/DomainResponse.java
index e848759c9e4..7e5bd970d29 100644
--- a/api/src/main/java/org/apache/cloudstack/api/response/DomainResponse.java
+++ b/api/src/main/java/org/apache/cloudstack/api/response/DomainResponse.java
@@ -165,7 +165,7 @@
 private String secondaryStorageLimit;
 
 @SerializedName("secondarystoragetotal") @Param(description="the total 
secondary storage space (in GiB) owned by domain", since="4.2.0")
-private Long secondaryStorageTotal;
+private float secondaryStorageTotal;
 
 @SerializedName("secondarystorageavailable") @Param(description="the total 
secondary storage space (in GiB) available to be used for this domain", 
since="4.2.0")
 private String secondaryStorageAvailable;
@@ -399,7 +399,7 @@ public void setSecondaryStorageLimit(String 
secondaryStorageLimit) {
 }
 
 @Override
-public void setSecondaryStorageTotal(Long secondaryStorageTotal) {
+public void setSecondaryStorageTotal(float secondaryStorageTotal) {
 this.secondaryStorageTotal = secondaryStorageTotal;
 }
 
diff --git 
a/api/src/main/java/org/apache/cloudstack/api/response/ProjectResponse.java 
b/api/src/main/java/org/apache/cloudstack/api/response/ProjectResponse.java
index 0ae9e18612e..8bfa6d94b63 100644
--- a/api/src/main/java/org/apache/cloudstack/api/response/ProjectResponse.java
+++ b/api/src/main/java/org/apache/cloudstack/api/response/ProjectResponse.java
@@ -29,7 +29,6 @@
 import com.cloud.serializer.Param;
 
 @EntityReference(value = Project.class)
-@SuppressWarnings("unused")
 public class ProjectResponse extends BaseResponse implements 
ResourceLimitAndCountResponse {
 
 @SerializedName(ApiConstants.ID)
@@ -134,7 +133,7 @@
 
 @SerializedName("secondarystoragetotal")
 @Param(description = "the total secondary storage space (in GiB) owned by 
project", since = "4.2.0")
-private Long 

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF subversion and git services (JIRA)]

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

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

Commit 73251bf8304ed7e337d98cd5595c17b472481ee7 in cloudstack's branch 
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=73251bf ]

[CLOUDSTACK-10259] Missing float part of secondary storage data in listAccounts


> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF subversion and git services (JIRA)]

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

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

Commit 9aa34c409269b1c22cab1f894bbd6539d56141c6 in cloudstack's branch 
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9aa34c4 ]

Merge pull request #2439 from rafaelweingartner/CLOUDSTACK-10259

[CLOUDSTACK-10259] Missing float part of secondary storage data in listAccounts 
method

> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10259:
-

borisstoyanov commented on issue #2439: [CLOUDSTACK-10259] Missing float part 
of secondary storage data in listAccounts method
URL: https://github.com/apache/cloudstack/pull/2439#issuecomment-369649820
 
 
   @rafaelweingartner 3 LGTMs no conflicts/CI-errors etc.. if I were you I'd be 
pinging people to merge this :) 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10259:
-

rafaelweingartner commented on issue #2439: [CLOUDSTACK-10259] Missing float 
part of secondary storage data in listAccounts method
URL: https://github.com/apache/cloudstack/pull/2439#issuecomment-369649388
 
 
   Ok, thanks!
   then, it seems that everything is ok here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10259:
-

borisstoyanov commented on issue #2439: [CLOUDSTACK-10259] Missing float part 
of secondary storage data in listAccounts method
URL: https://github.com/apache/cloudstack/pull/2439#issuecomment-369649101
 
 
   @rafaelweingartner host_ha are often appearing cause it manipulates host 
state and it appears sometimes fails to fallback. Privategw one is a known 
issue I bealive


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10259:
-

rafaelweingartner commented on issue #2439: [CLOUDSTACK-10259] Missing float 
part of secondary storage data in listAccounts method
URL: https://github.com/apache/cloudstack/pull/2439#issuecomment-369648523
 
 
   @borisstoyanov can we ignore those errors?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Missing float part of secondary storage data when calculating secondary 
> storage usage in listAccounts 
> --
>
> Key: CLOUDSTACK-10259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> There is a non-floating points division that is missing the floating part of 
> the secondary storage usage. This will affect methods that use the following 
> SET method 
> org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String).
> It affects the listAccounts API method, making it differ from the 
> updateResource count method, which is presented in bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8855:


rafaelweingartner commented on issue #2387: CLOUDSTACK-8855 Improve Error 
Message for Host Alert State and reconnect host API.
URL: https://github.com/apache/cloudstack/pull/2387#issuecomment-369641394
 
 
   @DaanHoogland I fixed that test that was not working. I isolated it, and 
then everything started working just fine. I think it was a concurrency problem.
   
   @marcaurele  would you mind finish the review here?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Improve Error Message for Host Alert State
> --
>
> Key: CLOUDSTACK-8855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10257) Create template/volume does not allow to specify HVM requirement

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10257:
-

rafaelweingartner commented on issue #2437: [CLOUDSTACK-10257]Create 
template/volume does not allow to specify HVM requirements
URL: https://github.com/apache/cloudstack/pull/2437#issuecomment-369631095
 
 
   Thanks @khos2ow.
   @DaanHoogland are you ok with changes introduced here?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create template/volume does not allow to specify HVM requirement
> 
>
> Key: CLOUDSTACK-10257
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10257
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> Even when creating a template from a snapshot of a ROOT volume, which has a 
> PV operating system, ACS created the template with flag HVM=1, which may 
> cause problems to deploy the aforementioned template in environments that do 
> not have hosts that support HVM. When creating templates from Snapshots or 
> volumes an option to specify if the template that is going to be created 
> needs HVM or not should be presented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10257) Create template/volume does not allow to specify HVM requirement

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10257:
-

rafaelweingartner commented on issue #2437: [CLOUDSTACK-10257]Create 
template/volume does not allow to specify HVM requirements
URL: https://github.com/apache/cloudstack/pull/2437#issuecomment-369631095
 
 
   Thanks @khos2ow.
   @DaanHoogland are you ok here?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create template/volume does not allow to specify HVM requirement
> 
>
> Key: CLOUDSTACK-10257
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10257
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Minor
>
> Even when creating a template from a snapshot of a ROOT volume, which has a 
> PV operating system, ACS created the template with flag HVM=1, which may 
> cause problems to deploy the aforementioned template in environments that do 
> not have hosts that support HVM. When creating templates from Snapshots or 
> volumes an option to specify if the template that is going to be created 
> needs HVM or not should be presented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10283:
-

rhtyd commented on a change in pull request #2454: CLOUDSTACK-10283: Sudo to 
setup agent keystore, fail on host add failure
URL: https://github.com/apache/cloudstack/pull/2454#discussion_r171580645
 
 

 ##
 File path: agent/src/com/cloud/agent/Agent.java
 ##
 @@ -647,7 +647,7 @@ public Answer setupAgentKeystore(final 
SetupKeyStoreCommand cmd) {
 _shell.setPersistentProperty(null, 
KeyStoreUtils.passphrasePropertyName, storedPassword);
 }
 
-Script script = new Script(_keystoreSetupPath, 6, s_logger);
+Script script = new Script(true, _keystoreSetupPath, 6, s_logger);
 
 Review comment:
   @krissterckx this runs the script with sudo (when true is passed). It allows 
admins to add a KVM host using a non-root sudoer user (see for details 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+non-root+user+to+add+KVM+hypervisor)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use sudo to execute keystore setup/import for kvm agents, and fail on 
> keystore setup failures
> -
>
> Key: CLOUDSTACK-10283
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Addition of a KVM host creates keystore on the KVM host's 
> /etc/cloudstack/agent path. The current scripts and codebase assumes that it 
> will be the root user which is why the script don't call keytool with 'sudo'. 
> To allow addition of host using a sudo-enabled/admin user, make suitable 
> changes to the script, and also fail the addHost execution if keystore 
> scripts fail (say due to permission issues etc).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10283:
-

krissterckx commented on a change in pull request #2454: CLOUDSTACK-10283: Sudo 
to setup agent keystore, fail on host add failure
URL: https://github.com/apache/cloudstack/pull/2454#discussion_r171577491
 
 

 ##
 File path: agent/src/com/cloud/agent/Agent.java
 ##
 @@ -647,7 +647,7 @@ public Answer setupAgentKeystore(final 
SetupKeyStoreCommand cmd) {
 _shell.setPersistentProperty(null, 
KeyStoreUtils.passphrasePropertyName, storedPassword);
 }
 
-Script script = new Script(_keystoreSetupPath, 6, s_logger);
+Script script = new Script(true, _keystoreSetupPath, 6, s_logger);
 
 Review comment:
   sorry what does this mean/do ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use sudo to execute keystore setup/import for kvm agents, and fail on 
> keystore setup failures
> -
>
> Key: CLOUDSTACK-10283
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Addition of a KVM host creates keystore on the KVM host's 
> /etc/cloudstack/agent path. The current scripts and codebase assumes that it 
> will be the root user which is why the script don't call keytool with 'sudo'. 
> To allow addition of host using a sudo-enabled/admin user, make suitable 
> changes to the script, and also fail the addHost execution if keystore 
> scripts fail (say due to permission issues etc).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10283:
-

krissterckx commented on a change in pull request #2454: CLOUDSTACK-10283: Sudo 
to setup agent keystore, fail on host add failure
URL: https://github.com/apache/cloudstack/pull/2454#discussion_r171577491
 
 

 ##
 File path: agent/src/com/cloud/agent/Agent.java
 ##
 @@ -647,7 +647,7 @@ public Answer setupAgentKeystore(final 
SetupKeyStoreCommand cmd) {
 _shell.setPersistentProperty(null, 
KeyStoreUtils.passphrasePropertyName, storedPassword);
 }
 
-Script script = new Script(_keystoreSetupPath, 6, s_logger);
+Script script = new Script(true, _keystoreSetupPath, 6, s_logger);
 
 Review comment:
   sorry what does this mean/do ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use sudo to execute keystore setup/import for kvm agents, and fail on 
> keystore setup failures
> -
>
> Key: CLOUDSTACK-10283
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Addition of a KVM host creates keystore on the KVM host's 
> /etc/cloudstack/agent path. The current scripts and codebase assumes that it 
> will be the root user which is why the script don't call keytool with 'sudo'. 
> To allow addition of host using a sudo-enabled/admin user, make suitable 
> changes to the script, and also fail the addHost execution if keystore 
> scripts fail (say due to permission issues etc).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)