[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR 
downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375820113
 
 
   Trillian test result (tid-2410)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 29914 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2508-t2410-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_usage.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 61 look OK, 6 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_04_extract_template | `Failure` | 128.44 | test_templates.py
   ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py
   test_06_download_detached_volume | `Failure` | 137.76 | test_volumes.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 474.67 | 
test_vpc_redundant.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 3.52 | 
test_host_maintenance.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 3.86 | 
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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-10271) detect vulnerabilities in depndencies

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10271:
-

DaanHoogland opened a new pull request #2446: CLOUDSTACK-10271 maven plugin for 
owasp dependency check added
URL: https://github.com/apache/cloudstack/pull/2446
 
 
   


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


> detect vulnerabilities in depndencies
> -
>
> Key: CLOUDSTACK-10271
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10271
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Major
>
> As a developer I want to know whether and what dependencies I am using that 
> might harm my users. For this we need to add the owasp dependency checker to 
> the maven build. It will require more then just this but it is a good first 
> step.



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


[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-10320 - Invalid pair for response object breaking response parsing 
(#2481)



> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for 
> simplicity I will expose the JSON case. The API response on a 
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" :  ] } }{code}
> To understand how this is possible, assume you have more than one management 
> server and one is processing the destroy of a virtual machine in the account 
> X which is the only one it has. Another process is returning the result of 
> listVirtualMachines for that same account X. During the listVM command, the 
> result set is fetch with a searchAndDistinctCount due to the view 
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
>  This is done through 2 queries in the GenericDao 
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
>  and if you encounter the _right_ conditions, the VM will be marked as 
> removed in between those 2 queries. This results in having a Pair result with 
> at least one object but a count of 0. Then following how is done the 
> serialization of the response at 
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
>  you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair 
> response to ensure a correct response formatting. If the result set contains 
> at least something, the count cannot be 0 but we cannot guess the correct 
> answer, but only state it has at least one element.



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


[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10320:
-

DaanHoogland closed pull request #2481: CLOUDSTACK-10320 - Invalid pair for 
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481
 
 
   

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/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java 
b/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java
index 304a122a0b7..442d3cc181d 100644
--- a/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java
+++ b/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java
@@ -1315,6 +1315,10 @@ protected void addJoins(StringBuilder str, 
Collection searchAndCount(final SearchCriteria sc, 
final Filter filter) {
 List objects = search(sc, filter, null, false);
 Integer count = getCount(sc);
+// Count cannot be less than the result set but can be higher due to 
pagination, see CLOUDSTACK-10320
+if (count < objects.size()) {
+count = objects.size();
+}
 return new Pair(objects, count);
 }
 
@@ -1323,6 +1327,11 @@ protected void addJoins(StringBuilder str, 
Collection searchAndDistinctCount(final 
SearchCriteria sc, final Filter filter) {
 List objects = search(sc, filter, null, false);
 Integer count = getDistinctCount(sc);
+// Count cannot be 0 if there is at least a result in the list, see 
CLOUDSTACK-10320
+if (count == 0 && !objects.isEmpty()) {
+// Cannot assume if it's more than one since the count is distinct 
vs search
+count = 1;
+}
 return new Pair(objects, count);
 }
 
@@ -1331,6 +1340,11 @@ protected void addJoins(StringBuilder str, 
Collection searchAndDistinctCount(final 
SearchCriteria sc, final Filter filter, final String[] distinctColumns) {
 List objects = search(sc, filter, null, false);
 Integer count = getDistinctCount(sc, distinctColumns);
+// Count cannot be 0 if there is at least a result in the list, see 
CLOUDSTACK-10320
+if (count == 0 && !objects.isEmpty()) {
+// Cannot assume if it's more than one since the count is distinct 
vs search
+count = 1;
+}
 return new Pair(objects, count);
 }
 


 


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


> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for 
> simplicity I will expose the JSON case. The API response on a 
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" :  ] } }{code}
> To understand how this is possible, assume you have more than one management 
> server and one is processing the destroy of a virtual machine in the account 
> X which is the only one it has. Another process is returning the result of 
> listVirtualMachines for that same account X. During the listVM command, the 
> result set is fetch with a searchAndDistinctCount due to the view 
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
>  This is done through 2 queries in the GenericDao 
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
>  and if you encounter the _right_ conditions, the VM will be marked as 
> removed in between those 2 queries. This results in having a Pair result with 
> at least one object but a count of 0. Then following how is done the 
> serialization of the response at 
> 

[jira] [Commented] (CLOUDSTACK-10271) detect vulnerabilities in depndencies

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10271:
-

DaanHoogland closed pull request #2446: CLOUDSTACK-10271 maven plugin for owasp 
dependency check added
URL: https://github.com/apache/cloudstack/pull/2446
 
 
   

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/pom.xml b/pom.xml
index b1ff1021af1..274d705be28 100644
--- a/pom.xml
+++ b/pom.xml
@@ -123,6 +123,8 @@
 2.11.0
 9.4.8.v20171121
 
9.2.22.v20170606
+2.1.0.1
+
3.1.1
   
 
   
@@ -370,7 +372,7 @@
   
 org.owasp.esapi
 esapi
-2.1.0.1
+${cs.owasp.esapi.version}
   
   
 org.eclipse.persistence
@@ -569,6 +571,22 @@
   
 install
 
+  
+org.owasp
+dependency-check-maven
+${cs.owasp.dependency-checker.version}
+
+  true
+  true
+
+
+  
+
+  check
+
+  
+
+  
   
 org.apache.maven.plugins
 maven-checkstyle-plugin
@@ -1045,6 +1063,18 @@
   
   
 
+  
+org.owasp
+dependency-check-maven
+${cs.owasp.dependency-checker.version}
+
+  
+
+  aggregate
+
+  
+
+  
   
 org.codehaus.mojo
 findbugs-maven-plugin


 


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


> detect vulnerabilities in depndencies
> -
>
> Key: CLOUDSTACK-10271
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10271
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Major
>
> As a developer I want to know whether and what dependencies I am using that 
> might harm my users. For this we need to add the owasp dependency checker to 
> the maven build. It will require more then just this but it is a good first 
> step.



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


[jira] [Commented] (CLOUDSTACK-10334) Inadequate information for handling catch clauses

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10334:
-

rafaelweingartner commented on a change in pull request #2510: 
CLOUDSTACK-10334: Fix inadequate information for handling catch clauses
URL: https://github.com/apache/cloudstack/pull/2510#discussion_r176784389
 
 

 ##
 File path: server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java
 ##
 @@ -258,11 +258,11 @@ public void processParameters(final BaseCmd cmd, final 
Map params) {
 }
 
 } catch (final IllegalArgumentException e) {
-s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.");
+s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.", e);
 
 Review comment:
   Why do you need to log the stack trace twice? I mean, the exception is 
re-thrown as a cloudruntime. Wherever it is catch, it will probably be logged.
   
   In the Jira ticket you mention that the problem (confusion) is caused by the 
same message in the stack trace. Why not improve the messaging then, instead of 
logging printing the strack trace twice?


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


> Inadequate information for handling catch clauses
> -
>
> Key: CLOUDSTACK-10334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10334
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Zhenhao Li
>Priority: Major
>  Labels: easyfix
>
> Their are some situations that different exception types are caught, but the 
> handling of those exceptions can not show the differences of those types. 
> Here are the code snippets we found which have this problem:
> *cloudstack/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java*
> [https://github.com/apache/cloudstack/blob/893a88d225276e45f12f9490e6af2c94a81c2965/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java]
> At Line *261* and Line *265.* We can see that two exception types are caught, 
> but the logging statements here can not show the exception type at all.
> Also they threw new exceptions after the logs, but the throw statements in 
> these two catch clauses are identical, which are not distinguishable.
> It may cause confusions to the person who is reading the log, the person can 
> not know what exception happened here and can not distinguish logs generated 
> by these two statements.
>  Maybe adding stack trace information to these two logging statements and 
> change the log message to handle specific situations is a simple way to 
> improve it.



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


[jira] [Commented] (CLOUDSTACK-10334) Inadequate information for handling catch clauses

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10334:
-

rhtyd commented on issue #2510: CLOUDSTACK-10334: Fix inadequate information 
for handling catch clauses
URL: https://github.com/apache/cloudstack/pull/2510#issuecomment-375714186
 
 
   The change is simply in error logging, Travis is green so explicit trillian 
tests may not be necessary. +1 on tests based on 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


> Inadequate information for handling catch clauses
> -
>
> Key: CLOUDSTACK-10334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10334
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Zhenhao Li
>Priority: Major
>  Labels: easyfix
>
> Their are some situations that different exception types are caught, but the 
> handling of those exceptions can not show the differences of those types. 
> Here are the code snippets we found which have this problem:
> *cloudstack/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java*
> [https://github.com/apache/cloudstack/blob/893a88d225276e45f12f9490e6af2c94a81c2965/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java]
> At Line *261* and Line *265.* We can see that two exception types are caught, 
> but the logging statements here can not show the exception type at all.
> Also they threw new exceptions after the logs, but the throw statements in 
> these two catch clauses are identical, which are not distinguishable.
> It may cause confusions to the person who is reading the log, the person can 
> not know what exception happened here and can not distinguish logs generated 
> by these two statements.
>  Maybe adding stack trace information to these two logging statements and 
> change the log message to handle specific situations is a simple way to 
> improve it.



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


[jira] [Created] (CLOUDSTACK-10343) UI checkbox is greyed out for "Specify VLAN" on guest network offerings

2018-03-23 Thread Nux (JIRA)
Nux created CLOUDSTACK-10343:


 Summary: UI checkbox is greyed out for "Specify VLAN" on guest 
network offerings
 Key: CLOUDSTACK-10343
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10343
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, UI
Affects Versions: 4.11.0.0
 Environment: CentOS 7 + KVM
Reporter: Nux
 Attachments: Selection_016.png

Hi,

 

The UI checkbox is greyed out for "Specify VLAN" on guest network offerings and 
without it the offering can't be created.

See http://img.nux.ro/3Xx-Selection_016.png



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


[jira] [Commented] (CLOUDSTACK-10334) Inadequate information for handling catch clauses

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10334:
-

lzh3636 opened a new pull request #2510: CLOUDSTACK-10334: Fix inadequate 
information for handling catch clauses
URL: https://github.com/apache/cloudstack/pull/2510
 
 
   ## Description
   The description of the problem:
   https://issues.apache.org/jira/browse/CLOUDSTACK-10334
   I just added stack traces information to those two logging statements, so 
that the exception type can be generated to the logs.
   ## Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [x] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   
   ## Checklist:
   
   
   - [x] I have read the 
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
 document.
   - [x] My code follows the code style of this project.
   - [ ] My change requires a change to the documentation.
   - [ ] I have updated the documentation accordingly.
   - [ ] I have added tests to cover my changes.
   - [x] All new and existing tests passed.
   
   


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


> Inadequate information for handling catch clauses
> -
>
> Key: CLOUDSTACK-10334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10334
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Zhenhao Li
>Priority: Major
>  Labels: easyfix
>
> Their are some situations that different exception types are caught, but the 
> handling of those exceptions can not show the differences of those types. 
> Here are the code snippets we found which have this problem:
> *cloudstack/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java*
> [https://github.com/apache/cloudstack/blob/893a88d225276e45f12f9490e6af2c94a81c2965/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java]
> At Line *261* and Line *265.* We can see that two exception types are caught, 
> but the logging statements here can not show the exception type at all.
> Also they threw new exceptions after the logs, but the throw statements in 
> these two catch clauses are identical, which are not distinguishable.
> It may cause confusions to the person who is reading the log, the person can 
> not know what exception happened here and can not distinguish logs generated 
> by these two statements.
>  Maybe adding stack trace information to these two logging statements and 
> change the log message to handle specific situations is a simple way to 
> improve it.



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


[jira] [Updated] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA

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

Rafael Weingärtner updated CLOUDSTACK-10342:

Description: 
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions.
{code:java}
4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and CLOUDSTACK*
{code}
The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol

  was:
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "
{code:java}
4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and CLOUDSTACK*
{code}
". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol


> Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*
> ---
>
> Key: CLOUDSTACK-10342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches "Remove 
> branches matching the expressions.
> {code:java}
> 4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and CLOUDSTACK*
> {code}
> The branches that will be removed are the following:
> * 4.5.2.1-security-RC20160525T120
> * 4.7.0-RC20151213T2109
> * 4.7.1-RC20160120T2318
> * 4.7.1.1-RC20160525T1230
> * 4.8.0-RC20160120T2343
> * 4.8.0.1-RC20160525T1247
> * 4.8.1-RC20160808T1006
> * 4.8.2.0-RC20161210T0832
> * 4.9-bountycastle-daan
> * 4.9-systemdubuntupkging
> * 4.9.0-RC20160706T1546
> * 4.9.0-RC20160725T1656
> * 4.9.1.0-RC20161210T0838
> * 4.9.2.0-RC20161227T1309
> * CLOUDSTACK-10012
> * CLOUDSTACK-1302
> * CLOUDSTACK-2554
> * CLOUDSTACK-8243
> * CLOUDSTACK-8301
> * CLOUDSTACK-8313
> * CLOUDSTACK-8489
> * CLOUDSTACK-8530
> * CLOUDSTACK-8559
> * CLOUDSTACK-8560
> * CLOUDSTACK-8566
> * CLOUDSTACK-8766
> [1] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol



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


[jira] [Updated] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA

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

Rafael Weingärtner updated CLOUDSTACK-10342:

Description: 
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "4.5.2.1-*, 4.7.\*-\*, 4.8.\*-\*, 4.9\*-\*, and 
CLOUDSTACK*". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol

  was:
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and 
CLOUDSTACK*". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol


> Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*
> ---
>
> Key: CLOUDSTACK-10342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches "Remove 
> branches matching the expressions "4.5.2.1-*, 4.7.\*-\*, 4.8.\*-\*, 4.9\*-\*, 
> and CLOUDSTACK*". The branches that will be removed are the following:
> * 4.5.2.1-security-RC20160525T120
> * 4.7.0-RC20151213T2109
> * 4.7.1-RC20160120T2318
> * 4.7.1.1-RC20160525T1230
> * 4.8.0-RC20160120T2343
> * 4.8.0.1-RC20160525T1247
> * 4.8.1-RC20160808T1006
> * 4.8.2.0-RC20161210T0832
> * 4.9-bountycastle-daan
> * 4.9-systemdubuntupkging
> * 4.9.0-RC20160706T1546
> * 4.9.0-RC20160725T1656
> * 4.9.1.0-RC20161210T0838
> * 4.9.2.0-RC20161227T1309
> * CLOUDSTACK-10012
> * CLOUDSTACK-1302
> * CLOUDSTACK-2554
> * CLOUDSTACK-8243
> * CLOUDSTACK-8301
> * CLOUDSTACK-8313
> * CLOUDSTACK-8489
> * CLOUDSTACK-8530
> * CLOUDSTACK-8559
> * CLOUDSTACK-8560
> * CLOUDSTACK-8566
> * CLOUDSTACK-8766
> [1] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol



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


[jira] [Updated] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA

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

Rafael Weingärtner updated CLOUDSTACK-10342:

Description: 
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "
{code:java}
4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and CLOUDSTACK*
{code}
". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol

  was:
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "4.5.2.1-*, 4.7.\*-\*, 4.8.\*-\*, 4.9\*-\*, and 
CLOUDSTACK*". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol


> Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*
> ---
>
> Key: CLOUDSTACK-10342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches "Remove 
> branches matching the expressions "
> {code:java}
> 4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and CLOUDSTACK*
> {code}
> ". The branches that will be removed are the following:
> * 4.5.2.1-security-RC20160525T120
> * 4.7.0-RC20151213T2109
> * 4.7.1-RC20160120T2318
> * 4.7.1.1-RC20160525T1230
> * 4.8.0-RC20160120T2343
> * 4.8.0.1-RC20160525T1247
> * 4.8.1-RC20160808T1006
> * 4.8.2.0-RC20161210T0832
> * 4.9-bountycastle-daan
> * 4.9-systemdubuntupkging
> * 4.9.0-RC20160706T1546
> * 4.9.0-RC20160725T1656
> * 4.9.1.0-RC20161210T0838
> * 4.9.2.0-RC20161227T1309
> * CLOUDSTACK-10012
> * CLOUDSTACK-1302
> * CLOUDSTACK-2554
> * CLOUDSTACK-8243
> * CLOUDSTACK-8301
> * CLOUDSTACK-8313
> * CLOUDSTACK-8489
> * CLOUDSTACK-8530
> * CLOUDSTACK-8559
> * CLOUDSTACK-8560
> * CLOUDSTACK-8566
> * CLOUDSTACK-8766
> [1] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol



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


[jira] [Updated] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA

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

Rafael Weingärtner updated CLOUDSTACK-10342:

Description: 
Following the protocol defined in [1]. We will remove branches "Remove branches 
matching the expressions "4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and 
CLOUDSTACK*". The branches that will be removed are the following:

* 4.5.2.1-security-RC20160525T120
* 4.7.0-RC20151213T2109
* 4.7.1-RC20160120T2318
* 4.7.1.1-RC20160525T1230
* 4.8.0-RC20160120T2343
* 4.8.0.1-RC20160525T1247
* 4.8.1-RC20160808T1006
* 4.8.2.0-RC20161210T0832
* 4.9-bountycastle-daan
* 4.9-systemdubuntupkging
* 4.9.0-RC20160706T1546
* 4.9.0-RC20160725T1656
* 4.9.1.0-RC20161210T0838
* 4.9.2.0-RC20161227T1309
* CLOUDSTACK-10012
* CLOUDSTACK-1302
* CLOUDSTACK-2554
* CLOUDSTACK-8243
* CLOUDSTACK-8301
* CLOUDSTACK-8313
* CLOUDSTACK-8489
* CLOUDSTACK-8530
* CLOUDSTACK-8559
* CLOUDSTACK-8560
* CLOUDSTACK-8566
* CLOUDSTACK-8766

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol

  was:
Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC 
The branches that will be removed are the following:



> Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*
> ---
>
> Key: CLOUDSTACK-10342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches "Remove 
> branches matching the expressions "4.5.2.1-*, 4.7.*-*, 4.8.*-*, 4.9*-*, and 
> CLOUDSTACK*". The branches that will be removed are the following:
> * 4.5.2.1-security-RC20160525T120
> * 4.7.0-RC20151213T2109
> * 4.7.1-RC20160120T2318
> * 4.7.1.1-RC20160525T1230
> * 4.8.0-RC20160120T2343
> * 4.8.0.1-RC20160525T1247
> * 4.8.1-RC20160808T1006
> * 4.8.2.0-RC20161210T0832
> * 4.9-bountycastle-daan
> * 4.9-systemdubuntupkging
> * 4.9.0-RC20160706T1546
> * 4.9.0-RC20160725T1656
> * 4.9.1.0-RC20161210T0838
> * 4.9.2.0-RC20161227T1309
> * CLOUDSTACK-10012
> * CLOUDSTACK-1302
> * CLOUDSTACK-2554
> * CLOUDSTACK-8243
> * CLOUDSTACK-8301
> * CLOUDSTACK-8313
> * CLOUDSTACK-8489
> * CLOUDSTACK-8530
> * CLOUDSTACK-8559
> * CLOUDSTACK-8560
> * CLOUDSTACK-8566
> * CLOUDSTACK-8766
> [1] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR 
downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375677067
 
 
   @rhtyd 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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375676755
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Updated] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA

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

Rafael Weingärtner updated CLOUDSTACK-10342:

Description: 
Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC 
The branches that will be removed are the following:


> Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*
> ---
>
> Key: CLOUDSTACK-10342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC 
> The branches that will be removed are the following:



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


[jira] [Created] (CLOUDSTACK-10342) Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK*

2018-03-23 Thread JIRA
Rafael Weingärtner created CLOUDSTACK-10342:
---

 Summary: Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and 
CLOUDSTACK*
 Key: CLOUDSTACK-10342
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10342
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rafael Weingärtner






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


[jira] [Commented] (CLOUDSTACK-10334) Inadequate information for handling catch clauses

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10334:
-

lzh3636 closed pull request #2509: CLOUDSTACK-10334: Inadequate information for 
handling catch clauses
URL: https://github.com/apache/cloudstack/pull/2509
 
 
   

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/server/src/com/cloud/api/dispatch/ParamProcessWorker.java 
b/server/src/com/cloud/api/dispatch/ParamProcessWorker.java
index feefaabc551..72cfeb00571 100644
--- a/server/src/com/cloud/api/dispatch/ParamProcessWorker.java
+++ b/server/src/com/cloud/api/dispatch/ParamProcessWorker.java
@@ -258,11 +258,11 @@ public void processParameters(final BaseCmd cmd, final 
Map params) {
 }
 
 } catch (final IllegalArgumentException e) {
-s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.");
+s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.", e);
 throw new CloudRuntimeException("Internal error initializing 
parameters for command " + cmd.getCommandName() + " [field " + field.getName() +
 " is not accessible]");
 } catch (final IllegalAccessException e) {
-s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.");
+s_logger.error("Error initializing command " + 
cmd.getCommandName() + ", field " + field.getName() + " is not accessible.", e);
 throw new CloudRuntimeException("Internal error initializing 
parameters for command " + cmd.getCommandName() + " [field " + field.getName() +
 " is not accessible]");
 }


 


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


> Inadequate information for handling catch clauses
> -
>
> Key: CLOUDSTACK-10334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10334
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Zhenhao Li
>Priority: Major
>  Labels: easyfix
>
> Their are some situations that different exception types are caught, but the 
> handling of those exceptions can not show the differences of those types. 
> Here are the code snippets we found which have this problem:
> *cloudstack/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java*
> [https://github.com/apache/cloudstack/blob/893a88d225276e45f12f9490e6af2c94a81c2965/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java]
> At Line *261* and Line *265.* We can see that two exception types are caught, 
> but the logging statements here can not show the exception type at all.
> Also they threw new exceptions after the logs, but the throw statements in 
> these two catch clauses are identical, which are not distinguishable.
> It may cause confusions to the person who is reading the log, the person can 
> not know what exception happened here and can not distinguish logs generated 
> by these two statements.
>  Maybe adding stack trace information to these two logging statements and 
> change the log message to handle specific situations is a simple way to 
> improve it.



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


[jira] [Commented] (CLOUDSTACK-10334) Inadequate information for handling catch clauses

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10334:
-

lzh3636 opened a new pull request #2509: CLOUDSTACK-10334: Inadequate 
information for handling catch clauses
URL: https://github.com/apache/cloudstack/pull/2509
 
 
   ## Description
   The description of the problem:
   https://issues.apache.org/jira/browse/CLOUDSTACK-10334
   I just added stack traces information to those two logging statements, so 
that the exception type can be generated to the logs.
   ## Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [x] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   
   ## Checklist:
   
   
   - [x] I have read the 
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
 document.
   - [x] My code follows the code style of this project.
   - [ ] My change requires a change to the documentation.
   - [ ] I have updated the documentation accordingly.
   - [ ] I have added tests to cover my changes.
   - [x] All new and existing tests passed.
   
   


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


> Inadequate information for handling catch clauses
> -
>
> Key: CLOUDSTACK-10334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10334
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Zhenhao Li
>Priority: Major
>  Labels: easyfix
>
> Their are some situations that different exception types are caught, but the 
> handling of those exceptions can not show the differences of those types. 
> Here are the code snippets we found which have this problem:
> *cloudstack/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java*
> [https://github.com/apache/cloudstack/blob/893a88d225276e45f12f9490e6af2c94a81c2965/server/src/main/java/com/cloud/api/dispatch/ParamProcessWorker.java]
> At Line *261* and Line *265.* We can see that two exception types are caught, 
> but the logging statements here can not show the exception type at all.
> Also they threw new exceptions after the logs, but the throw statements in 
> these two catch clauses are identical, which are not distinguishable.
> It may cause confusions to the person who is reading the log, the person can 
> not know what exception happened here and can not distinguish logs generated 
> by these two statements.
>  Maybe adding stack trace information to these two logging statements and 
> change the log message to handle specific situations is a simple way to 
> improve it.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR 
downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375668275
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1822


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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


ustcweizhou commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375663398
 
 
   god @rhtyd 


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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: WIP - CLOUDSTACK-9114: Reduce VR 
downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-375660859
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd opened a new pull request #2508: CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508
 
 
   ## Description
   
   
   Note *WIP*, but working for both non-redundant and redundant network VRs :)
   
   Every time there is a major CloudStack version that requires a new 
systemvmtemplate, admins need to restart VRs which can take few (sometimes 
several) minutes. The aim of this project is three parts:
   - Reduce systemvmtemplate size, see #2506. Smaller the image size, faster it 
will be to copy template to primary storage to provision new VR.
   - Perform rolling reboot/deployment of VRs, by provisioning new VRs first 
and then killing old ones.
   - Make isolated VRs future proof (have keepalived+conntrackd preconfigured 
TBD)
   - Refactor systemvm python code to speed up VR programming or rule 
application
   - Speed up iptables and misc rules application from the VR's .json files
   
   Future:
   - Move away from iptables, move to nftables
   - Move away from Python2 codebase to Python3 or something else like Go? TBD
   
   Todos:
   [ ] Implement rolling reboot for VPC based on #2436 
   [ ] Speed up iptables and rules application based on #2083 
   
   
   
   
   ## Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   ## Screenshots (if appropriate):
   
   Screenshot shows ping drops from a guest VM, in a non-redundant isolated 
network: (2-5 ping drops observed)
   ![screenshot from 2018-03-23 
17-53-46](https://user-images.githubusercontent.com/95203/37830985-f4022b92-2ec9-11e8-94e4-9b972a592861.png)
   
   In case of rVRs, 0-1 ping drops are observed
   
   ## How Has This Been Tested?
   
   
   
   
   
   ## Checklist:
   
   
   - [ ] I have read the 
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
 document.
   - [ ] My code follows the code style of this project.
   - [ ] My change requires a change to the documentation.
   - [ ] I have updated the documentation accordingly.
   - [ ] I have added tests to cover my changes.
   - [ ] All new and existing tests passed.
   
   
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd closed pull request #2435: CLOUDSTACK-9114: restartnetwork with cleanup 
should restart the RVRs …
URL: https://github.com/apache/cloudstack/pull/2435
 
 
   

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/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 
b/engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
index cec2e5926c1..e324db7cf8c 100644
--- 
a/engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
+++ 
b/engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
@@ -38,6 +38,7 @@
 import javax.inject.Inject;
 import javax.naming.ConfigurationException;
 
+import com.cloud.network.VpcVirtualNetworkApplianceService;
 import org.apache.log4j.Logger;
 
 import org.apache.cloudstack.acl.ControlledEntity.ACLType;
@@ -45,7 +46,6 @@
 import org.apache.cloudstack.engine.cloud.entity.api.db.VMNetworkMapVO;
 import org.apache.cloudstack.engine.cloud.entity.api.db.dao.VMNetworkMapDao;
 import 
org.apache.cloudstack.engine.orchestration.service.NetworkOrchestrationService;
-import org.apache.cloudstack.framework.config.ConfigDepot;
 import org.apache.cloudstack.framework.config.ConfigKey;
 import org.apache.cloudstack.framework.config.ConfigKey.Scope;
 import org.apache.cloudstack.framework.config.Configurable;
@@ -53,7 +53,6 @@
 import org.apache.cloudstack.framework.messagebus.MessageBus;
 import org.apache.cloudstack.framework.messagebus.PublishScope;
 import org.apache.cloudstack.managed.context.ManagedContextRunnable;
-import org.apache.cloudstack.region.PortableIpDao;
 
 
 import com.cloud.agent.AgentManager;
@@ -86,7 +85,6 @@
 import com.cloud.deploy.DeployDestination;
 import com.cloud.deploy.DeploymentPlan;
 import com.cloud.domain.Domain;
-import com.cloud.event.dao.UsageEventDao;
 import com.cloud.exception.ConcurrentOperationException;
 import com.cloud.exception.ConnectionException;
 import com.cloud.exception.InsufficientAddressCapacityException;
@@ -127,7 +125,6 @@
 import com.cloud.network.dao.NetworkAccountDao;
 import com.cloud.network.dao.NetworkAccountVO;
 import com.cloud.network.dao.NetworkDao;
-import com.cloud.network.dao.NetworkDetailsDao;
 import com.cloud.network.dao.NetworkDomainDao;
 import com.cloud.network.dao.NetworkDomainVO;
 import com.cloud.network.dao.NetworkServiceMapDao;
@@ -140,7 +137,6 @@
 import com.cloud.network.dao.PhysicalNetworkVO;
 import com.cloud.network.dao.RemoteAccessVpnDao;
 import com.cloud.network.dao.RemoteAccessVpnVO;
-import com.cloud.network.dao.VpnUserDao;
 import com.cloud.network.element.AggregatedCommandExecutor;
 import com.cloud.network.element.DhcpServiceProvider;
 import com.cloud.network.element.DnsServiceProvider;
@@ -286,11 +282,11 @@
 @Inject
 VMNetworkMapDao _vmNetworkMapDao;
 @Inject
-DomainRouterDao _rotuerDao;
+DomainRouterDao _routerDao;
 @Inject
 RemoteAccessVpnDao _remoteAccessVpnDao;
 @Inject
-VpnUserDao _vpnUserDao;
+VpcVirtualNetworkApplianceService _routerService;
 
 List networkGurus;
 
@@ -368,17 +364,9 @@ public void setDhcpProviders(final 
List dhcpProviders) {
 @Inject
 NetworkACLManager _networkACLMgr;
 @Inject
-UsageEventDao _usageEventDao;
-@Inject
 NetworkModel _networkModel;
 @Inject
 NicSecondaryIpDao _nicSecondaryIpDao;
-@Inject
-PortableIpDao _portableIpDao;
-@Inject
-ConfigDepot _configDepot;
-@Inject
-NetworkDetailsDao _networkDetailsDao;
 
 protected StateMachine2 
_stateMachine;
 ScheduledExecutorService _executor;
@@ -1145,30 +1133,8 @@ public void implementNetworkElementsAndResources(final 
DeployDestination dest, f
 }
 }
 // get providers to implement
-final List providersToImplement = 
getNetworkProviders(network.getId());
-for (final NetworkElement element : networkElements) {
-if (providersToImplement.contains(element.getProvider())) {
-if 
(!_networkModel.isProviderEnabledInPhysicalNetwork(_networkModel.getPhysicalNetworkId(network),
 element.getProvider().getName())) {
-// The physicalNetworkId will not get translated into a 
uuid by the reponse serializer,
-// because the serializer would look up the NetworkVO 
class's table and retrieve the
-// network id instead of the physical network 

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd commented on issue #2435: CLOUDSTACK-9114: restartnetwork with cleanup 
should restart the RVRs …
URL: https://github.com/apache/cloudstack/pull/2435#issuecomment-375658012
 
 
   I'll re-submit a PR that will reduce VR downtime during upgrade, will close 
this one, have stolen the commit from this PR originally by Wei ;)


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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375623934
 
 
   Packaging result: ✖centos6 ✖centos7 ✖debian. JID-1821


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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

resmo commented on a change in pull request #2468: CLOUDSTACK-10341 VR: minor 
fixes
URL: https://github.com/apache/cloudstack/pull/2468#discussion_r176698787
 
 

 ##
 File path: systemvm/debian/etc/systemd/system/cloud-postinit.service
 ##
 @@ -1,7 +1,7 @@
 [Unit]
 Description=CloudStack post-patching init script
 After=cloud-early-config.service network.target local-fs.target
-Before=ssh.service
+Before=ssh.service apache2.service
 
 Review comment:
   I meant the dependency caused in the scripts not systemd.
   
   However, I am ok to revert this if it causes serious issues.


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

rhtyd commented on issue #2506: CLOUDSTACK-10341: Reduce systemvmtemplate size, 
install nftables
URL: https://github.com/apache/cloudstack/pull/2506#issuecomment-375620822
 
 
   Thanks @resmo, we indeed install packages with the --no-install-recommends 
flag 
https://github.com/apache/cloudstack/blob/master/tools/appliance/systemvmtemplate/scripts/install_systemvm_packages.sh#L46


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

rhtyd commented on a change in pull request #2468: CLOUDSTACK-10341 VR: minor 
fixes
URL: https://github.com/apache/cloudstack/pull/2468#discussion_r176697597
 
 

 ##
 File path: systemvm/debian/etc/systemd/system/cloud-postinit.service
 ##
 @@ -1,7 +1,7 @@
 [Unit]
 Description=CloudStack post-patching init script
 After=cloud-early-config.service network.target local-fs.target
-Before=ssh.service
+Before=ssh.service apache2.service
 
 Review comment:
   You can see the dependency graph for systemd, via systemd-analyze (plot it 
or analyze the critical-chain etc, refer docs for more info). Apache2 is 
disabled by default, so during first boot no errors should be seen. Can you 
share when you saw those errors, did that cause any service related failure for 
you, also where you saw these errors (in console or logs?). The cloud-postinst 
script will handle any failure and start apache2 is required, any initial 
error/warning may be ignored.
   
   The issue now I'm seeing repeatedly is that, cloud-postinst service is stuck 
at 'systemctl restart apache2' due to interdependencies between cloud-postinst 
and apache2 services. To break this, apache2 needs to be removed from the 
change above ^^


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

rhtyd commented on a change in pull request #2468: CLOUDSTACK-10341 VR: minor 
fixes
URL: https://github.com/apache/cloudstack/pull/2468#discussion_r176697597
 
 

 ##
 File path: systemvm/debian/etc/systemd/system/cloud-postinit.service
 ##
 @@ -1,7 +1,7 @@
 [Unit]
 Description=CloudStack post-patching init script
 After=cloud-early-config.service network.target local-fs.target
-Before=ssh.service
+Before=ssh.service apache2.service
 
 Review comment:
   You can see the dependency graph for systemd, via systemd-analyze (plot it 
or analyze the critical-chain etc, refer docs for more info). Apache2 is 
disabled by default, so during first boot no errors should be seen. Can you 
share when you saw those errors, did that cause any service related failure for 
you, also where you saw these errors (in console or logs?). The cloud-postinst 
script will handle any failure and start apache2 is required, any initial 
error/warning may be ignored.


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375619006
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

rhtyd commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for 
KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375618792
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

rhtyd commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for 
KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375608035
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

blueorangutan commented on issue #2507: CLOUDSTACK-10319: Allow TLSv1, v1.1 for 
XenServer, Vmware
URL: https://github.com/apache/cloudstack/pull/2507#issuecomment-375618571
 
 
   @rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) 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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375618627
 
 
   Packaging result: ✖centos6 ✖centos7 ✖debian. JID-1820


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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375608088
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375618627
 
 
   Packaging result: ✖centos6 ✖centos7 ✖debian. JID-1820


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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

rhtyd commented on issue #2507: CLOUDSTACK-10319: Allow TLSv1, v1.1 for 
XenServer, Vmware
URL: https://github.com/apache/cloudstack/pull/2507#issuecomment-375618329
 
 
   @blueorangutan test centos7 vmware-55u3


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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM 
Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375608088
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10333:
-

rhtyd commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for 
KVM
URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375608035
 
 
   @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


> Secure VM Live migration for KVM
> 
>
> Key: CLOUDSTACK-10333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> With use of CA framework to secure hosts, the current mechanisms don't secure 
> libvirtd to use those certificates (used by agent to connect to mgmt server). 
> This causes insecure vm migration over tcp instead of tls. The aim is to use 
> the same framework and certificates to secure live VM migration. This could 
> be coupled with securing of a host and renewal/provisioning of certificates 
> to host.
>  
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

resmo commented on issue #2506: CLOUDSTACK-10341: Reduce systemvmtemplate size, 
install nftables
URL: https://github.com/apache/cloudstack/pull/2506#issuecomment-375606039
 
 
   while improving, I wonder do we already have `--no-recommends`? This would 
also skip installing docs and optimize disk space usage. I would even suggest 
to add it to apt.conf
   
   ~~~
   cat > /etc/apt/apt.conf.d/01norecommend << EOF
   APT::Install-Recommends "0";
   APT::Install-Suggests "0";
   EOF
   ~~~
   
   Any thoughts?


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

resmo commented on issue #2506: CLOUDSTACK-10341: Reduce systemvmtemplate size, 
install nftables
URL: https://github.com/apache/cloudstack/pull/2506#issuecomment-375606039
 
 
   while improving, I wonder do we already have --no-recommends? This would 
also skip installing docs and optimize disk space usage. I would even suggest 
to add it to apt.conf
   
   ~~~
   cat > /etc/apt/apt.conf.d/01norecommend << EOF
   APT::Install-Recommends "0";
   APT::Install-Suggests "0";
   EOF
   ~~~
   
   Any thoughts?


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10332:
-

rafaelweingartner commented on issue #2496: [CLOUDSTACK-10332] Users are not 
able to change/edit the protocol of an ACL rule 
URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375603221
 
 
   Now the errors changed. Are they intermittent ones?


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


> Users are not able to change/edit the protocol of an ACL rule 
> --
>
> Key: CLOUDSTACK-10332
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>
> Users should be able to edit an ACL rule completely. Therefore, they must be 
> able to change the protocol type and others configs of an ACL rules.
> Right now users are not able to execute the following. 
> * Create an ACL for ICMP
> * Click on edit and change the protocol to TCP
> * An error will happen when saving the rule.
> Users should be able to execute the protocol changes without problem.
> In addition, it is not just the protocol that users are not able to change. 
> For instance, after defining ports, or reason/description for the rule, users 
> are not able to set those values back to null. The same happens for ICMP code 
> and type.
> We will introduce a new parameter called "partialUpdate", which will have its 
> default value as true to maintain backward compatibility. When this parameter 
> is set to false, we will consider only the parameters sent, and not the 
> parameters we already have in the database to change and validate the ACL 
> rule data. This allows us to update parameters already set back to null, and 
> to completely change an ACL rule.



--
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.

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

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-375602995
 
 
   Now the errors changed, it increased the number of them. However, the new 
test case that was added keeps failing.


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-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

blueorangutan commented on issue #2507: CLOUDSTACK-10319: Allow TLSv1, v1.1 for 
XenServer, Vmware
URL: https://github.com/apache/cloudstack/pull/2507#issuecomment-375597210
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1819


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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

resmo commented on a change in pull request #2468: CLOUDSTACK-10341 VR: minor 
fixes
URL: https://github.com/apache/cloudstack/pull/2468#discussion_r176677207
 
 

 ##
 File path: systemvm/debian/etc/systemd/system/cloud-postinit.service
 ##
 @@ -1,7 +1,7 @@
 [Unit]
 Description=CloudStack post-patching init script
 After=cloud-early-config.service network.target local-fs.target
-Before=ssh.service
+Before=ssh.service apache2.service
 
 Review comment:
   We see systemd errors unable to start apache on the first boot, It seemed to 
be related to missing network setup but after postinit script ran, apache were 
"restarted" and apache was accessible again.
   
   It is really hard to predict the dependency tree in this scripting 
construct...


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

blueorangutan commented on issue #2507: CLOUDSTACK-10319: Allow TLSv1, v1.1 for 
XenServer, Vmware
URL: https://github.com/apache/cloudstack/pull/2507#issuecomment-375589643
 
 
   @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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

rhtyd opened a new pull request #2507: CLOUDSTACK-10319: Allow TLSv1, v1.1 for 
XenServer, Vmware
URL: https://github.com/apache/cloudstack/pull/2507
 
 
   ## Description
   
   This reverts changes from #2480, instead moves TLS settings to
   java ciphers settings config file. It should be sufficient to enforce
   TLS v1.2 on public facing CloudStack services:
   - CloudStack webserver (Jetty based)
   - Apache2 for secondary storage VM
   - CPVM HTTPs server
   
   
   
   
   ## Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   ## Checklist:
   
   
   - [ ] I have read the 
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
 document.
   - [ ] My code follows the code style of this project.
   - [ ] All new and existing tests passed.
   
   
   @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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10319:
-

rhtyd commented on issue #2480: CLOUDSTACK-10319: Prefer TLSv1.2, deprecate 
TLSv1.0,1.1
URL: https://github.com/apache/cloudstack/pull/2480#issuecomment-375585194
 
 
   @rafaelweingartner @PaulAngus and others this seems to break older 
xenservers and vmware 5.x vcenters which expects to connect via TLS 1.0. I 
think instead to do this system-wide we may only fix it for public facing 
services such as - (a) apache2 in systemvms, (b) console proxy server, (c) 
management server. I'll partially revert this.


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


> Prefer TLSv1.2 and deprecate TLS 1.0/1.1
> 
>
> Key: CLOUDSTACK-10319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make 
> cloudstack prefer tls 1.2.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

rhtyd commented on a change in pull request #2468: CLOUDSTACK-10341 VR: minor 
fixes
URL: https://github.com/apache/cloudstack/pull/2468#discussion_r176670427
 
 

 ##
 File path: systemvm/debian/etc/systemd/system/cloud-postinit.service
 ##
 @@ -1,7 +1,7 @@
 [Unit]
 Description=CloudStack post-patching init script
 After=cloud-early-config.service network.target local-fs.target
-Before=ssh.service
+Before=ssh.service apache2.service
 
 Review comment:
   @resmo post-merging this PR I found that sometimes isolated network VRs get 
stuck when starting due to unable to restart apache2 via postinit script. Can 
you advise why apache2 need to be started after postinit script runs?


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



--
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.

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

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-375567577
 
 
   Trillian test result (tid-2403)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 42229 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2403-kvm-centos7.zip
   Intermitten failure detected: 
/marvin/tests/smoke/test_affinity_groups_projects.py
   Intermitten failure detected: /marvin/tests/smoke/test_affinity_groups.py
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 61 look OK, 6 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_DeployVmAntiAffinityGroup_in_project | `Error` | 58.44 | 
test_affinity_groups_projects.py
   test_DeployVmAntiAffinityGroup | `Error` | 63.06 | test_affinity_groups.py
   test_04_rvpc_privategw_static_routes | `Failure` | 370.47 | 
test_privategw_acl.py
   test_11_migrate_volume_and_change_offering | `Error` | 130.68 | 
test_volumes.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 540.19 | 
test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.44 | 
test_hostha_kvm.py
   test_hostha_kvm_host_fencing | `Failure` | 675.83 | test_hostha_kvm.py
   test_hostha_kvm_host_recovering | `Failure` | 623.78 | 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


> 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 

[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10327:
-

blueorangutan commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the 
session when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375567486
 
 
   Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1818


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


> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore 
> with CloudStack 4.11, since commit 
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to 
> a network CIDR), but also a regression due to a refactoring: every API 
> request that is not "validated" generates the same error (401 - Unauthorized) 
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to 
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
>  an API command reserved for root admins. When the user is not a root admin, 
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
>  user is not allowed to request the API command or the API command does not 
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the 
> session is invalidated. Then the next API calls lead to an error "Session 
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
>  to verify user credentials and/or request signature"}}
> {noformat}



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10340:
-

blueorangutan commented on issue #2504: CLOUDSTACK-10340: Add setter to 
hypervisorType in VMInstanceVO
URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375566583
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1816


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


> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10327:
-

blueorangutan commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the 
session when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375559143
 
 
   @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


> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore 
> with CloudStack 4.11, since commit 
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to 
> a network CIDR), but also a regression due to a refactoring: every API 
> request that is not "validated" generates the same error (401 - Unauthorized) 
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to 
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
>  an API command reserved for root admins. When the user is not a root admin, 
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
>  user is not allowed to request the API command or the API command does not 
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the 
> session is invalidated. Then the next API calls lead to an error "Session 
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
>  to verify user credentials and/or request signature"}}
> {noformat}



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


[jira] [Updated] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread Rohit Yadav (JIRA)

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

Rohit Yadav updated CLOUDSTACK-10341:
-
Status: Reviewable  (was: In Progress)

> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10327:
-

rhtyd commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the session 
when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375559096
 
 
   @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


> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore 
> with CloudStack 4.11, since commit 
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to 
> a network CIDR), but also a regression due to a refactoring: every API 
> request that is not "validated" generates the same error (401 - Unauthorized) 
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to 
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
>  an API command reserved for root admins. When the user is not a root admin, 
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
>  user is not allowed to request the API command or the API command does not 
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the 
> session is invalidated. Then the next API calls lead to an error "Session 
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
>  to verify user credentials and/or request signature"}}
> {noformat}



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


[jira] [Commented] (CLOUDSTACK-10271) detect vulnerabilities in depndencies

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10271:
-

rhtyd commented on issue #2446: CLOUDSTACK-10271 maven plugin for owasp 
dependency check added
URL: https://github.com/apache/cloudstack/pull/2446#issuecomment-375558901
 
 
   @DaanHoogland can you check and fix Travis failures? 


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


> detect vulnerabilities in depndencies
> -
>
> Key: CLOUDSTACK-10271
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10271
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Major
>
> As a developer I want to know whether and what dependencies I am using that 
> might harm my users. For this we need to add the owasp dependency checker to 
> the maven build. It will require more then just this but it is a good first 
> step.



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


[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9781:


rhtyd commented on issue #1940: CLOUDSTACK-9781:ACS records ID in events tables 
instead of UUID.
URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-375558690
 
 
   Ping @syed, let's re-discuss this?


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


> ACS records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>Priority: Major
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504)

This adds a missing setter to set hypervisorType in VMInstanceVO.

Signed-off-by: Rohit Yadav 

> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

Commit 9753cc3681b4dd31a9e409897f89228fb3fbd562 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9753cc3 ]

Merge branch '4.11'

CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468)
CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504)

Signed-off-by: Rohit Yadav 


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468)

- Fixes rsyslog: fix config error in rsylslog.conf

Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: action '*' treated as 
':omusrmsg:*' - please use ':omusrmsg:*' syntax instead, '*' will not be 
supported in the future [v8.24.0 try http://www.rsyslog.com/e/2184 ]
Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: error during parsing file 
/etc/rsyslog.conf, on or before line 95: warnings occured in file 
'/etc/rsyslog.conf' around line 95 [v8.24.0 try http://www.rsyslog.com/e/2207 ]

- Run apache2 only after cloud-postinit

- Increase /run size for VR with 256M RAM

root@r-395-VM:~# systemctl daemon-reload
Failed to reload daemon: Refusing to reload, not enough space available on 
/run/systemd. Currently, 15.8M are free, but a safety buffer of 16.0M is 
enforced.

tmpfs23M  6.5M   16M  29% /run


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

Commit 9753cc3681b4dd31a9e409897f89228fb3fbd562 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9753cc3 ]

Merge branch '4.11'

CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468)
CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504)

Signed-off-by: Rohit Yadav 


> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10341:
-

rhtyd opened a new pull request #2506: CLOUDSTACK-10341: Reduce template size, 
install nft
URL: https://github.com/apache/cloudstack/pull/2506
 
 
   ## Description
   
   This reduces systemvmtemplate size by 600MB and installs nftables,
   updates iptables.
   
   
   
   
   ## Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   ## Screenshots (if appropriate):
   
   ## How Has This Been Tested?
   
   Manually built using packer and tested locally by running smoketests.
   
   
   
   
   
   ## Checklist:
   
   
   - [ ] I have read the 
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
 document.
   - [ ] My code follows the code style of this project.
   - [ ] All new and existing tests passed.
   


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


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468)

- Fixes rsyslog: fix config error in rsylslog.conf

Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: action '*' treated as 
':omusrmsg:*' - please use ':omusrmsg:*' syntax instead, '*' will not be 
supported in the future [v8.24.0 try http://www.rsyslog.com/e/2184 ]
Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: error during parsing file 
/etc/rsyslog.conf, on or before line 95: warnings occured in file 
'/etc/rsyslog.conf' around line 95 [v8.24.0 try http://www.rsyslog.com/e/2207 ]

- Run apache2 only after cloud-postinit

- Increase /run size for VR with 256M RAM

root@r-395-VM:~# systemctl daemon-reload
Failed to reload daemon: Refusing to reload, not enough space available on 
/run/systemd. Currently, 15.8M are free, but a safety buffer of 16.0M is 
enforced.

tmpfs23M  6.5M   16M  29% /run


> Systemvmtemplate 4.11 changes
> -
>
> Key: CLOUDSTACK-10341
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Systemvmtemplate and fail due to low /run memory allocation, the template is 
> slow to copy the size may be further reduced.



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


[jira] [Created] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes

2018-03-23 Thread Rohit Yadav (JIRA)
Rohit Yadav created CLOUDSTACK-10341:


 Summary: Systemvmtemplate 4.11 changes
 Key: CLOUDSTACK-10341
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341
 Project: CloudStack
  Issue Type: Task
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.12.0.0, 4.11.1.0


Systemvmtemplate and fail due to low /run memory allocation, the template is 
slow to copy the size may be further reduced.



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10340:
-

blueorangutan commented on issue #2504: CLOUDSTACK-10340: Add setter to 
hypervisorType in VMInstanceVO
URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375556408
 
 
   @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


> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504)

This adds a missing setter to set hypervisorType in VMInstanceVO.

Signed-off-by: Rohit Yadav 

> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10340:
-

rhtyd commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType 
in VMInstanceVO
URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375556274
 
 
   Thanks all, merging this based on code reviews and test results (the 
failures were not caused by this PR, but were intermitted/env caused).


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


> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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


[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10340:
-

rhtyd closed pull request #2504: CLOUDSTACK-10340: Add setter to hypervisorType 
in VMInstanceVO
URL: https://github.com/apache/cloudstack/pull/2504
 
 
   

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/com/cloud/vm/VMInstanceVO.java 
b/engine/schema/src/com/cloud/vm/VMInstanceVO.java
index b55e030620b..b0ebf2406f5 100644
--- a/engine/schema/src/com/cloud/vm/VMInstanceVO.java
+++ b/engine/schema/src/com/cloud/vm/VMInstanceVO.java
@@ -267,6 +267,10 @@ public HypervisorType getHypervisorType() {
 return hypervisorType;
 }
 
+public void setHypervisorType(HypervisorType hypervisorType) {
+this.hypervisorType = hypervisorType;
+}
+
 @Override
 public Date getCreated() {
 return created;


 


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


> Add setter in vminstancevo 
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
>  _VMInstanceVO needs setHypervisorType()_



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