[jira] [Commented] (CLOUDSTACK-10132) Extend Multiple Management Servers Support for agents to allow sorting algorithms

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-10132: Fix POM of "agent-lb" project (#2491)

Post fwd merging, this fixes build issues. 

> Extend Multiple Management Servers Support for agents to allow sorting 
> algorithms
> -
>
> Key: CLOUDSTACK-10132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10132
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Multiple Management Servers Support for agents



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

[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10326:
-

nvazquez opened a new pull request #2493: CLOUDSTACK-10326: Prevent hosts fall 
into Maintenance when there are running VMs on it
URL: https://github.com/apache/cloudstack/pull/2493
 
 
   JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
   
   This issue was discovered, fixed and tested on KVM, but applies for every 
hypervisor.
   
   ### Background
   When enabling maintenance mode in a host, host state is put into 
'PrepareForMaintenance' and running VMs are migrated into another host. After 
every VM is migrated, host goes to 'Maintenance' state.
   
   Checks are performed on `ResourceManagerImpl.checkAndMaintan()` method:
   
   - List VMs with host_id = HOST_ID
   - List VMs with last_host_id = HOST_ID and state=Migrating
   
   When both queries are empty, then the host can be put into Maintenance.
   
   When a VM is being migrated to DEST_HOST, its host_id column is set to 
DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then migration 
fails, host_id = last_host_id = ORIGIN_HOST 
   
   ### Issue
   This sequence:
   
   - Enable maintenance mode on ORIGIN_HOST
   - VMs start being migrated to a host, say DEST_HOST
   - checkAndMaintain() starts:
  - First check passes (no VM with host_id = ORIGIN_HOST_ID as those are 
being migrated)
  - Before the second check, one or more migrations fail
  - Second check passes, however there are VMs running on the host as 
migrations have failed.
   - Host goes into Maintenance state.
   
   Screenshots attached, query executed on each case:
   `select id, name, instance_name, state, host_id, last_host_id from 
vm_instance;`
   
   Before enabling maintenance mode on host 4:
   
![cloudstack-10326-initialstate](https://user-images.githubusercontent.com/5295080/37496971-54f6a482-2894-11e8-9976-5097434608b1.png)
   
   While host = 'PrepareForMaintenance' and VM is being migrated to host 1:
   
![cloudstack-10326-migrating](https://user-images.githubusercontent.com/5295080/37497029-a31d6a38-2894-11e8-8e7e-6df725b69252.png)
   
   At this point the first check is performed:
   
![cloudstack-10326-debug1](https://user-images.githubusercontent.com/5295080/37497097-fe6df646-2894-11e8-8dd5-a7e2a8869398.png)
   
   Made migrations fail adding these rules on host 4:
   
   iptables -I OUTPUT -j REJECT -m state --state NEW -m tcp -p tcp --dport 
49152:49215 -m comment --comment 'test block migrations'
   iptables -I OUTPUT -j REJECT -m state --state NEW -m tcp -p tcp --dport 
16509 -m comment --comment 'test block migrations'
   
   Migration failed and VM goes Running into host 4:
   
![cloudstack-10326-migrationfailed](https://user-images.githubusercontent.com/5295080/37497071-dcf8ee76-2894-11e8-8064-0870870ba422.png)
   
   Second check passes and host goes into Maintenance
   
![cloudstack-10326-debug](https://user-images.githubusercontent.com/5295080/37497109-0bc56ae0-2895-11e8-94e9-a00ed1195502.png)
   


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


> Prevent hosts fall into Maintenance when there are running VMs on it
> 
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png, 
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, 
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every 
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into 
> 'PrepareForMaintenance' and running VMs are migrated into another host. After 
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
>  * List VMs with host_id = HOST_ID
>  * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to 
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then 
> migration 

[jira] [Updated] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10326:
-
Description: 
This issue was discovered, fixed and tested on KVM, but applies for every 
hypervisor.
h2. Background

When enabling maintenance mode in a host, host state is put into 
'PrepareForMaintenance' and running VMs are migrated into another host. After 
every VM is migrated, host goes to 'Maintenance' state.

Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
 * List VMs with host_id = HOST_ID
 * List VMs with last_host_id = HOST_ID and state=Migrating

When both queries are empty, then the host can be put into Maintenance.

When a VM is being migrated to DEST_HOST, its host_id column is set to 
DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then migration 
fails, host_id = last_host_id = ORIGIN_HOST 
h2. Issue

This sequence:
 * Enable maintenance mode on ORIGIN_HOST
 * VMs start being migrated to a host, say DEST_HOST
 * checkAndMaintain() starts:
 ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are being 
migrated)
 ** Before the second check, one or more migrations fail
 ** Second check passes, however there are VMs running on the host as 
migrations have failed.
 * Host goes into Maintenance state.

Screenshots attached, query executed on each case:

select id, name, instance_name, state, host_id, last_host_id from vm_instance;

  was:
This issue was discovered, fixed and tested on KVM, but applies for every 
hypervisor.
h2. Background

When enabling maintenance mode in a host, host state is put into 
'PrepareForMaintenance' and running VMs are migrated into another host. After 
every VM is migrated, host goes to 'Maintenance' state.

Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
 * List VMs with host_id = HOST_ID
 * List VMs with last_host_id = HOST_ID and state=Migrating

When both queries are empty, then the host can be put into Maintenance.

When a VM is being migrated to DEST_HOST, its host_id column is set to 
DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then migration 
fails, host_id = last_host_id = ORIGIN_HOST 
h2. Issue

This sequence:
 * Enable maintenance mode on ORIGIN_HOST
 * VMs start being migrated to a host, say DEST_HOST
 * checkAndMaintain() starts:
 ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are being 
migrated)
 ** Before the second check, one or more migrations fail
 ** Second check passes, however there are VMs running on the host as 
migrations have failed.
 * Host goes into Maintenance state.

 


> Prevent hosts fall into Maintenance when there are running VMs on it
> 
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png, 
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, 
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every 
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into 
> 'PrepareForMaintenance' and running VMs are migrated into another host. After 
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
>  * List VMs with host_id = HOST_ID
>  * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to 
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then 
> migration fails, host_id = last_host_id = ORIGIN_HOST 
> h2. Issue
> This sequence:
>  * Enable maintenance mode on ORIGIN_HOST
>  * VMs start being migrated to a host, say DEST_HOST
>  * checkAndMaintain() starts:
>  ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are 
> being migrated)
>  ** Before the second check, one or more migrations fail
>  ** Second check passes, however there are VMs running on the host as 
> migrations have failed.
>  * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;



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

[jira] [Updated] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10326:
-
Attachment: CLOUDSTACK-10326-MigrationFailed.png
CLOUDSTACK-10326-Migrating.png
CLOUDSTACK-10326-InitialState.png
CLOUDSTACK-10326-Debug.png

> Prevent hosts fall into Maintenance when there are running VMs on it
> 
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png, 
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, 
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every 
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into 
> 'PrepareForMaintenance' and running VMs are migrated into another host. After 
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
>  * List VMs with host_id = HOST_ID
>  * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to 
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then 
> migration fails, host_id = last_host_id = ORIGIN_HOST 
> h2. Issue
> This sequence:
>  * Enable maintenance mode on ORIGIN_HOST
>  * VMs start being migrated to a host, say DEST_HOST
>  * checkAndMaintain() starts:
>  ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are 
> being migrated)
>  ** Before the second check, one or more migrations fail
>  ** Second check passes, however there are VMs running on the host as 
> migrations have failed.
>  * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;



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

[jira] [Created] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it

[Nicolas Vazquez (JIRA)]

Nicolas Vazquez created CLOUDSTACK-10326:


 Summary: Prevent hosts fall into Maintenance when there are 
running VMs on it
 Key: CLOUDSTACK-10326
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.11.0.0
Reporter: Nicolas Vazquez
Assignee: Nicolas Vazquez
 Fix For: 4.11.1.0


This issue was discovered, fixed and tested on KVM, but applies for every 
hypervisor.
h2. Background

When enabling maintenance mode in a host, host state is put into 
'PrepareForMaintenance' and running VMs are migrated into another host. After 
every VM is migrated, host goes to 'Maintenance' state.

Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
 * List VMs with host_id = HOST_ID
 * List VMs with last_host_id = HOST_ID and state=Migrating

When both queries are empty, then the host can be put into Maintenance.

When a VM is being migrated to DEST_HOST, its host_id column is set to 
DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then migration 
fails, host_id = last_host_id = ORIGIN_HOST 
h2. Issue

This sequence:
 * Enable maintenance mode on ORIGIN_HOST
 * VMs start being migrated to a host, say DEST_HOST
 * checkAndMaintain() starts:
 ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are being 
migrated)
 ** Before the second check, one or more migrations fail
 ** Second check passes, however there are VMs running on the host as 
migrations have failed.
 * Host goes into Maintenance state.

 



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

DaanHoogland commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373545553
 
 
   @fmaximus @rafaelweingartner @marcaurele @rhtyd @ustcweizhou , can we please 
have further reviews for this? (or mpre discussion) Of couse a flyway kind of 
solution need to be our long term solution.


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

blueorangutan commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373544092
 
 
   Trillian test result (tid-2377)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 27933 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2449-t2377-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 65 look OK, 2 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 502.65 | 
test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.79 | 
test_hostha_kvm.py
   


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10268:
-

blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance 
package script
URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-373530890
 
 
   Trillian test result (tid-2374)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 30030 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2433-t2374-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 66 look OK, 1 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_02_vpc_privategw_static_routes | `Failure` | 181.86 | 
test_privategw_acl.py
   


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


> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains 
> SNAPSHOT
>  ** in the final artifacts (jar) name
>  ** in the final package (rpm, deb) name
>  ** in `/etc/cloudstack-release` file of SystemVMs
>  ** in the Management Server > About dialog
>  * if there's a "branding" string in the POM version (e.g. 
> `x.y.z.a-NAME[-SNAPSHOT]`),  the branding name will be used in the final 
> generated pacakge name such as following:
>   ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
>  ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
>  * branding string can be overriden with newly added `-b, --brand` flag
>  * handle the new format version for VR version
>  * fix long opts (they were broken)
>  * tolerate and show a warning message for unrecognized flags
>  * usage help reformat



--
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=16400920#comment-16400920
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8855:


blueorangutan 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-373480133
 
 
   Trillian test result (tid-2373)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 19887 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2387-t2373-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 66 look OK, 1 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 0.93 | 
test_hostha_kvm.py
   


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: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>




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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

rhtyd commented on issue #2458: CLOUDSTACK-10296: Find time different from last 
timestamp
URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-373457537
 
 
   No @DaanHoogland it's the trigger that is sometimes caused by github that 
kicks these pkging jobs post merge. 


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10231:
-

nvazquez commented on issue #2408: CLOUDSTACK-10231: Asserted fixes for Direct 
Download on KVM
URL: https://github.com/apache/cloudstack/pull/2408#issuecomment-373400478
 
 
   @rhtyd done


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


> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
>  Labels: direct-download,, kvm
> Fix For: 4.11.1.0
>
>
> Several fixes addressed:
>  * Dettach ISO fails when trying to detach a direct download ISO
>  * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238)
>  * Reinstall VM from bypassed registered template (this closes 
> CLOUDSTACK-10250)
>  * Fix upload certificate error message even though operation was successful
>  * Fix metalink download, checksum retry logic and metalink SSVM downloader



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

