[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419724#comment-16419724 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377364863 I closed the revert PR because after re-reading this one I got confused. Did you have an upgrade problem between 4.10 and 4.11, and that is why this PR was 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 > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419726#comment-16419726 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377364863 I closed the revert PR because after re-reading this one I got confused. Did we have an upgrade problem between 4.10 and 4.11, and that is why this PR was 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 > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419720#comment-16419720 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner closed pull request #2516: Revert "CLOUDSTACK-10278 idempotent column addition" URL: https://github.com/apache/cloudstack/pull/2516 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419719#comment-16419719 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2516: Revert "CLOUDSTACK-10278 idempotent column addition" URL: https://github.com/apache/cloudstack/pull/2516#issuecomment-377364524 Ok, I am definitely confused now. I will wait for others feedback regarding #2449. I read the history of the PR, but I am still not sure where those SQLs should go into. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419714#comment-16419714 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner opened a new pull request #2516: Revert "CLOUDSTACK-10278 idempotent column addition" URL: https://github.com/apache/cloudstack/pull/2516 Reverts apache/cloudstack#2449 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419712#comment-16419712 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377363253 Folks, I was going to merge this forward. However, there is something wrong here. this was merged after 4.11 was closed, but the script used to add changes is `schema-41000to41100.sql`; it should have been schema-41100to41110.sql. Moreover, the upgrade path from 4.11.0.0 to 4.11.1.0 should have been created. I will revert this PR, so I can proceed with other merge forwards that were not executed yet. We can evaluate and re-introduce this PR later. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10241. - Resolution: Fixed Fix Version/s: 4.12 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419576#comment-16419576 ] ASF subversion and git services commented on CLOUDSTACK-10241: -- Commit 060715e9f5f929804b7f515cfba0b4b130581876 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=060715e ] [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools (#2414) * [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools Due to a race condition between multiple management servers, in some rare cases, CloudStack is creating multiple file SRs to the same secondary folder. This causes a problem when introducing the SR to the XenServer pools, as “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they are seen in different SRs, and therefore cause an error. The solution to avoid race conditions between management servers is to use a deterministic srUuid for the file SR to be created (we are leaving XenServer with the burden of managing race conditions). The UUID is based on the SR file path and is generated using UUID#nameUUIDFromBytes. Therefore, if there is an SR with the generated UUID, this means that some other management server has just created it. An exception will occur and it will contain a message saying 'Db_exn.Uniqueness_constraint_violation'. In these unlikely events, we catch the exception and use the method retrieveAlreadyConfiguredSrWithoutException to get the SR that has already been created for the given mount point. > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419574#comment-16419574
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
rafaelweingartner closed pull request #2414: [CLOUDSTACK-10241] Duplicated file
SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414
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/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
index ee146a1f88c..2cecbea162c 100644
---
a/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
+++
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
@@ -198,7 +198,7 @@ public String toString() {
private final static int BASE_TO_CONVERT_BYTES_INTO_KILOBYTES = 1024;
-protected static final XenServerConnectionPool ConnPool =
XenServerConnectionPool.getInstance();
+private static final XenServerConnectionPool ConnPool =
XenServerConnectionPool.getInstance();
// static min values for guests on xenserver
private static final long mem_128m = 134217728L;
@@ -243,7 +243,7 @@ private static boolean isAlienVm(final VM vm, final
Connection conn) throws XenA
protected String _guestNetworkName;
protected int _heartbeatInterval = 60;
protected int _heartbeatTimeout = 120;
-protected final XsHost _host = new XsHost();
+protected XsHost _host = new XsHost();
protected String _instance; // instance name (default is usually "VM")
protected boolean _isOvs = false;
protected String _linkLocalPrivateNetworkName;
diff --git
a/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
index dea1752abd7..d809560ac22 100644
---
a/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
+++
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
@@ -18,6 +18,27 @@
*/
package com.cloud.hypervisor.xenserver.resource;
+import java.io.File;
+import java.net.URI;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.UUID;
+
+import org.apache.cloudstack.storage.command.CopyCmdAnswer;
+import org.apache.cloudstack.storage.command.CopyCommand;
+import org.apache.cloudstack.storage.to.PrimaryDataStoreTO;
+import org.apache.cloudstack.storage.to.SnapshotObjectTO;
+import org.apache.cloudstack.storage.to.TemplateObjectTO;
+import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.commons.collections.CollectionUtils;
+import org.apache.commons.collections.MapUtils;
+import org.apache.commons.lang.StringUtils;
+import org.apache.log4j.Logger;
+import org.apache.xmlrpc.XmlRpcException;
+
import com.cloud.agent.api.Answer;
import com.cloud.agent.api.to.DataObjectType;
import com.cloud.agent.api.to.DataStoreTO;
@@ -37,26 +58,9 @@
import com.xensource.xenapi.Task;
import com.xensource.xenapi.Types;
import com.xensource.xenapi.Types.BadServerResponse;
+import com.xensource.xenapi.Types.StorageOperations;
import com.xensource.xenapi.Types.XenAPIException;
import com.xensource.xenapi.VDI;
-import org.apache.cloudstack.storage.command.CopyCmdAnswer;
-import org.apache.cloudstack.storage.command.CopyCommand;
-import org.apache.cloudstack.storage.to.PrimaryDataStoreTO;
-import org.apache.cloudstack.storage.to.SnapshotObjectTO;
-import org.apache.cloudstack.storage.to.TemplateObjectTO;
-import org.apache.cloudstack.storage.to.VolumeObjectTO;
-import org.apache.commons.lang.StringUtils;
-import org.apache.log4j.Logger;
-import org.apache.xmlrpc.XmlRpcException;
-
-import java.io.File;
-import java.net.URI;
-import java.util.ArrayList;
-import java.util.HashMap;
-import java.util.List;
-import java.util.Map;
-import java.util.Set;
-import java.util.UUID;
public class Xenserver625StorageProcessor extends XenServerStorageProcessor {
private static final Logger s_logger =
Logger.getLogger(XenServerStorageProcessor.class);
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419575#comment-16419575 ] ASF subversion and git services commented on CLOUDSTACK-10241: -- Commit 060715e9f5f929804b7f515cfba0b4b130581876 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=060715e ] [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools (#2414) * [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools Due to a race condition between multiple management servers, in some rare cases, CloudStack is creating multiple file SRs to the same secondary folder. This causes a problem when introducing the SR to the XenServer pools, as “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they are seen in different SRs, and therefore cause an error. The solution to avoid race conditions between management servers is to use a deterministic srUuid for the file SR to be created (we are leaving XenServer with the burden of managing race conditions). The UUID is based on the SR file path and is generated using UUID#nameUUIDFromBytes. Therefore, if there is an SR with the generated UUID, this means that some other management server has just created it. An exception will occur and it will contain a message saying 'Db_exn.Uniqueness_constraint_violation'. In these unlikely events, we catch the exception and use the method retrieveAlreadyConfiguredSrWithoutException to get the SR that has already been created for the given mount point. > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10345) StorageSystemSnapshotStrategy and StorageSystemDataMotionStrategy: Only use a host whose Resource State is Enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10345. - Resolution: Fixed Fix Version/s: 4.11.1.0 > StorageSystemSnapshotStrategy and StorageSystemDataMotionStrategy: Only use a > host whose Resource State is Enabled > -- > > Key: CLOUDSTACK-10345 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10345 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Update the StorageSystemSnapshotStrategy and StorageSystemDataMotionStrategy > classes to only leverage a host when its Resource State is Enabled. -- 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419446#comment-16419446 ] ASF GitHub Bot commented on CLOUDSTACK-9114: blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during network restart URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-377311160 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1853 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419415#comment-16419415 ] ASF GitHub Bot commented on CLOUDSTACK-9114: rhtyd commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during network restart URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-377306931 Thanks @rafaelweingartner for the review, I'll get back to them after holidays. 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419389#comment-16419389 ] ASF GitHub Bot commented on CLOUDSTACK-9114: blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during network restart URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-377302618 @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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419388#comment-16419388 ] ASF GitHub Bot commented on CLOUDSTACK-9114: rhtyd commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during network restart URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-377302363 @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-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419080#comment-16419080 ] 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-377251692 Packaging result: ✖centos6 ✖centos7 ✖debian. JID-1851 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419052#comment-16419052 ] 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-377246348 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419049#comment-16419049 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - borisstoyanov commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-377246041 @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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419031#comment-16419031 ] 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-377243724 Packaging result: ✖centos6 ✖centos7 ✖debian. JID-1850 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-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419022#comment-16419022 ] ASF GitHub Bot commented on CLOUDSTACK-7982: wido commented on issue #1709: CLOUDSTACK-7982: KVM live migration with local storage URL: https://github.com/apache/cloudstack/pull/1709#issuecomment-377242576 @marcaurele Have you been able to do the rebase yet? 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 > Storage live migration support for KVM > -- > > Key: CLOUDSTACK-7982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Marc-Aurèle Brothier >Priority: Major > Fix For: Future > > > Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. > We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419008#comment-16419008 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - borisstoyanov commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-377240132 I'll kick new tests with the latest commit once the build comes out 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419002#comment-16419002 ] 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-377238976 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419001#comment-16419001 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - borisstoyanov commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-377238735 @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-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418962#comment-16418962
]
ASF GitHub Bot commented on CLOUDSTACK-10326:
-
rafaelweingartner commented on a change in pull request #2493:
CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running
VMs on it
URL: https://github.com/apache/cloudstack/pull/2493#discussion_r178048428
##
File path: server/src/com/cloud/resource/ResourceManagerImpl.java
##
@@ -1296,10 +1296,17 @@ public boolean checkAndMaintain(final long hostId) {
if (host.getType() != Host.Type.Storage) {
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
+final List failedMigratedVms =
_vmDao.listNonMigratingVmsByHostEqualsLastHost(hostId);
if (vos.isEmpty() && vosMigrating.isEmpty()) {
-resourceStateTransitTo(host,
ResourceState.Event.InternalEnterMaintenance, _nodeId);
-hostInMaintenance = true;
-
ActionEventUtils.onCompletedActionEvent(CallContext.current().getCallingUserId(),
CallContext.current().getCallingAccountId(), EventVO.LEVEL_INFO,
EventTypes.EVENT_MAINTENANCE_PREPARE, "completed maintenance for host " +
hostId, 0);
+if (!failedMigratedVms.isEmpty()) {
Review comment:
What about extracting the body of this IF to a method?
This allows documentation and unit tests to be easily written.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Prevent hosts fall into Maintenance when there are running VMs on it
>
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png,
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png,
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into
> 'PrepareForMaintenance' and running VMs are migrated into another host. After
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
> * List VMs with host_id = HOST_ID
> * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then
> migration fails, host_id = last_host_id = ORIGIN_HOST
> h2. Issue
> This sequence:
> * Enable maintenance mode on ORIGIN_HOST
> * VMs start being migrated to a host, say DEST_HOST
> * checkAndMaintain() starts:
> ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are
> being migrated)
> ** Before the second check, one or more migrations fail
> ** Second check passes, however there are VMs running on the host as
> migrations have failed.
> * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418870#comment-16418870
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rafaelweingartner commented on a change in pull request #2505:
CLOUDSTACK-10333: Secure Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178034861
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -140,9 +143,11 @@ public int value() {
long _startupWait = _startupWaitDefault;
boolean _reconnectAllowed = true;
//For time sentitive task, e.g. PingTask
-private final ThreadPoolExecutor _ugentTaskPool;
+ThreadPoolExecutor _ugentTaskPool;
ExecutorService _executor;
+Thread _shutdownThread = new ShutdownThread(this);
Review comment:
Awesome! Thanks!
This is a cosmetic thing, but if we do not get ride of them, newcomers might
think that we enforce them. I am trying to do the same in other PRs.
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418867#comment-16418867
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rafaelweingartner commented on a change in pull request #2505:
CLOUDSTACK-10333: Secure Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178034614
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -274,6 +279,19 @@ public void start() {
}
}
_shell.updateConnectedHost();
+
+// In case of software based restart, GC to remove old instances
+_executor.submit(new Runnable() {
Review comment:
Got it. There is only one thing. We never now for sure that the GC has been
executed. `System.gc` only suggests for the JVM that the GC can be executed,
but there is no guarantees. Anyways, as long as the old objects are not used
anymore we are safe to go.
Would you mind extracting this block of code to a method and document it
with this explanation?
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-9114) restartnetwork with cleanup should not update/restart both routers at once
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418862#comment-16418862
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178031283
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2838,8 +2828,27 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
s_logger.debug("Restarting network " + networkId + "...");
final ReservationContext context = new ReservationContextImpl(null,
null, callerUser, callerAccount);
+final NetworkOffering offering =
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
if (cleanup) {
+// Destroy non-running VRs
+for (final DomainRouterVO router :
_routerDao.findByNetwork(network.getId())) {
+if (router.getState() != VirtualMachine.State.Running) {
+s_logger.debug("Destroying " + router + " as it is not in
Running state");
+_routerService.destroyRouter(router.getId(),
context.getAccount(), context.getCaller().getId());
+}
+}
+// Perform rolling restart for Virtual Routers
+final List routers =
_routerDao.findByNetwork(network.getId());
+if (routers != null && !routers.isEmpty()) {
Review comment:
You can use `CollectionUtils.isNotEmpty` here
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418860#comment-16418860
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178032230
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2868,6 +2876,82 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
}
}
+@Override
+public VirtualRouter findExpendableRouterForRollingRestart(final List routers) {
+VirtualRouter expendableRouter = null;
+if (routers != null && routers.size() > 1) {
+for (final VirtualRouter router : routers) {
+if (router.getRedundantState() !=
VirtualRouter.RedundantState.MASTER) {
+expendableRouter = router;
+}
+}
+if (expendableRouter == null) {
+expendableRouter = routers.get(routers.size() - 1);
+}
+}
+return expendableRouter;
+}
+
+private boolean rollingRestartRouters(final NetworkVO network, final
NetworkOffering offering, final List oldRouters, final
ReservationContext context) throws ResourceUnavailableException,
ConcurrentOperationException, InsufficientCapacityException {
+final Account callerAccount =
CallContext.current().getCallingAccount();
Review comment:
Can you break this method into smaller ones? It is quite big already.
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418855#comment-16418855
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178032100
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2868,6 +2876,82 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
}
}
+@Override
+public VirtualRouter findExpendableRouterForRollingRestart(final List routers) {
+VirtualRouter expendableRouter = null;
+if (routers != null && routers.size() > 1) {
+for (final VirtualRouter router : routers) {
+if (router.getRedundantState() !=
VirtualRouter.RedundantState.MASTER) {
+expendableRouter = router;
+}
+}
+if (expendableRouter == null) {
+expendableRouter = routers.get(routers.size() - 1);
+}
+}
+return expendableRouter;
+}
+
+private boolean rollingRestartRouters(final NetworkVO network, final
NetworkOffering offering, final List oldRouters, final
ReservationContext context) throws ResourceUnavailableException,
ConcurrentOperationException, InsufficientCapacityException {
+final Account callerAccount =
CallContext.current().getCallingAccount();
+final long callerUserId = CallContext.current().getCallingUserId();
+final DeployDestination dest = new
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+final List providersToImplement =
getNetworkProviders(network.getId());
+
+// Find and destroy any expendable router
+final VirtualRouter expendableRouter =
findExpendableRouterForRollingRestart(oldRouters);
+if (expendableRouter != null) {
+_routerService.destroyRouter(expendableRouter.getId(),
callerAccount, callerUserId);
+}
+final List remainingOldRouters =
_routerDao.findByNetwork(network.getId());
+
+// Create a new router
+network.setRollingRestart(true);
+implementNetworkElements(dest, context, network, offering,
providersToImplement);
+network.setRollingRestart(false);
+
+if (network.isRedundant()) {
+try {
+// For redundant network wait for 3*(1+skew_seconds) for VRRP
to kick in
+Thread.sleep(1L);
+} catch (final InterruptedException ignored) {
Review comment:
Please, do not hide exceptions.
You should at least log them.
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418854#comment-16418854
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178031428
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2838,8 +2828,27 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
s_logger.debug("Restarting network " + networkId + "...");
final ReservationContext context = new ReservationContextImpl(null,
null, callerUser, callerAccount);
+final NetworkOffering offering =
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
if (cleanup) {
Review comment:
What about extracting this IF body to a method? This allows proper
documentation (instead of code comments), and unit 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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418858#comment-16418858
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178033706
##
File path: server/src/com/cloud/network/vpc/VpcManagerImpl.java
##
@@ -2435,4 +2460,66 @@ public boolean isSrcNatIpRequired(long vpcOfferingId) {
final Map
vpcOffSvcProvidersMap = getVpcOffSvcProvidersMap(vpcOfferingId);
return
vpcOffSvcProvidersMap.get(Network.Service.SourceNat).contains(Network.Provider.VPCVirtualRouter);
}
+
+private boolean rollingRestartVpc(final Vpc vpc, final
List oldRouters, final ReservationContext context) throws
ResourceUnavailableException, ConcurrentOperationException,
InsufficientCapacityException {
Review comment:
This method has a good chunk of code duplicated with
`rollingRestartRouters`. Would mind extracting the code common code to methods
and then reuse them?
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418861#comment-16418861
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178031820
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2868,6 +2876,82 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
}
}
+@Override
+public VirtualRouter findExpendableRouterForRollingRestart(final List routers) {
+VirtualRouter expendableRouter = null;
+if (routers != null && routers.size() > 1) {
Review comment:
You invert the logic here. `if (router == null || router.size <=1)`, then
return null;
This would allow you to remove one nesting level.
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418857#comment-16418857
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178031163
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2838,8 +2828,27 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
s_logger.debug("Restarting network " + networkId + "...");
final ReservationContext context = new ReservationContextImpl(null,
null, callerUser, callerAccount);
+final NetworkOffering offering =
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
if (cleanup) {
+// Destroy non-running VRs
+for (final DomainRouterVO router :
_routerDao.findByNetwork(network.getId())) {
+if (router.getState() != VirtualMachine.State.Running) {
Review comment:
Should VRs in `Migrating` or `Starting` be destroyed as well?
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418859#comment-16418859
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178031995
##
File path:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -2868,6 +2876,82 @@ public boolean restartNetwork(final Long networkId,
final Account callerAccount,
}
}
+@Override
+public VirtualRouter findExpendableRouterForRollingRestart(final List routers) {
+VirtualRouter expendableRouter = null;
+if (routers != null && routers.size() > 1) {
+for (final VirtualRouter router : routers) {
+if (router.getRedundantState() !=
VirtualRouter.RedundantState.MASTER) {
+expendableRouter = router;
+}
+}
+if (expendableRouter == null) {
+expendableRouter = routers.get(routers.size() - 1);
+}
+}
+return expendableRouter;
+}
+
+private boolean rollingRestartRouters(final NetworkVO network, final
NetworkOffering offering, final List oldRouters, final
ReservationContext context) throws ResourceUnavailableException,
ConcurrentOperationException, InsufficientCapacityException {
+final Account callerAccount =
CallContext.current().getCallingAccount();
+final long callerUserId = CallContext.current().getCallingUserId();
+final DeployDestination dest = new
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+final List providersToImplement =
getNetworkProviders(network.getId());
+
+// Find and destroy any expendable router
+final VirtualRouter expendableRouter =
findExpendableRouterForRollingRestart(oldRouters);
+if (expendableRouter != null) {
+_routerService.destroyRouter(expendableRouter.getId(),
callerAccount, callerUserId);
+}
+final List remainingOldRouters =
_routerDao.findByNetwork(network.getId());
+
+// Create a new router
+network.setRollingRestart(true);
+implementNetworkElements(dest, context, network, offering,
providersToImplement);
+network.setRollingRestart(false);
+
+if (network.isRedundant()) {
+try {
+// For redundant network wait for 3*(1+skew_seconds) for VRRP
to kick in
+Thread.sleep(1L);
Review comment:
I am reading the comment, and it uses a variable there, but the code uses a
hard-coded value. Is this right?
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418856#comment-16418856
]
ASF GitHub Bot commented on CLOUDSTACK-9114:
rafaelweingartner commented on a change in pull request #2508: CLOUDSTACK-9114:
Reduce VR downtime during network restart
URL: https://github.com/apache/cloudstack/pull/2508#discussion_r178032576
##
File path: server/src/com/cloud/network/vpc/VpcManagerImpl.java
##
@@ -1508,19 +1519,33 @@ public boolean restartVpc(final long vpcId, final
boolean cleanUp, final boolean
// Change the VPC in order to get it updated after the end of
// the restart procedure.
-_vpcDao.update(vpc.getId(), entity);
+if (_vpcDao.update(vpc.getId(), entity)) {
+vpc = entity;
+}
// If the offering and redundant column are changing, force the
// clean up.
forceCleanup = true;
}
if (forceCleanup) {
Review comment:
Can you extract the body of this IF to a method?
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418846#comment-16418846
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rhtyd commented on a change in pull request #2505: CLOUDSTACK-10333: Secure
Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178033244
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -140,9 +143,11 @@ public int value() {
long _startupWait = _startupWaitDefault;
boolean _reconnectAllowed = true;
//For time sentitive task, e.g. PingTask
-private final ThreadPoolExecutor _ugentTaskPool;
+ThreadPoolExecutor _ugentTaskPool;
ExecutorService _executor;
+Thread _shutdownThread = new ShutdownThread(this);
Review comment:
I'm not fan of them either, but added the name to keep the naming consistent
in the Agent class. Sure, will fix this for all the variables in Agent then.
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418844#comment-16418844
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rhtyd commented on a change in pull request #2505: CLOUDSTACK-10333: Secure
Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178033101
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -274,6 +279,19 @@ public void start() {
}
}
_shell.updateConnectedHost();
+
+// In case of software based restart, GC to remove old instances
+_executor.submit(new Runnable() {
Review comment:
Yes @rafaelweingartner, with the feature we've introduced a background
thread that will perform software based restart of the agent. Look at the post
renewal restart task. With this it will be easier to restart an agent without
actually restarting the agent JVM process. This runnable is needed to GC old
agent instance, we can remove this as well, but keeping it ensures that old
agent is stopped+GC-ed.
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-10344) Sometimes a bug happens when moving ACL rules (changing their order with drag and drop)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418830#comment-16418830 ] ASF GitHub Bot commented on CLOUDSTACK-10344: - blueorangutan commented on issue #2511: [CLOUDSTACK-10344] bug when moving ACL rules (change order with drag and drop) URL: https://github.com/apache/cloudstack/pull/2511#issuecomment-377209438 @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Sometimes a bug happens when moving ACL rules (changing their order with drag > and drop) > > > Key: CLOUDSTACK-10344 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10344 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > An error is happening in certain conditions, such as when you have only 2 ACL > rules and you move the last one to the top. There are other conditions, for > instance, when moving ACLs that are in a sequence of numbers without gaps. > Example, rules: > number | rule > 1 - rule A > 2 - rule D > 3 - rule B > 4 - rule C > 5 - rule E > It is not possible to move "rule C" in position 2, 1, and 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418829#comment-16418829 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377209399 I noticed that you did not forward the merge of this PR. I actually put this in my task list, but if you are going to do I will wait for you. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10344) Sometimes a bug happens when moving ACL rules (changing their order with drag and drop)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418828#comment-16418828 ] ASF GitHub Bot commented on CLOUDSTACK-10344: - DaanHoogland commented on issue #2511: [CLOUDSTACK-10344] bug when moving ACL rules (change order with drag and drop) URL: https://github.com/apache/cloudstack/pull/2511#issuecomment-377209259 @rafaelweingartner slight problem on the test bed side: https://github.com/apache/cloudstack/pull/2505#issuecomment-377195906 @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 > Sometimes a bug happens when moving ACL rules (changing their order with drag > and drop) > > > Key: CLOUDSTACK-10344 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10344 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > An error is happening in certain conditions, such as when you have only 2 ACL > rules and you move the last one to the top. There are other conditions, for > instance, when moving ACLs that are in a sequence of numbers without gaps. > Example, rules: > number | rule > 1 - rule A > 2 - rule D > 3 - rule B > 4 - rule C > 5 - rule E > It is not possible to move "rule C" in position 2, 1, and 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418825#comment-16418825
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rafaelweingartner commented on a change in pull request #2505:
CLOUDSTACK-10333: Secure Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178028132
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -274,6 +279,19 @@ public void start() {
}
}
_shell.updateConnectedHost();
+
+// In case of software based restart, GC to remove old instances
+_executor.submit(new Runnable() {
Review comment:
Can you explaining the goal of this code here?
Remove old instance of Java objects?
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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418824#comment-16418824
]
ASF GitHub Bot commented on CLOUDSTACK-10333:
-
rafaelweingartner commented on a change in pull request #2505:
CLOUDSTACK-10333: Secure Live VM Migration for KVM
URL: https://github.com/apache/cloudstack/pull/2505#discussion_r178027920
##
File path: agent/src/com/cloud/agent/Agent.java
##
@@ -140,9 +143,11 @@ public int value() {
long _startupWait = _startupWaitDefault;
boolean _reconnectAllowed = true;
//For time sentitive task, e.g. PingTask
-private final ThreadPoolExecutor _ugentTaskPool;
+ThreadPoolExecutor _ugentTaskPool;
ExecutorService _executor;
+Thread _shutdownThread = new ShutdownThread(this);
Review comment:
Would you mind not introducing `_` in the code anymore?
They are meaningless in our code base.
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-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418819#comment-16418819 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - DaanHoogland commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377208682 @rafaelweingartner the changes should be forward merged to master and i am procastrinating that task. I see that test was not on my eyes as being unstable yet. maybe something got merged ;) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418800#comment-16418800 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377207223 @DaanHoogland here we have the same "test_04_rvpc_network_garbage_collector_nics" test appearing. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418798#comment-16418798 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - blueorangutan commented on issue #2449: CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-377206986 Trillian test result (tid-2434) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 95679 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2449-t2434-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_routers.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. 63 look OK, 4 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_restart_network_wo_cleanup | `Failure` | 4.09 | test_routers.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 557.43 | test_vpc_redundant.py test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 3.28 | test_host_maintenance.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.51 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10344) Sometimes a bug happens when moving ACL rules (changing their order with drag and drop)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418794#comment-16418794 ] ASF GitHub Bot commented on CLOUDSTACK-10344: - rafaelweingartner commented on issue #2511: [CLOUDSTACK-10344] bug when moving ACL rules (change order with drag and drop) URL: https://github.com/apache/cloudstack/pull/2511#issuecomment-377206430 @DaanHoogland here I am seeing that `test_04_rvpc_network_garbage_collector_nics` test that is failing in one of my other PRs. Interesting enough, here there are other failures, but I did not change code that was already in ACS. Everything I introduce here is new, so this changes should not affect anything else. 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 > Sometimes a bug happens when moving ACL rules (changing their order with drag > and drop) > > > Key: CLOUDSTACK-10344 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10344 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > An error is happening in certain conditions, such as when you have only 2 ACL > rules and you move the last one to the top. There are other conditions, for > instance, when moving ACLs that are in a sequence of numbers without gaps. > Example, rules: > number | rule > 1 - rule A > 2 - rule D > 3 - rule B > 4 - rule C > 5 - rule E > It is not possible to move "rule C" in position 2, 1, and 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418788#comment-16418788
]
ASF GitHub Bot commented on CLOUDSTACK-10226:
-
rafaelweingartner commented on issue #2401: [CLOUDSTACK-10226] CloudStack is
not importing Local storage properly
URL: https://github.com/apache/cloudstack/pull/2401#issuecomment-377205506
@DaanHoogland I checked the error, and I still do not understand how it
could be related to the code of this PR. Here I am only changing how local
storages are detected and loaded to the system. Whereas, the error is related
to redundant VRs in VPCs.
Anyways, I am trying to run the tests locally with simulator, but I am
getting this error:
```
ERROR: do_vpc_test (integration.smoke.test_vpc_redundant.TestVPCRedundancy)
--
TypeError: do_vpc_test() takes exactly 2 arguments (1 given)
>> begin captured stdout << -
=== TestName: do_vpc_test | Status : EXCEPTION ===
```
I am not understanding the cause of that error. This is the command I am
using to execute the test:
`nosetests --with-marvin --marvin-config=/root/marvinCloudStackConfig.cfg
--hypervisor=simulator
/root/cloudstack/test/integration/smoke/test_vpc_redundant.py`
Am I missing something else that is required to run 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
> CloudStack is not importing Local storage properly
> ---
>
> Key: CLOUDSTACK-10226
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>
> CloudStack is importing as Local storage any XenServer SR that is of type LVM
> or EXT. This causes a problem when one wants to use both Direct attach
> storage and local storage. Moreover, CloudStack was not importing all of the
> local storage that a host has available when local storage is enabled. It was
> only importing the First SR it sees.
> To fix the first problem we started ignoring SRs that have the flag
> shared=true when discovering local storages. SRs configured to be shared are
> used as direct attached storage, and therefore should not be imported again
> as local ones.
> To fix the second problem, we started loading all Local storage and importing
> them accordingly to ACS.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418781#comment-16418781 ] 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-377203944 @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 > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418780#comment-16418780 ] 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-377203845 @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 > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418773#comment-16418773 ] 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-377201936 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1849 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418729#comment-16418729 ] 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-377195906 @borisstoyanov as discovered in lab, the issue was related to traffic label and was env related. Please use the sed based unsecuring approach, and avoid cloudstack-setup-agent to speed up tests. @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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418730#comment-16418730 ] 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-377195942 @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] [Resolved] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10332. - Resolution: Fixed > 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-10332) Users are not able to change/edit the protocol of an ACL rule
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418576#comment-16418576
]
ASF GitHub Bot commented on CLOUDSTACK-10332:
-
DaanHoogland closed pull request #2496: [CLOUDSTACK-10332] Users are not able
to change/edit the protocol of an ACL rule
URL: https://github.com/apache/cloudstack/pull/2496
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/api/src/main/java/org/apache/cloudstack/api/ApiConstants.java
b/api/src/main/java/org/apache/cloudstack/api/ApiConstants.java
index ac9406fee99..7825bb4fc93 100644
--- a/api/src/main/java/org/apache/cloudstack/api/ApiConstants.java
+++ b/api/src/main/java/org/apache/cloudstack/api/ApiConstants.java
@@ -309,7 +309,7 @@
public static final String USERNAME = "username";
public static final String USER_SECURITY_GROUP_LIST =
"usersecuritygrouplist";
public static final String USE_VIRTUAL_NETWORK = "usevirtualnetwork";
-public static final String Update_IN_SEQUENCE ="updateinsequence";
+public static final String Update_IN_SEQUENCE = "updateinsequence";
public static final String VALUE = "value";
public static final String VIRTUAL_MACHINE_ID = "virtualmachineid";
public static final String VIRTUAL_MACHINE_IDS = "virtualmachineids";
@@ -453,6 +453,7 @@
public static final String NSP_ID = "nspid";
public static final String ACL_TYPE = "acltype";
public static final String ACL_REASON = "reason";
+public static final String ACL_RULE_PARTIAL_UPGRADE = "partialupgrade";
public static final String SUBDOMAIN_ACCESS = "subdomainaccess";
public static final String LOAD_BALANCER_DEVICE_ID = "lbdeviceid";
public static final String LOAD_BALANCER_DEVICE_NAME = "lbdevicename";
@@ -707,14 +708,12 @@
+ " and just a plain ascii/utf8 representation of a hexadecimal
string. If it is required to\n"
+ " use another algorithm the hexadecimal string is to be prefixed
with a string of the form,\n"
+ " \"{}\", not including the double quotes. In this
is the exact string\n"
-+ " representing the java supported algorithm, i.e. MD5 or
SHA-256. Note that java does not\n"
-+ " contain an algorithm called SHA256 or one called sha-256, only
SHA-256.";
++ " representing the java supported algorithm, i.e. MD5 or
SHA-256. Note that java does not\n" + " contain an algorithm called SHA256 or
one called sha-256, only SHA-256.";
public static final String HAS_ANNOTATION = "hasannotation";
public static final String LAST_ANNOTATED = "lastannotated";
public static final String LDAP_DOMAIN = "ldapdomain";
-
public enum HostDetails {
all, capacity, events, stats, min;
}
diff --git
a/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLItemCmd.java
b/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLItemCmd.java
index 1530239fd12..1215f5710a0 100644
---
a/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLItemCmd.java
+++
b/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLItemCmd.java
@@ -79,6 +79,9 @@
@Parameter(name = ApiConstants.ACL_REASON, type = CommandType.STRING,
description = "A description indicating why the ACL rule is required.")
private String reason;
+@Parameter(name = ApiConstants.ACL_RULE_PARTIAL_UPGRADE, type =
CommandType.BOOLEAN, required = false, description = "Indicates if the ACL rule
is to be updated partially (merging the parameters sent with current
configuration) or completely (disconsidering all of the current
configurations). The default value is 'true'.")
+private boolean partialUpgrade = true;
+
// ///
// / Accessors ///
// ///
@@ -188,4 +191,7 @@ public void checkUuid() {
}
}
+public boolean isPartialUpgrade() {
+return partialUpgrade;
+}
}
diff --git
a/server/src/main/java/com/cloud/network/vpc/NetworkACLServiceImpl.java
b/server/src/main/java/com/cloud/network/vpc/NetworkACLServiceImpl.java
index bfa842807f9..5369ffa4f8a 100644
--- a/server/src/main/java/com/cloud/network/vpc/NetworkACLServiceImpl.java
+++ b/server/src/main/java/com/cloud/network/vpc/NetworkACLServiceImpl.java
@@ -829,6 +829,8 @@ public NetworkACLItem
updateNetworkACLItem(UpdateNetworkACLItemCmd updateNetwork
* We transfer the update information form {@link
UpdateNetworkACLItemCmd} to the {@link NetworkACLItemVO} POJO
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418584#comment-16418584 ] ASF GitHub Bot commented on CLOUDSTACK-10226: - DaanHoogland commented on issue #2401: [CLOUDSTACK-10226] CloudStack is not importing Local storage properly URL: https://github.com/apache/cloudstack/pull/2401#issuecomment-377157866 @rafaelweingartner , i'm cautious here. This one seems consistent. Did you explain the cause of the failure? @mike-tutkowski can you review this (and add yourself to the apache org)? 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 > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418578#comment-16418578 ] ASF subversion and git services commented on CLOUDSTACK-10332: -- Commit 36f4645154bae4b6c79b62d9df93cb94a3323255 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=36f4645 ] [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule (#2496) * [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule * Code formatting > 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-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418579#comment-16418579 ] ASF subversion and git services commented on CLOUDSTACK-10332: -- Commit 36f4645154bae4b6c79b62d9df93cb94a3323255 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=36f4645 ] [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule (#2496) * [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule * Code formatting > 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)