[jira] [Closed] (CLOUDSTACK-10250) Reinstall VM from bypassed registered template

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez closed CLOUDSTACK-10250.

   Resolution: Fixed
Fix Version/s: 4.11.1.0

Included on CLOUDSTACK-10231

> Reinstall VM from bypassed registered template
> --
>
> Key: CLOUDSTACK-10250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10250
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
>
> This fix allows users to restore a VM from a previously registered template 
> using the Direct Download option (only for KVM currently)
> NOTE: As Reinstall VM button prompts only featured templates, to be able to 
> restore a vm to a Direct Download template, it should be registered as 
> Featured



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

[jira] [Updated] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10231:
-
Labels: direct-download, kvm  (was: )

> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
>  Labels: direct-download,, kvm
> Fix For: 4.11.1.0
>
>
> Several fixes addressed:
>  * Dettach ISO fails when trying to detach a direct download ISO
>  * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238)
>  * Reinstall VM from bypassed registered template (this closes 
> CLOUDSTACK-10250)
>  * Fix upload certificate error message even though operation was successful
>  * Fix metalink download, checksum retry logic and metalink SSVM downloader



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

[jira] [Closed] (CLOUDSTACK-10238) Fix for metalink support on SSVM agents

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez closed CLOUDSTACK-10238.

   Resolution: Fixed
Fix Version/s: 4.11.1.0

Included on CLOUDSTACK-10231

> Fix for metalink support on SSVM agents
> ---
>
> Key: CLOUDSTACK-10238
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10238
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Fix for metalink support



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

[jira] [Updated] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10231:
-
Description: 
Several fixes addressed:
 * Dettach ISO fails when trying to detach a direct download ISO
 * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238)
 * Reinstall VM from bypassed registered template (this closes CLOUDSTACK-10250)
 * Fix upload certificate error message even though operation was successful
 * Fix metalink download, checksum retry logic and metalink SSVM downloader

  was:Dettach ISO fails when trying to detach a direct download ISO (KVM only)


> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Several fixes addressed:
>  * Dettach ISO fails when trying to detach a direct download ISO
>  * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238)
>  * Reinstall VM from bypassed registered template (this closes 
> CLOUDSTACK-10250)
>  * Fix upload certificate error message even though operation was successful
>  * Fix metalink download, checksum retry logic and metalink SSVM downloader



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

[jira] [Updated] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10231:
-
Fix Version/s: 4.11.1.0

> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Dettach ISO fails when trying to detach a direct download ISO (KVM only)



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

[jira] [Updated] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10231:
-
Summary: Asserted fixes for Direct Download on KVM  (was: Detach ISO fails 
for direct downloaded ISO on KVM)

> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
>
> Dettach ISO fails when trying to detach a direct download ISO (KVM only)



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

[jira] [Updated] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-10231:
-
Component/s: KVM

> Asserted fixes for Direct Download on KVM
> -
>
> Key: CLOUDSTACK-10231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
>
> Dettach ISO fails when trying to detach a direct download ISO (KVM only)



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

[jira] [Resolved] (CLOUDSTACK-10268) Fix and enhance package script

[Khosrow Moossavi (JIRA)]

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

Khosrow Moossavi resolved CLOUDSTACK-10268.
---
Resolution: Fixed

> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains 
> SNAPSHOT
>  ** in the final artifacts (jar) name
>  ** in the final package (rpm, deb) name
>  ** in `/etc/cloudstack-release` file of SystemVMs
>  ** in the Management Server > About dialog
>  * if there's a "branding" string in the POM version (e.g. 
> `x.y.z.a-NAME[-SNAPSHOT]`),  the branding name will be used in the final 
> generated pacakge name such as following:
>   ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
>  ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
>  * branding string can be overriden with newly added `-b, --brand` flag
>  * handle the new format version for VR version
>  * fix long opts (they were broken)
>  * tolerate and show a warning message for unrecognized flags
>  * usage help reformat



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373391397
 
 
   Yes. However, that is a consequence of the last merge and is fixed with: 
#2491


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

DaanHoogland commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373391096
 
 
   debian packaging failed and so did jenkins and travis!


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

DaanHoogland commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373390590
 
 
   @blueorangutan test


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

blueorangutan commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373390643
 
 
   @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

blueorangutan commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373380619
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1783


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

rafaelweingartner commented on issue #2449: WIP CLOUDSTACK-10278 idempotent 
column addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373380723
 
 
   I believe so, but we still need to find a better way technical and protocol 
to better manage data model changes in the database.


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10325) Create database upgrade from 4.11.0.0 to 4.11.1.0

[Ernie Janse van Rensburg (JIRA)]

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

Ernie Janse van Rensburg commented on CLOUDSTACK-10325:
---

development done

dev testing done

pull request done [https://github.com/apache/cloudstack/pull/2490]

request for review - in progress

 

> Create database upgrade from 4.11.0.0 to 4.11.1.0
> -
>
> Key: CLOUDSTACK-10325
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10325
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
> Fix For: 4.11.1.0
>
>   Original Estimate: 16h
>  Remaining Estimate: 16h
>
> Create database upgrade from 4.11.0.0 to 4.11.1.0.
> Add missing VMWare version to OS mapping SQL at the same time.



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

ernjvr commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373373896
 
 
   @DaanHoogland no further comments or objections from anyone. Can the request 
be merged?


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371916
 
 
   @blueorangutan test


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371964
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

blueorangutan commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373366996
 
 
   @DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10278:
-

DaanHoogland commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column 
addition
URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373366839
 
 
   Discussion seems to go stale, are we now done with all comments @ernjvr ?
   @blueorangutan package


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


> Adding a SQL table column is not Idempotent
> ---
>
> Key: CLOUDSTACK-10278
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.10.0.0, 4.11.0.0
>Reporter: Ernie Janse van Rensburg
>Assignee: Ernie Janse van Rensburg
>Priority: Major
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The SQL code to add a new column to a table in the 
> META-INF/db/schema-41000to41100.sql script is not written in an idempotent 
> way. When the upgrade is re-run, the code above causes a SQL error as 
> reported on the user mailing list: 
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc
> INT(1) NOT NULL DEFAULT 0
> This is a more generic problem for every version due to to the fact that it 
> is not idempotent
>  



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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

DaanHoogland commented on issue #2458: CLOUDSTACK-10296: Find time different 
from last timestamp
URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-373365586
 
 
   wow, blueorangutan came back with a stale package result after merge! need 
more oil in the machine, something got stuck


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373354280
 
 
   Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1781


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



--
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=16400284#comment-16400284
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10311:
-

blueorangutan commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate 
variable replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-373351125
 
 
   Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1779


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-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different 
from last timestamp
URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-373349665
 
 
   Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1778


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373348135
 
 
   @blueorangutan package


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373348238
 
 
   @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10132) Extend Multiple Management Servers Support for agents to allow sorting algorithms

[ASF subversion and git services (JIRA)]

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

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

Commit 30175d6879ff323f0e1abac71a9fe3a7232f8b61 in cloudstack's branch 
refs/heads/master from [~rohithsharma]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=30175d6 ]

CLOUDSTACK-10132: Extend support for management servers LB for agents (#2469)

The new CA framework introduced basic support for comma-separated
list of management servers for agent, which makes an external LB
unnecessary.

This extends that feature to implement LB sorting algorithms that
sorts the management server list before they are sent to the agents.
This adds a central intelligence in the management server and adds
additional enhancements to Agent class to be algorithm aware and
have a background mechanism to check/fallback to preferred management
server (assumed as the first in the list). This is support for any
indirect agent such as the KVM, CPVM and SSVM agent, and would
provide support for management server host migration during upgrade
(when instead of in-place, new hosts are used to setup new mgmt server).

This FR introduces two new global settings:

- `indirect.agent.lb.algorithm`: The algorithm for the indirect agent LB.
- `indirect.agent.lb.check.interval`: The preferred host check interval
  for the agent's background task that checks and switches to agent's
  preferred host.

The indirect.agent.lb.algorithm supports following algorithm options:

- static: use the list as provided.
- roundrobin: evenly spreads hosts across management servers based on
  host's id.
- shuffle: (pseudo) randomly sorts the list (not recommended for production).

Any changes to the global settings - `indirect.agent.lb.algorithm` and
`host` does not require restarting of the mangement server(s) and the
agents. A message bus based system dynamically reacts to change in these
global settings and propagates them to all connected agents.

Comma-separated management server list is propagated to agents on
following cases:
- Addition of a host (including ssvm, cpvm systevms).
- Connection or reconnection by the agents to a management server.
- After admin changes the 'host' and/or the
  'indirect.agent.lb.algorithm' global settings.

On the agent side, the 'host' setting is saved in its properties file as:
`host=@`.

First the agent connects to the management server and sends its current
management server list, which is compared by the management server and
in case of failure a new/update list is sent for the agent to persist.

>From the agent's perspective, the first address in the propagated list
will be considered the preferred host. A new background task can be
activated by configuring the `indirect.agent.lb.check.interval` which is
a cluster level global setting from CloudStack and admins can also
override this by configuring the 'host.lb.check.interval' in the
`agent.properties` file.

Every time agent gets a ms-host list and the algorithm, the host specific
background check interval is also sent and it dynamically reconfigures
the background task without need to restart agents.

Note: The 'static' and 'roundrobin' algorithms, strictly checks for the
order as expected by them, however, the 'shuffle' algorithm just checks
for content and not the order of the comma separate ms host addresses.

Signed-off-by: Rohit Yadav 


> Extend Multiple Management Servers Support for agents to allow sorting 
> algorithms
> -
>
> Key: CLOUDSTACK-10132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10132
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Multiple Management Servers Support for agents



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

[jira] [Commented] (CLOUDSTACK-1253) remove @author tags from codebase

[ASF subversion and git services (JIRA)]

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

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

Commit 19d6578732311872d8232276e248e509bf730a82 in cloudstack's branch 
refs/heads/master from [~smeetsr]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=19d6578 ]

CLOUDSTACK-10303 : Refactor test data to nuage_test_data.py runnable against 
simulator (#2483)

* Refactored nuage tests

Added simulator support for ConfigDrive
Allow all nuage tests to run against simulator
Refactored nuage tests to remove code duplication

* Move test data from test_data.py to nuage_test_data.py

Nuage test data is now contained in nuage_test_data.py instead of
test_data.py
Removed all nuage test data from nuage_test_data.py

* CLOUD-1252 fixed cleanup of vpc tier network

* Import libVSD into the codebase

* CLOUDSTACK-1253: Volumes are not expunged in simulator

* Fixed some merge issues in test_nuage_vsp_mngd_subnets test

* Implement GetVolumeStatsCommand in Simulator

* Add vspk as marvin nuagevsp dependency, after removing libVSD dependency

* correct libVSD files for license purposes

pep8 pyflakes compliant


> remove @author tags from codebase
> -
>
> Key: CLOUDSTACK-1253
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1253
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Prasanna Santhanam
>Priority: Major
> Fix For: 4.3.2
>
>
> As of Jun 8 2013 (2dc25df62)
> console-proxy/src/com/cloud/consoleproxy/ConsoleProxyPasswordBasedEncryptor.java:
>  * @author Kelven Yang
> console-proxy/src/com/cloud/consoleproxy/vnc/packet/client/FramebufferUpdateRequestPacket.java:
>  * @author Volodymyr M. Lisivka
> engine/api/src/org/apache/cloudstack/engine/cloud/entity/api/BackupEntity.java:
>  * @author ahuang
> engine/api/src/org/apache/cloudstack/engine/cloud/entity/api/NicEntity.java: 
> * @author ahuang
> engine/storage/integration-test/test/org/apache/cloudstack/storage/test/StorageFactoryBean.java:
>  * @author Mattias Severson, Jayway
> plugins/hypervisors/baremetal/resources/security_group_agent/security_group_agent/cs_sg_agent.py:@author:
>  frank
> plugins/hypervisors/baremetal/resources/security_group_agent/security_group_agent/xmlobject.py:@author:
>  Frank
> plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/element/DnsNotifier.java:
>  * @author ahuang
> scripts/network/ping/baremetal_user_data.py:@author: frank
> Some of the following have been resolved:
> As of Feb 8: (f65ba4)
> api/src/com/cloud/exception/RequestLimitException.java: * @author minc
> api/src/org/apache/cloudstack/api/ApiErrorCode.java: * @author minc
> api/src/org/apache/cloudstack/query/QueryService.java: * @author minc
> awsapi/src/com/cloud/bridge/io/DimeDelimitedInputStream.java: * @author Rick 
> Rineholt
> console-proxy/src/com/cloud/consoleproxy/vnc/packet/client/FramebufferUpdateRequestPacket.java:
>  * @author Volodymyr M. Lisivka
> deps/XenServerJava/src/com/xensource/xenapi/Auth.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Blob.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Bond.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Console.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Crashdump.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/DRTask.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/DataSource.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Event.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/GPUGroup.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Host.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/HostCpu.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/HostCrashdump.java: * @author 
> Citrix Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/HostMetrics.java: * @author 
> Citrix Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/HostPatch.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Message.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/Network.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/PBD.java: * @author Citrix 
> Systems, Inc.
> deps/XenServerJava/src/com/xensource/xenapi/PCI.java: * @author Citrix 
> Systems, Inc.
> 

[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM

[ASF subversion and git services (JIRA)]

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

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

Commit 74db647dbbaa224ffa5667a3203d53f48532d072 in cloudstack's branch 
refs/heads/master from [~nicolas.vazquez]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=74db647 ]

CLOUDSTACK-10321: CPU Cap for KVM (#2482)



> CPU Cap for KVM
> ---
>
> Key: CLOUDSTACK-10321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
>




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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-10296: Find time different from last timestamp (#2458)

This fixes a difference issue in rVR heartbeat check script raised
recently on dev@.
Reduce logging to avoid logging to fill ramdisk
Make checkrouter return fault state when keepalived is not running

Signed-off-by: Rohit Yadav 


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file

[ASF subversion and git services (JIRA)]

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

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

Commit 19d6578732311872d8232276e248e509bf730a82 in cloudstack's branch 
refs/heads/master from [~smeetsr]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=19d6578 ]

CLOUDSTACK-10303 : Refactor test data to nuage_test_data.py runnable against 
simulator (#2483)

* Refactored nuage tests

Added simulator support for ConfigDrive
Allow all nuage tests to run against simulator
Refactored nuage tests to remove code duplication

* Move test data from test_data.py to nuage_test_data.py

Nuage test data is now contained in nuage_test_data.py instead of
test_data.py
Removed all nuage test data from nuage_test_data.py

* CLOUD-1252 fixed cleanup of vpc tier network

* Import libVSD into the codebase

* CLOUDSTACK-1253: Volumes are not expunged in simulator

* Fixed some merge issues in test_nuage_vsp_mngd_subnets test

* Implement GetVolumeStatsCommand in Simulator

* Add vspk as marvin nuagevsp dependency, after removing libVSD dependency

* correct libVSD files for license purposes

pep8 pyflakes compliant


> refactor plugins/nuagevsp tests to run from its own test_data.py file
> -
>
> Key: CLOUDSTACK-10303
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.11.0.0
> Environment: nuagevsp, simulator
>Reporter: Raf Smeets
>Assignee: Sigert Goeminne
>Priority: Major
>
> refactor plugins/nuagevsp tests to run from its own test_data.py file and 
> make sure that all nuagevsp tests run with simulator.



--
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=16400240#comment-16400240
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10311:
-

blueorangutan commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate 
variable replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-373339568
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


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-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=16400239#comment-16400239
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10311:
-

rhtyd commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate variable 
replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-373339530
 
 
   Can you check the build failures @Slair1 ? (See travis for details, or 
confirm you're able to build without failures?).
   
   @blueorangutan package


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-10132) Extend Multiple Management Servers Support for agents to allow sorting algorithms

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10132:
-

rhtyd closed pull request #2469: CLOUDSTACK-10132: Extend support for 
management servers LB for agents
URL: https://github.com/apache/cloudstack/pull/2469
 
 
   

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/agent/conf/agent.properties b/agent/conf/agent.properties
index 0354aceadab..ad35b96bab6 100644
--- a/agent/conf/agent.properties
+++ b/agent/conf/agent.properties
@@ -30,6 +30,17 @@ workers=5
 #host= The IP address of management server
 host=localhost
 
+# The time interval in seconds after which agent will check if connected host
+# is the preferred host (the first host in the comma-separated list is 
preferred
+# one) and will attempt to reconnect to the preferred host when it's connected
+# to one of the secondary/backup hosts. The timer task is scheduled after agent
+# connects to a management server. On connection, it receives admin configured
+# cluster-level 'indirect.agent.lb.check.interval' setting that will be used by
+# the agent as the preferred host check interval however the following setting
+# if defined overrides the received value. The value 0 and lb algorithm 
'shuffle'
+# disables this background task.
+#host.lb.check.interval=0
+
 #port = The port management server listening on, default is 8250
 port=8250
 
diff --git a/agent/src/com/cloud/agent/Agent.java 
b/agent/src/com/cloud/agent/Agent.java
index 1c5417bf767..32112540c1c 100644
--- a/agent/src/com/cloud/agent/Agent.java
+++ b/agent/src/com/cloud/agent/Agent.java
@@ -21,6 +21,8 @@
 import java.io.PrintWriter;
 import java.io.StringWriter;
 import java.net.InetAddress;
+import java.net.InetSocketAddress;
+import java.net.Socket;
 import java.net.UnknownHostException;
 import java.nio.channels.ClosedChannelException;
 import java.nio.charset.Charset;
@@ -38,12 +40,15 @@
 import javax.naming.ConfigurationException;
 
 import 
org.apache.cloudstack.agent.directdownload.SetupDirectDownloadCertificate;
+import org.apache.cloudstack.agent.lb.SetupMSListAnswer;
+import org.apache.cloudstack.agent.lb.SetupMSListCommand;
 import org.apache.cloudstack.ca.SetupCertificateAnswer;
 import org.apache.cloudstack.ca.SetupCertificateCommand;
 import org.apache.cloudstack.ca.SetupKeyStoreCommand;
 import org.apache.cloudstack.ca.SetupKeystoreAnswer;
 import org.apache.cloudstack.managed.context.ManagedContextTimerTask;
 import org.apache.cloudstack.utils.security.KeyStoreUtils;
+import org.apache.commons.collections.CollectionUtils;
 import org.apache.commons.io.FileUtils;
 import org.apache.log4j.Logger;
 import org.slf4j.MDC;
@@ -65,6 +70,7 @@
 import com.cloud.exception.AgentControlChannelException;
 import com.cloud.resource.ServerResource;
 import com.cloud.utils.PropertiesUtil;
+import com.cloud.utils.StringUtils;
 import com.cloud.utils.backoff.BackoffAlgorithm;
 import com.cloud.utils.concurrency.NamedThreadFactory;
 import com.cloud.utils.exception.CloudRuntimeException;
@@ -121,6 +127,7 @@ public int value() {
 Long _id;
 
 Timer _timer = new Timer("Agent Timer");
+Timer hostLBTimer;
 
 List _watchList = new ArrayList();
 long _sequence = 0;
@@ -144,7 +151,7 @@ public Agent(final IAgentShell shell) {
 _shell = shell;
 _link = null;
 
-_connection = new NioClient("Agent", _shell.getHost(), 
_shell.getPort(), _shell.getWorkers(), this);
+_connection = new NioClient("Agent", _shell.getNextHost(), 
_shell.getPort(), _shell.getWorkers(), this);
 
 Runtime.getRuntime().addShutdownHook(new ShutdownThread(this));
 
@@ -179,7 +186,7 @@ public Agent(final IAgentShell shell, final int 
localAgentId, final ServerResour
 throw new ConfigurationException("Unable to configure " + 
_resource.getName());
 }
 
-final String host = _shell.getHost();
+final String host = _shell.getNextHost();
 _connection = new NioClient("Agent", host, _shell.getPort(), 
_shell.getWorkers(), this);
 
 // ((NioClient)_connection).setBindAddress(_shell.getPrivateIp());
@@ -255,7 +262,7 @@ public void start() {
 s_logger.info("Attempted to connect to the server, but received an 
unexpected exception, trying again...");
 }
 while (!_connection.isStartup()) {
-final String host = _shell.getHost();
+final String host = _shell.getNextHost();
 _shell.getBackoffAlgorithm().waitBeforeRetry();
 _connection = new NioClient("Agent", host, _shell.getPort(), 
_shell.getWorkers(), this);
 

[jira] [Commented] (CLOUDSTACK-10132) Extend Multiple Management Servers Support for agents to allow sorting algorithms

[ASF subversion and git services (JIRA)]

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

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

Commit 30175d6879ff323f0e1abac71a9fe3a7232f8b61 in cloudstack's branch 
refs/heads/4.11 from [~rohithsharma]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=30175d6 ]

CLOUDSTACK-10132: Extend support for management servers LB for agents (#2469)

The new CA framework introduced basic support for comma-separated
list of management servers for agent, which makes an external LB
unnecessary.

This extends that feature to implement LB sorting algorithms that
sorts the management server list before they are sent to the agents.
This adds a central intelligence in the management server and adds
additional enhancements to Agent class to be algorithm aware and
have a background mechanism to check/fallback to preferred management
server (assumed as the first in the list). This is support for any
indirect agent such as the KVM, CPVM and SSVM agent, and would
provide support for management server host migration during upgrade
(when instead of in-place, new hosts are used to setup new mgmt server).

This FR introduces two new global settings:

- `indirect.agent.lb.algorithm`: The algorithm for the indirect agent LB.
- `indirect.agent.lb.check.interval`: The preferred host check interval
  for the agent's background task that checks and switches to agent's
  preferred host.

The indirect.agent.lb.algorithm supports following algorithm options:

- static: use the list as provided.
- roundrobin: evenly spreads hosts across management servers based on
  host's id.
- shuffle: (pseudo) randomly sorts the list (not recommended for production).

Any changes to the global settings - `indirect.agent.lb.algorithm` and
`host` does not require restarting of the mangement server(s) and the
agents. A message bus based system dynamically reacts to change in these
global settings and propagates them to all connected agents.

Comma-separated management server list is propagated to agents on
following cases:
- Addition of a host (including ssvm, cpvm systevms).
- Connection or reconnection by the agents to a management server.
- After admin changes the 'host' and/or the
  'indirect.agent.lb.algorithm' global settings.

On the agent side, the 'host' setting is saved in its properties file as:
`host=@`.

First the agent connects to the management server and sends its current
management server list, which is compared by the management server and
in case of failure a new/update list is sent for the agent to persist.

>From the agent's perspective, the first address in the propagated list
will be considered the preferred host. A new background task can be
activated by configuring the `indirect.agent.lb.check.interval` which is
a cluster level global setting from CloudStack and admins can also
override this by configuring the 'host.lb.check.interval' in the
`agent.properties` file.

Every time agent gets a ms-host list and the algorithm, the host specific
background check interval is also sent and it dynamically reconfigures
the background task without need to restart agents.

Note: The 'static' and 'roundrobin' algorithms, strictly checks for the
order as expected by them, however, the 'shuffle' algorithm just checks
for content and not the order of the comma separate ms host addresses.

Signed-off-by: Rohit Yadav 


> Extend Multiple Management Servers Support for agents to allow sorting 
> algorithms
> -
>
> Key: CLOUDSTACK-10132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10132
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Multiple Management Servers Support for agents



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

[jira] [Commented] (CLOUDSTACK-10132) Extend Multiple Management Servers Support for agents to allow sorting algorithms

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10132:
-

rhtyd commented on issue #2469: CLOUDSTACK-10132: Extend support for management 
servers LB for agents
URL: https://github.com/apache/cloudstack/pull/2469#issuecomment-373339040
 
 
   Thanks, merging this based on test results and two LGTMs.


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


> Extend Multiple Management Servers Support for agents to allow sorting 
> algorithms
> -
>
> Key: CLOUDSTACK-10132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10132
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Multiple Management Servers Support for agents



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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different 
from last timestamp
URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-373338731
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

rhtyd closed pull request #2458: CLOUDSTACK-10296: Find time different from 
last timestamp
URL: https://github.com/apache/cloudstack/pull/2458
 
 
   

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/systemvm/debian/opt/cloud/bin/checkrouter.sh 
b/systemvm/debian/opt/cloud/bin/checkrouter.sh
index 0a9041bfbd1..bb6c9f8a0f2 100755
--- a/systemvm/debian/opt/cloud/bin/checkrouter.sh
+++ b/systemvm/debian/opt/cloud/bin/checkrouter.sh
@@ -17,6 +17,13 @@
 # under the License.
 
 STATUS=UNKNOWN
+
+if [ "$(systemctl is-active keepalived)" != "active" ]
+then
+echo "Status: FAULT"
+exit
+fi
+
 ROUTER_TYPE=$(cat /etc/cloudstack/cmdline.json | grep type | awk '{print $2;}' 
| sed -e 's/[,\"]//g')
 if [ "$ROUTER_TYPE" = "router" ]
 then
diff --git a/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ 
b/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ
index 2ab9abaa8a4..62a2b180e6c 100755
--- a/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ
+++ b/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ
@@ -16,48 +16,52 @@
 # specific language governing permissions and limitations
 # under the License.
 
-ROUTER_BIN_PATH=/ramdisk/rrouter
-ROUTER_LOG=${ROUTER_BIN_PATH}/keepalived.log
+ROUTER_BIN_PATH="/ramdisk/rrouter"
+ROUTER_LOG="${ROUTER_BIN_PATH}/keepalived.log"
 STRIKE_FILE="$ROUTER_BIN_PATH/keepalived.strikes"
+TS_FILE="$ROUTER_BIN_PATH/keepalived.ts"
+CT_FILE="$ROUTER_BIN_PATH/keepalived.ct"
 
-if [ -e $ROUTER_BIN_PATH/keepalived.ts2 ]
+checktime=$(date +%s)
+hbtime=$(cat $TS_FILE)
+diff=$(($checktime - $hbtime))
+
+lastcheck=0
+if [ -e $CT_FILE ]
+then
+lastcheck=$(cat $CT_FILE 2>/dev/null)
+fi
+checkdiff=$(($checktime - $lastcheck))
+if [ $checkdiff -ge 0 ] && [ $checkdiff -lt 30 ]
+then
+exit
+fi
+echo $checktime > $CT_FILE
+
+s=0
+if [ $diff -gt 10 ]
 then
-thistime=$(cat $ROUTER_BIN_PATH/keepalived.ts)
-lasttime=$(cat $ROUTER_BIN_PATH/keepalived.ts2)
-diff=$(($lasttime - $thistime))
-s=0
-if [ $diff -ge 10 ]
+if [ -e $STRIKE_FILE ]
 then
-if [ -e $STRIKE_FILE ]
-then
-s=`cat $STRIKE_FILE 2>/dev/null`
-fi
-s=$(($s+1))
-echo $s > $STRIKE_FILE
-else
-if [ -e $STRIKE_FILE ]
-then
-rm $STRIKE_FILE
-echo keepalived.strikes file was removed! >> $ROUTER_LOG
-else
-echo keepalived.strikes file does not exist! >> $ROUTER_LOG
-fi
+s=$(cat $STRIKE_FILE 2>/dev/null)
 fi
-#3 strikes rule
-if [ $s -gt 2 ]
-then
-echo Keepalived process is dead! >> $ROUTER_LOG
-systemctl stop keepalived >> $ROUTER_LOG 2>&1
-systemctl stop conntrackd >> $ROUTER_LOG 2>&1
+s=$(($s+1))
+echo $s > $STRIKE_FILE
+echo "Check time: $checktime, last heartbeat time: $hbtime, time diff: 
$diff, strike count: $s" >> $ROUTER_LOG
+else
+rm -f $STRIKE_FILE
+fi
+
+if [ $s -gt 3 ]
+then
+systemctl stop --now keepalived >> $ROUTER_LOG 2>&1
+systemctl stop --now conntrackd >> $ROUTER_LOG 2>&1
 
-#Set fault so we have the same effect as a KeepaliveD fault.
-python /opt/cloud/bin/master.py --fault
+#Set fault so we have the same effect as a KeepaliveD fault.
+python /opt/cloud/bin/master.py --fault
 
-pkill -9 keepalived >> $ROUTER_LOG 2>&1
-pkill -9 conntrackd >> $ROUTER_LOG 2>&1
-echo Status: FAULT \(keepalived process is dead\) >> $ROUTER_LOG
-exit
-fi
+pkill -9 keepalived >> $ROUTER_LOG 2>&1 || true
+pkill -9 conntrackd >> $ROUTER_LOG 2>&1 || true
+echo Status: FAULT \(keepalived process is dead\) >> $ROUTER_LOG
+exit
 fi
-
-cp $ROUTER_BIN_PATH/keepalived.ts $ROUTER_BIN_PATH/keepalived.ts2


 


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>   

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF subversion and git services (JIRA)]

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

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

Commit ab0bce2a1baa4e199a447e3f2d74ca93c026a037 in cloudstack's branch 
refs/heads/4.11 from [~rohithsharma]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=ab0bce2 ]

CLOUDSTACK-10296: Find time different from last timestamp (#2458)

This fixes a difference issue in rVR heartbeat check script raised
recently on dev@.
Reduce logging to avoid logging to fill ramdisk
Make checkrouter return fault state when keepalived is not running

Signed-off-by: Rohit Yadav 


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10296:
-

rhtyd commented on issue #2458: CLOUDSTACK-10296: Find time different from last 
timestamp
URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-373338575
 
 
   Merging this based on test results and review LGTMs.


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


> Fix timestamp difference in heartbeat script for rVRs
> -
>
> Key: CLOUDSTACK-10296
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.9.3.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.11.1.1
>
>
> Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat 
> checker script for rVRs wrongly take difference, that will always be less 
> than or equal to 0.



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373338067
 
 
   Did you pushed your changes to your branch in the remote repository?
   I am checking your branch, but there is no new commit there.


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10268:
-

DaanHoogland closed pull request #2433: CLOUDSTACK-10268: Fix and enhance 
package script
URL: https://github.com/apache/cloudstack/pull/2433
 
 
   

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/engine/schema/src/main/java/com/cloud/upgrade/DatabaseIntegrityChecker.java 
b/engine/schema/src/main/java/com/cloud/upgrade/DatabaseIntegrityChecker.java
index 6111fb16cf2..bb75aacf2b6 100644
--- 
a/engine/schema/src/main/java/com/cloud/upgrade/DatabaseIntegrityChecker.java
+++ 
b/engine/schema/src/main/java/com/cloud/upgrade/DatabaseIntegrityChecker.java
@@ -26,7 +26,8 @@
 import org.apache.log4j.Logger;
 import org.springframework.stereotype.Component;
 
-import com.cloud.maint.Version;
+import org.apache.cloudstack.utils.CloudStackVersion;
+
 import com.cloud.upgrade.dao.VersionDao;
 import com.cloud.utils.component.AdapterBase;
 import com.cloud.utils.component.ComponentLifecycle;
@@ -210,7 +211,7 @@ private boolean checkMissedPremiumUpgradeFor228() {
 return false;
 }
 
-if (Version.compare(Version.trimToPatch(dbVersion), 
Version.trimToPatch("2.2.8")) != 0) {
+if (CloudStackVersion.compare(dbVersion, "2.2.8") != 0) {
 txn.commit();
 return true;
 }
diff --git a/packaging/build-deb.sh b/packaging/build-deb.sh
index d8f2f8f09b0..52a168a95ba 100755
--- a/packaging/build-deb.sh
+++ b/packaging/build-deb.sh
@@ -40,18 +40,104 @@
 # docker run -ti -v /tmp:/src ubuntu:14.04 /bin/bash -c "apt-get update && 
apt-get install -y dpkg-dev python debhelper openjdk-8-jdk genisoimage 
python-mysql.connector maven lsb-release devscripts dh-systemd 
python-setuptools && /src/cloudstack/packaging/build-deb.sh"
 #
 
-cd `dirname $0`
-cd ..
+function usage() {
+cat << USAGE
+Usage: ./build-deb.sh [OPTIONS]...
+Package CloudStack for Debian based distribution.
+
+If there's a "branding" string in the POM version (e.g. 
x.y.z.a-NAME[-SNAPSHOT]), the branding name will
+be used in the final generated pacakge like: 
cloudstack-management_x.y.z.a-NAME-SNAPSHOT~xenial_all.deb
+note that you can override/provide "branding" string with "-b, --brand" flag 
as well.
+
+Optional arguments:
+   -b, --brand string  Set branding to be used in package 
name (it will override any branding string in POM version)
+   -T, --use-timestamp Use epoch timestamp instead of 
SNAPSHOT in the package name (if not provided, use "SNAPSHOT")
+
+Other arguments:
+   -h, --help  Display this help message and exit
+
+Examples:
+   build-deb.sh --use-timestamp
+   build-deb.sh --brand foo
+
+USAGE
+exit 0
+}
+
+BRANDING=""
+USE_TIMESTAMP="false"
+
+while [ -n "$1" ]; do
+case "$1" in
+-h | --help)
+usage
+;;
+
+-b | --brand)
+if [ -n "$BRANDING" ]; then
+echo "ERROR: you have already entered value for -b, --brand"
+exit 1
+else
+BRANDING=$2
+shift 2
+fi
+;;
+
+-T | --use-timestamp)
+if [ "$USE_TIMESTAMP" == "true" ]; then
+echo "ERROR: you have already entered value for -T, 
--use-timestamp"
+exit 1
+else
+USE_TIMESTAMP="true"
+shift 1
+fi
+;;
+
+-*|*)
+echo "ERROR: no such option $1. -h or --help for help"
+exit 1
+;;
+esac
+done
 
 DCH=$(which dch)
 if [ -z "$DCH" ] ; then
 echo -e "dch not found, please install devscripts at first. \nDEB Build 
Failed"
-exit
+exit 1
 fi
 
+NOW="$(date +%s)"
+PWD=$(cd $(dirname "$0") && pwd -P)
+cd $PWD/../
+
 VERSION=$(head -n1 debian/changelog  |awk -F [\(\)] '{print $2}')
 DISTCODE=$(lsb_release -sc)
 
+if [ "$USE_TIMESTAMP" == "true" ]; then
+# use timestamp instead of SNAPSHOT
+if echo "$VERSION" | grep -q SNAPSHOT ; then
+# apply/override branding, if provided
+if [ "$BRANDING" != "" ]; then
+VERSION=$(echo "$VERSION" | cut -d '-' -f 1) # remove any existing 
branding from POM version to be overriden
+VERSION="$VERSION-$BRANDING-$NOW"
+else
+VERSION=`echo $VERSION | sed 's/-SNAPSHOT/-'$NOW'/g'`
+fi
+
+branch=$(cd $PWD; git rev-parse --abbrev-ref HEAD)
+(cd $PWD; ./tools/build/setnextversion.sh --version $VERSION 

[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script

[ASF subversion and git services (JIRA)]

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

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

Commit 1708838518299d5d04f810d0d01cfb4faf425b03 in cloudstack's branch 
refs/heads/master from [~kmoossavi]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=1708838 ]

CLOUDSTACK-10268: Fix and enhance package script (#2433)

- new flag `-T, --use-timestamp` to use `timestamp` when POM version contains 
SNAPSHOT
  - in the final artifacts (jar) name
  - in the final package (rpm, deb) name
  - in `/etc/cloudstack-release` file of SystemVMs
  - in the Management Server > About dialog
- if there's a "branding" string in the POM version (e.g. 
`x.y.z.a-NAME[-SNAPSHOT]`),
the branding name will be used in the final generated pacakge name such as 
following:
  - `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
  - `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
- branding string can be overriden with newly added `-b, --brand` flag
- handle the new format version for VR version
- fix long opts (they were broken)
- tolerate and show a warning message for unrecognized flags
- usage help reformat

* Deprecate Version class in favor or CloudStackVersion


> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains 
> SNAPSHOT
>  ** in the final artifacts (jar) name
>  ** in the final package (rpm, deb) name
>  ** in `/etc/cloudstack-release` file of SystemVMs
>  ** in the Management Server > About dialog
>  * if there's a "branding" string in the POM version (e.g. 
> `x.y.z.a-NAME[-SNAPSHOT]`),  the branding name will be used in the final 
> generated pacakge name such as following:
>   ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
>  ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
>  * branding string can be overriden with newly added `-b, --brand` flag
>  * handle the new format version for VR version
>  * fix long opts (they were broken)
>  * tolerate and show a warning message for unrecognized flags
>  * usage help reformat



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373336567
 
 
   I'm not sure I'm doing this right.. but git says there's nothing to 
compare.. 
   ![screen shot 2018-03-15 at 12 51 
51](https://user-images.githubusercontent.com/13551960/37459115-c621161e-284f-11e8-8e42-c28590568c96.png)
   any idea? @rafaelweingartner 


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373328490
 
 
   Thanks!
   You can open a PR against my branch, then I can merge it 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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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

[jira] [Commented] (CLOUDSTACK-10307) Remove unused things from HostDaoImpl

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10307:
-

borisstoyanov commented on issue #2438: [CLOUDSTACK-10307] Remove unused things 
from HostDaoImpl
URL: https://github.com/apache/cloudstack/pull/2438#issuecomment-373321486
 
 
   @blueorangutan test 


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 unused things from HostDaoImpl
> -
>
> Key: CLOUDSTACK-10307
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10307
> 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
>
> Remove unnecessary annotation of HostDaoImpl. While removing this annotation 
> I noticed that one of the methods were not necessary. While removing it, I 
> found some code in CloudZonesStartupProcessor that was also not used, and 
> removed it.



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

[jira] [Commented] (CLOUDSTACK-10307) Remove unused things from HostDaoImpl

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10307:
-

blueorangutan commented on issue #2438: [CLOUDSTACK-10307] Remove unused things 
from HostDaoImpl
URL: https://github.com/apache/cloudstack/pull/2438#issuecomment-373321568
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


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 unused things from HostDaoImpl
> -
>
> Key: CLOUDSTACK-10307
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10307
> 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
>
> Remove unnecessary annotation of HostDaoImpl. While removing this annotation 
> I noticed that one of the methods were not necessary. While removing it, I 
> found some code in CloudZonesStartupProcessor that was also not used, and 
> removed it.



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

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373318892
 
 
   @rafaelweingartner I've created a marvin test but I'm not able to push to 
your repo. How can I contribute?


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


> Change disk offering when volume is migrated to different type of storage 
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



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