[jira] [Created] (CLOUDSTACK-9448) CloudStack UI - view and table spacing issue
ilya musayev created CLOUDSTACK-9448: Summary: CloudStack UI - view and table spacing issue Key: CLOUDSTACK-9448 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9448 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.9.0 Environment: Safari Reporter: ilya musayev Fix For: 4.9.1 http://screencast.com/t/mhJgdIsK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410329#comment-15410329
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1542
Oh that's sad, no problem, thanks anyways @DaanHoogland
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410227#comment-15410227
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1615
Packaging result: ✔centos6 ✔centos7 ✔debian repo:
http://packages.shapeblue.com/cloudstack/pr/1615
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410188#comment-15410188 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1623 Packaging result: ✔centos6 ✔centos7 ✔debian repo: http://packages.shapeblue.com/cloudstack/pr/1623 > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410163#comment-15410163
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1615#discussion_r73766528
--- Diff: server/src/com/cloud/storage/ImageStoreDetailsUtil.java ---
@@ -20,48 +20,68 @@
import javax.inject.Inject;
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.framework.config.impl.ConfigurationVO;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDetailsDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreVO;
+import com.cloud.capacity.CapacityManager;
+
public class ImageStoreDetailsUtil {
@Inject
protected ImageStoreDao imageStoreDao;
@Inject
protected ImageStoreDetailsDao imageStoreDetailsDao;
+@Inject
+protected ConfigurationDao configurationDao;
/**
- * Obtain NFS protocol version (if provided) for a store id.
- * It can be set by adding an entry in {@code image_store_details}
table, providing {@code name=nfs.version} and {@code value=X} (e.g. 3)
+ * Retrieve global secondary storage NFS version default value
+ * @return global default value
+ */
+protected Integer getGlobalDefaultNfsVersion(){
+ConfigurationVO globalNfsVersion =
configurationDao.findByName(CapacityManager.ImageStoreNFSVersion.key());
+String value = globalNfsVersion.getValue();
+return (value != null ? Integer.valueOf(value) : null);
+}
+/**
+ * Obtain NFS protocol version (if provided) for a store id, if not
use default config value
* @param storeId image store id
- * @return {@code null} if {@code nfs.version} is not found for
storeId
- * {@code X} if {@code nfs.version} is found found for storeId
+ * @return {@code null} if {@code secstorage.nfs.version} is not found
for storeId
+ * {@code X} if {@code secstorage.nfs.version} is found found for
storeId
*/
public Integer getNfsVersion(long storeId) throws
NumberFormatException {
-String nfsVersion = null;
+Integer nfsVersion;
if (imageStoreDetailsDao.getDetails(storeId) != null){
Map storeDetails =
imageStoreDetailsDao.getDetails(storeId);
--- End diff --
I recognize that this code predates this patch, but it is a double API
call. Consider the following refactoring:
```
public Integer getNfsVersion(long storeId) throws NumberFormatException {
final Map storeDetails =
imageStoreDetailsDao.getDetails(storeId);
if (storeDetails != null &&
storeDetails.containsKey(CapacityManager.ImageStoreNFSVersion.key())) {
final String version =
storeDetails.get(CapacityManager.ImageStoreNFSVersion.key());
return (val != null ? Integer.valueOf(val) : null);
}
return getGlobalDefaultNfsVersion();
}
```
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4.
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410151#comment-15410151
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1615#discussion_r73765825
--- Diff: server/src/com/cloud/storage/ImageStoreDetailsUtil.java ---
@@ -20,48 +20,68 @@
import javax.inject.Inject;
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.framework.config.impl.ConfigurationVO;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDetailsDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreVO;
+import com.cloud.capacity.CapacityManager;
+
public class ImageStoreDetailsUtil {
@Inject
protected ImageStoreDao imageStoreDao;
@Inject
protected ImageStoreDetailsDao imageStoreDetailsDao;
+@Inject
+protected ConfigurationDao configurationDao;
/**
- * Obtain NFS protocol version (if provided) for a store id.
- * It can be set by adding an entry in {@code image_store_details}
table, providing {@code name=nfs.version} and {@code value=X} (e.g. 3)
+ * Retrieve global secondary storage NFS version default value
+ * @return global default value
+ */
+protected Integer getGlobalDefaultNfsVersion(){
+ConfigurationVO globalNfsVersion =
configurationDao.findByName(CapacityManager.ImageStoreNFSVersion.key());
+String value = globalNfsVersion.getValue();
+return (value != null ? Integer.valueOf(value) : null);
+}
+/**
+ * Obtain NFS protocol version (if provided) for a store id, if not
use default config value
* @param storeId image store id
- * @return {@code null} if {@code nfs.version} is not found for
storeId
- * {@code X} if {@code nfs.version} is found found for storeId
+ * @return {@code null} if {@code secstorage.nfs.version} is not found
for storeId
+ * {@code X} if {@code secstorage.nfs.version} is found found for
storeId
*/
public Integer getNfsVersion(long storeId) throws
NumberFormatException {
-String nfsVersion = null;
+Integer nfsVersion;
--- End diff --
Variables should always be initialized. Consider initializing to ``null``.
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410147#comment-15410147
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1615#discussion_r73765615
--- Diff: server/src/com/cloud/storage/ImageStoreDetailsUtil.java ---
@@ -20,48 +20,68 @@
import javax.inject.Inject;
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.framework.config.impl.ConfigurationVO;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreDetailsDao;
import org.apache.cloudstack.storage.datastore.db.ImageStoreVO;
+import com.cloud.capacity.CapacityManager;
+
public class ImageStoreDetailsUtil {
@Inject
protected ImageStoreDao imageStoreDao;
@Inject
protected ImageStoreDetailsDao imageStoreDetailsDao;
+@Inject
+protected ConfigurationDao configurationDao;
/**
- * Obtain NFS protocol version (if provided) for a store id.
- * It can be set by adding an entry in {@code image_store_details}
table, providing {@code name=nfs.version} and {@code value=X} (e.g. 3)
+ * Retrieve global secondary storage NFS version default value
+ * @return global default value
+ */
+protected Integer getGlobalDefaultNfsVersion(){
+ConfigurationVO globalNfsVersion =
configurationDao.findByName(CapacityManager.ImageStoreNFSVersion.key());
+String value = globalNfsVersion.getValue();
--- End diff --
What if ``globalNfsVersion`` is null?
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410145#comment-15410145
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1615#discussion_r73765448
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java
---
@@ -520,6 +528,16 @@ public String updateConfiguration(final long userId,
final String name, final St
_accountDetailsDao.update(accountDetailVO.getId(),
accountDetailVO);
}
break;
+
+case ImageStore:
+final ImageStoreVO imgStore =
_imageStoreDao.findById(resourceId);
+if (imgStore == null) {
+throw new InvalidParameterValueException("unable to
find image store by id " + resourceId);
--- End diff --
``InvalidParameterValueException`` is used to indicate that an invalid
parameter was passed by a caller to a method. Since ``imgStore`` was not
passed into this method, it does not seem appropriate to use this exception
type. ``IllegalStateException`` seems more appropriate. Also, consider using
``Preconditions.checkState`` to replace the ``if`` block with a single line of
code for greater concession.
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410136#comment-15410136
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1615#discussion_r73764835
--- Diff:
api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java ---
@@ -145,6 +156,9 @@ public void execute() {
if (getAccountId() != null) {
response.setScope("account");
}
+if (getImageStoreId() != null) {
+response.setScope("imagestore");
+}
--- End diff --
Please remove this check and adding ``validations = PositiveNumber`` to the
``imageStoreId @Parameter`` annotation.
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410102#comment-15410102
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1615
A Trillian-Jenkins job has been kicked to build packages and start testing.
I'll keep you posted as I make progress.
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410101#comment-15410101
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1615
@blueorangutan kick
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410095#comment-15410095 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1623 A Trillian-Jenkins job has been kicked to build packages and start testing. I'll keep you posted as I make progress. > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410097#comment-15410097
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user DaanHoogland commented on the issue:
https://github.com/apache/cloudstack/pull/1542
@nvazquez unfortunately I no longer am involved in cloud computing. I'd
really need a deep dive to give value, sorry.
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410091#comment-15410091 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1623 @blueorangutan kick > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410088#comment-15410088 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1623 @blueorangutan kick > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410012#comment-15410012
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1602
Packaging result: ✔centos6 ✔centos7 ✖debian repo:
http://packages.shapeblue.com/cloudstack/pr/1602
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410006#comment-15410006
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73753345
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
---
@@ -537,15 +540,51 @@ public Answer executeRequest(Command cmd) {
protected void
checkStorageProcessorAndHandlerNfsVersionAttribute(StorageSubSystemCommand cmd)
{
if (storageNfsVersion != null) return;
if (cmd instanceof CopyCommand){
-examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd);
+EnumMap
params = new
EnumMap(VmwareStorageProcessorConfigurableFields.class);
+examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd,
params);
+
examineStorageSubSystemCommandFullCloneFlagForVmware((CopyCommand) cmd, params);
+reconfigureProcessorByHandler(params);
+}
+}
+
+/**
+ * Reconfigure processor by handler
+ * @param params params
+ */
+protected void
reconfigureProcessorByHandler(EnumMap
params) {
+VmwareStorageSubsystemCommandHandler handler =
(VmwareStorageSubsystemCommandHandler) storageHandler;
+boolean success = handler.reconfigureStorageProcessor(params);
+if (success){
+s_logger.info("VmwareStorageProcessor and
VmwareStorageSubsystemCommandHandler successfully reconfigured");
+} else {
+s_logger.error("Error while reconfiguring
VmwareStorageProcessor and VmwareStorageSubsystemCommandHandler");
--- End diff --
Done, thanks
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410008#comment-15410008
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73753387
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
---
@@ -537,15 +540,51 @@ public Answer executeRequest(Command cmd) {
protected void
checkStorageProcessorAndHandlerNfsVersionAttribute(StorageSubSystemCommand cmd)
{
if (storageNfsVersion != null) return;
if (cmd instanceof CopyCommand){
-examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd);
+EnumMap
params = new
EnumMap(VmwareStorageProcessorConfigurableFields.class);
+examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd,
params);
+
examineStorageSubSystemCommandFullCloneFlagForVmware((CopyCommand) cmd, params);
+reconfigureProcessorByHandler(params);
+}
+}
+
+/**
+ * Reconfigure processor by handler
+ * @param params params
+ */
+protected void
reconfigureProcessorByHandler(EnumMap
params) {
+VmwareStorageSubsystemCommandHandler handler =
(VmwareStorageSubsystemCommandHandler) storageHandler;
+boolean success = handler.reconfigureStorageProcessor(params);
+if (success){
+s_logger.info("VmwareStorageProcessor and
VmwareStorageSubsystemCommandHandler successfully reconfigured");
+} else {
+s_logger.error("Error while reconfiguring
VmwareStorageProcessor and VmwareStorageSubsystemCommandHandler");
+}
+}
+
+/**
+ * Examine StorageSubSystem command to get full clone flag, if provided
+ * @param cmd command to execute
+ * @param params params
+ */
+protected void
examineStorageSubSystemCommandFullCloneFlagForVmware(CopyCommand cmd,
EnumMap params) {
+HypervisorType hypervisor = cmd.getDestTO().getHypervisorType();
+if (hypervisor == null || (hypervisor != null && !
hypervisor.equals(HypervisorType.VMware))) return;
+
+DataStoreTO destDataStore = cmd.getDestTO().getDataStore();
+if (destDataStore instanceof PrimaryDataStoreTO){
+PrimaryDataStoreTO dest = (PrimaryDataStoreTO) destDataStore;
+if (dest.isFullCloneFlag() != null){
+
params.put(VmwareStorageProcessorConfigurableFields.FULL_CLONE_FLAG,
dest.isFullCloneFlag().booleanValue());
--- End diff --
Done, thanks for the review
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409919#comment-15409919
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73745286
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageSubsystemCommandHandler.java
---
@@ -66,19 +68,28 @@ public
VmwareStorageSubsystemCommandHandler(StorageProcessor processor, Integer
this._nfsVersion = nfsVersion;
}
-/**
- * Reconfigure NFS version for storage operations
- * @param nfsVersion NFS version to set
- * @return true if NFS version could be configured, false in other case
- */
-public boolean reconfigureNfsVersion(Integer nfsVersion){
+public boolean
reconfigureStorageProcessor(EnumMap
params) {
+VmwareStorageProcessor processor = (VmwareStorageProcessor)
this.processor;
try {
-VmwareStorageProcessor processor = (VmwareStorageProcessor)
this.processor;
-processor.setNfsVersion(nfsVersion);
-this._nfsVersion = nfsVersion;
+for (VmwareStorageProcessorConfigurableFields key :
params.keySet()){
+switch (key){
+case NFS_VERSION:
+Integer nfsVersion = (Integer) params.get(key);
+processor.setNfsVersion(nfsVersion);
+this._nfsVersion = nfsVersion;
+break;
+case FULL_CLONE_FLAG:
+boolean fullClone = (boolean) params.get(key);
+processor.setFullCloneFlag(fullClone);
+break;
+default:
+String msg = "Unknown reconfigurable field " +
key.getName() + " for VmwareStorageProcessor";
+throw new Exception(msg);
--- End diff --
General Java best practice never to throw ``Exception`` because it does not
provide specific cause information. Consider using ``IllegalStateException``
instead.
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409918#comment-15409918
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73744970
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
---
@@ -537,15 +540,51 @@ public Answer executeRequest(Command cmd) {
protected void
checkStorageProcessorAndHandlerNfsVersionAttribute(StorageSubSystemCommand cmd)
{
if (storageNfsVersion != null) return;
if (cmd instanceof CopyCommand){
-examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd);
+EnumMap
params = new
EnumMap(VmwareStorageProcessorConfigurableFields.class);
+examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd,
params);
+
examineStorageSubSystemCommandFullCloneFlagForVmware((CopyCommand) cmd, params);
+reconfigureProcessorByHandler(params);
+}
+}
+
+/**
+ * Reconfigure processor by handler
+ * @param params params
+ */
+protected void
reconfigureProcessorByHandler(EnumMap
params) {
+VmwareStorageSubsystemCommandHandler handler =
(VmwareStorageSubsystemCommandHandler) storageHandler;
+boolean success = handler.reconfigureStorageProcessor(params);
+if (success){
+s_logger.info("VmwareStorageProcessor and
VmwareStorageSubsystemCommandHandler successfully reconfigured");
+} else {
+s_logger.error("Error while reconfiguring
VmwareStorageProcessor and VmwareStorageSubsystemCommandHandler");
+}
+}
+
+/**
+ * Examine StorageSubSystem command to get full clone flag, if provided
+ * @param cmd command to execute
+ * @param params params
+ */
+protected void
examineStorageSubSystemCommandFullCloneFlagForVmware(CopyCommand cmd,
EnumMap params) {
+HypervisorType hypervisor = cmd.getDestTO().getHypervisorType();
+if (hypervisor == null || (hypervisor != null && !
hypervisor.equals(HypervisorType.VMware))) return;
+
+DataStoreTO destDataStore = cmd.getDestTO().getDataStore();
+if (destDataStore instanceof PrimaryDataStoreTO){
+PrimaryDataStoreTO dest = (PrimaryDataStoreTO) destDataStore;
+if (dest.isFullCloneFlag() != null){
+
params.put(VmwareStorageProcessorConfigurableFields.FULL_CLONE_FLAG,
dest.isFullCloneFlag().booleanValue());
--- End diff --
Modifying a passed parameter creates side-effects that increase coupling.
Consider refactoring to return a copy of the ``params`` parameter than contains
the new values.
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409914#comment-15409914
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73744705
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
---
@@ -537,15 +540,51 @@ public Answer executeRequest(Command cmd) {
protected void
checkStorageProcessorAndHandlerNfsVersionAttribute(StorageSubSystemCommand cmd)
{
if (storageNfsVersion != null) return;
if (cmd instanceof CopyCommand){
-examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd);
+EnumMap
params = new
EnumMap(VmwareStorageProcessorConfigurableFields.class);
+examineStorageSubSystemCommandNfsVersion((CopyCommand) cmd,
params);
+
examineStorageSubSystemCommandFullCloneFlagForVmware((CopyCommand) cmd, params);
+reconfigureProcessorByHandler(params);
+}
+}
+
+/**
+ * Reconfigure processor by handler
+ * @param params params
+ */
+protected void
reconfigureProcessorByHandler(EnumMap
params) {
+VmwareStorageSubsystemCommandHandler handler =
(VmwareStorageSubsystemCommandHandler) storageHandler;
+boolean success = handler.reconfigureStorageProcessor(params);
+if (success){
+s_logger.info("VmwareStorageProcessor and
VmwareStorageSubsystemCommandHandler successfully reconfigured");
+} else {
+s_logger.error("Error while reconfiguring
VmwareStorageProcessor and VmwareStorageSubsystemCommandHandler");
--- End diff --
Please include the values contained in ``params`` in the log message to
help operators diagnose the cause of the error.
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409902#comment-15409902
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73742358
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
---
@@ -1353,6 +1363,20 @@ public void prepare(VirtualMachineProfile vm,
DeployDestination dest) throws Sto
disk.setDetails(getDetails(volumeInfo, dataStore));
vm.addDisk(disk);
+
+// If hypervisor is vSphere, check for clone type setting.
+if (vm.getHypervisorType().equals(HypervisorType.VMware)) {
+// retrieve clone flag.
+UserVmCloneType cloneType = UserVmCloneType.linked;
+Boolean value =
CapacityManager.VmwareCreateCloneFull.valueIn(vol.getPoolId());
+if (value != null) {
+if (value.booleanValue() == true)
--- End diff --
Please collapse lines lines 1372 and 1373 into ``if (value != null &&
value)``. The compiler will autobox the ``Boolean`` instance -- removing the
requirement to call ``booleanValue``.
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409899#comment-15409899
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r73742107
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
---
@@ -1353,6 +1363,20 @@ public void prepare(VirtualMachineProfile vm,
DeployDestination dest) throws Sto
disk.setDetails(getDetails(volumeInfo, dataStore));
vm.addDisk(disk);
+
+// If hypervisor is vSphere, check for clone type setting.
+if (vm.getHypervisorType().equals(HypervisorType.VMware)) {
--- End diff --
@syed has this question/issue been answered by @nvazquez to your
satisfaction?
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409874#comment-15409874
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user jburwell commented on the issue:
https://github.com/apache/cloudstack/pull/1602
@rhtyd can you re-kick this PR for @blueorangutan?
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409469#comment-15409469
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1602
I rebased master branch and pushed again, could it be ran again?
@blueorangutan
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409434#comment-15409434 ] ASF GitHub Bot commented on CLOUDSTACK-9444: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1621 @jburwell I can do it late next week, pretty stacked up currently. > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9422) Granular VMware vm's creation as full clones on HV
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409432#comment-15409432
]
ASF GitHub Bot commented on CLOUDSTACK-9422:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1602
Packaging result: ✖centos6 ✖centos7 ✖debian repo:
http://packages.shapeblue.com/cloudstack/pr/1602
> Granular VMware vm's creation as full clones on HV
> --
>
> Key: CLOUDSTACK-9422
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9422
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> For VMware, It is possible to decide creating VMs as full clones on ESX HV,
> adjusting {{vmware.create.full.clone}} global setting. We would like to
> introduce this property as a primary storage detail, and use its value
> instead of global setting's value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409427#comment-15409427 ] ASF GitHub Bot commented on CLOUDSTACK-9444: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1621 Packaging result: ✔centos6 ✔centos7 ✔debian repo: http://packages.shapeblue.com/cloudstack/pr/1621 > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-9446. --- > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409385#comment-15409385 ] ASF GitHub Bot commented on CLOUDSTACK-9444: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1621 @borisstoyanov do you have the bandwidth to manually test upgrading 4.8 to 4.9 using this patch? > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409302#comment-15409302 ] ASF GitHub Bot commented on CLOUDSTACK-9444: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1621 The changes won't be tested by Trillian as it does not support upgrade tests yet. Based on the packaging result, we can accept it if anyone has performed an upgrade test manually. /cc @karuturi @jburwell > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409296#comment-15409296 ] ASF GitHub Bot commented on CLOUDSTACK-9444: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1621 Alright, your PR did not break packaging! Packages built and available at: http://packages.shapeblue.com/cloudstack/custom/github-1621 > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409271#comment-15409271 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 @rhtyd I couldn't find either. Let me know if you see any issues. > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8948) Volume migration not working in asynchronous way
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8948. - Resolution: Fixed all the operation on a VM are queued. But, operations on different vms can be parallel. please test with latest version and reopen if you are still facing this issue. > Volume migration not working in asynchronous way > > > Key: CLOUDSTACK-8948 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8948 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, VMware, Volumes >Affects Versions: 4.5.2 > Environment: vSphere 5.5 > CentOS 6.5 > 2 Mangament Servers > 1 MySQL Server >Reporter: Emil >Priority: Blocker > > We are trying to use the command migrateVolume which is written as > asynchronous in cloudstack API. > But in some way every time we try to run the command (through the API or Web) > only 1x migration running at a time (At very very rare situations 2x > migrations running simultaneously). > I tried to check every configuration settings especially those: > execute.in.sequence.hypervisor.commands > execute.in.sequence.network.element.commands > They were defaulted as false, I tried them with true as value also didnt > worked. > Also if we are trying to run storage vMotion through the vSphere client, it > working great (3,4,5 simultaneously) > Some logs conclusions: > When preforming the first volumeMigration it seems like each task has a > sequence id, which registerd some where, > then the task "Executing" it self and every thing fine. Got unique job > id for the task (to trace the status). > When the second volumeMigration executed there is a line in the log > which very suspicious and it says: > "Waiting for Seq 244522346426 Scheduling: .." > That sequence id is the id of the first migration ! Why the hell he > waiting for the first task ?! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8972) When Creating Jobs from GUI. Job does not start, no Notifications pending
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8972. - Resolution: Cannot Reproduce please test with latest version and reopen if you are still facing this issue. > When Creating Jobs from GUI. Job does not start, no Notifications pending > - > > Key: CLOUDSTACK-8972 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8972 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 > Environment: CentOS >Reporter: Prieur Leary >Priority: Blocker > > When we had a switch fail between CS Manager, and KVM Hosts nodes, CS showed > many hosts down. > Upon a restart of CS Management Service, GUI comes up, but will not take > commands to create jobs. Job gets created in aysync_job table, but does not > run, and no Notification in the GUI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9209) Database HA not working on a fresh install on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-9209. - Resolution: Fixed > Database HA not working on a fresh install on Ubuntu 12.04 > -- > > Key: CLOUDSTACK-9209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9209 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.0 > Environment: Two Ubuntu 12.04 Management Servers, Mysql Master Master > Replication, Official community repository: > http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.7/ >Reporter: Thomas >Priority: Blocker > > The cloudstack-management service will not come up because of this error: > 2016-01-05 16:15:00,899 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is > Data Base High Availiability enabled? Ans : true > 2016-01-05 16:15:00,924 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) > The slaves configured for Cloud Data base is/are : 192.168.0.90 > 2016-01-05 16:15:00,974 ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) > Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931) > at com.mysql.jdbc.Util.loadExtensions(Util.java:588) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:279) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at >
[jira] [Updated] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-9379:
Fix Version/s: (was: 4.10.0)
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9402: Fix Version/s: (was: 4.10.0) > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networks with different combinations of Static NAT > service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Static NAT service > providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Static NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_05_nuage_StaticNAT_isolated_networks_traffic | Status : SUCCESS === > ok > Test Nuage VSP Static NAT functionality for VPC network by
[jira] [Updated] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9402: Affects Version/s: 4.10.0 > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networks with different combinations of Static NAT > service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Static NAT service > providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Static NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_05_nuage_StaticNAT_isolated_networks_traffic | Status : SUCCESS === > ok > Test Nuage VSP Static NAT functionality for VPC network by
[jira] [Updated] (CLOUDSTACK-9282) VPC Inline LB plugin (VPC Public Load Balancing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9282: Fix Version/s: (was: 4.10.0) > VPC Inline LB plugin (VPC Public Load Balancing) > > > Key: CLOUDSTACK-9282 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9282 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0 >Reporter: Nick Livens >Assignee: Nick Livens > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9163) Dynamically routed VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9163: Fix Version/s: (was: 4.10.0) > Dynamically routed VPCs > --- > > Key: CLOUDSTACK-9163 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9163 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.8.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > In cloudstack traffic between VPC’s is routed via there public interface by > core-routers. OSPF protocol running on VPC routers in conjunction with the > core-routers will take care of routing between different VPC’s as well as > public network in most efficient manner. VPC’s traffic will be directly > routed via its router without going thru the core routers. > Quagga implements OSPF (v2, v3) and is found suitable to run on debian > based VPC virtual router to provide dynamic routing. Quagga is an advanced > software routing package that provides a suite of TCP/IP-based routing > protocols and provides implementations of OSPFv2, OSPFv3, RIP v1 and v2, > RIPng and BGP-4 for Unix-like platforms, particularly FreeBSD, Linux, Solaris > and NetBSD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409249#comment-15409249 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user rhtyd closed the pull request at: https://github.com/apache/cloudstack/pull/1612 > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9408: Fix Version/s: (was: 4.10.0) > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409248#comment-15409248 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1612 Thanks @karuturi I'm not sure why the PR did not close, closing it manually now. > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-9446. - Resolution: Fixed > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9446: Fix Version/s: (was: 4.8.1) > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409234#comment-15409234
]
ASF GitHub Bot commented on CLOUDSTACK-9438:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1615
Alright, your PR did not break packaging! Packages built and available at:
http://packages.shapeblue.com/cloudstack/custom/github-1615
> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was
> possible to configure NFS version for secondary storage mount.
> However, changing NFS version requires inserting an new detail on
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value =
> X}} where X is desired NFS version, and then restarting management server for
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}}
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore*
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}}
> to {{cloud-engine-schema}} module in order to Spring find those beans to
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be
> injected on {{ConfigurationManagerImpl}}, if we added dependency from
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}}
> module
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409224#comment-15409224 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 This is merged to all the branches https://github.com/apache/cloudstack/commit/2875af71126cbfb6ebd0d47c2d593ff6d9c61c20 > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409209#comment-15409209 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user ProjectMoon commented on the issue: https://github.com/apache/cloudstack/pull/1623 JIRA ticket is CLOUDSTACK-9317. Have not run the Marvin tests, but will do so. > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409211#comment-15409211
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user ProjectMoon commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1623#discussion_r73664374
--- Diff: server/src/com/cloud/network/IpAddressManagerImpl.java ---
@@ -1698,6 +1698,22 @@ public String acquireGuestIpAddress(Network network,
String requestedIp) {
Random _rand = new Random(System.currentTimeMillis());
+/**
+ * Get the list of public IPs that need to be applied for a static NAT
enable/disable operation.
+ * Manipulating only these ips prevents concurrency issues when
disabling static nat at the same time.
+ * @param staticNats
+ * @return The list of IPs that need to be applied for the static NAT
to work.
+ */
+public List getStaticNatSourceIps(List staticNats) {
+List userIps = new ArrayList<>();
+
+for (StaticNat snat : staticNats) {
+
userIps.add(_ipAddressDao.findById(snat.getSourceIpAddressId()));
+}
--- End diff --
This makes sense, yes. Better to have one database query than many.
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409198#comment-15409198 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1612 Thank you @karuturi > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409190#comment-15409190 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 I see the following successfully built packages on 4.8 cloudstack-agent-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-baremetal-agent-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-cli-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-common-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-integration-tests-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-management-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-marvin-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-usage-4.8.1-SNAPSHOT.el7.centos.x86_64.rpm I am forwarding merging this from 4.7 without further tests on 4.9 and master > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409166#comment-15409166 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1612 @karuturi thanks, I understand now. You're right, I sent for 4.7 as we support fwd-merging since 4.7 and we might need to test a 4.7 based security release in future. > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409163#comment-15409163 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 I meant 4.7 is not a supported release by the community and there wont be any more releases from it. > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9446: Fix Version/s: 4.9.1 4.10.0 4.8.1 > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.8.1, 4.10.0, 4.9.1 > > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409150#comment-15409150 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 I can see the following packages after a successful build on 4.7 cloudstack-agent-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-baremetal-agent-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-cli-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-common-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-integration-tests-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-management-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-marvin-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm cloudstack-usage-4.7.2-SNAPSHOT.el7.centos.x86_64.rpm I am rebuilding it on 4.8 > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9447) Fix systemvm template build failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-9447: Status: Reviewable (was: In Progress) > Fix systemvm template build failure > --- > > Key: CLOUDSTACK-9447 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9447 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > > SystemVM template build code has not been maintained in past months, the ISO > url does not work. Further certain openswan pkg version no longer is > available and is replaced by an package with the same version but newer pkg > name. The fix should do: > Bumps base debian iso to version 7.11 > Upgrade ruby version to 2.3.0 (latest/stable) > Fix Gemfile > Update README -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9447) Fix systemvm template build failure
Rohit Yadav created CLOUDSTACK-9447: --- Summary: Fix systemvm template build failure Key: CLOUDSTACK-9447 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9447 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav SystemVM template build code has not been maintained in past months, the ISO url does not work. Further certain openswan pkg version no longer is available and is replaced by an package with the same version but newer pkg name. The fix should do: Bumps base debian iso to version 7.11 Upgrade ruby version to 2.3.0 (latest/stable) Fix Gemfile Update README -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409029#comment-15409029 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1612 @karuturi I don't understand your comment, centos7 packages have been supported since 4.6 (actually 4.5 too ships a centos7 repository). The PR is for 4.7 as it would fix and improve testing for all branches/versions since 4.7 (we at least need this on 4.8, 4.9 and master). Further, this does not make any changes to CloudStack. > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409014#comment-15409014 ] ASF GitHub Bot commented on CLOUDSTACK-9446: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1612 I just realised that I started bulding centos7 pacakges on 4.7 which is not supported now. Do you want this in 4.7 given that we dont do anymore releases on it? > Package marvin and integration-tests for making testing easier > -- > > Key: CLOUDSTACK-9446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > > CloudStack is tested using deb/rpm packages by CI systems like Trillian, > Bubble etc. When we test using packages we don't know exactly which > integration tests or marvin to install/run unless the git sha is known. By > packaging marvin and integration-tests too, we can make it easier for CI > systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8415) [VMware] SSVM shutdown during snapshot operation results in disks to be left behind
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409002#comment-15409002 ] ASF GitHub Bot commented on CLOUDSTACK-8415: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/540 @jburwell Likitha has moved on, unlikely we'll hear from her or see further development activity > [VMware] SSVM shutdown during snapshot operation results in disks to be left > behind > > > Key: CLOUDSTACK-8415 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8415 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: Future > > > Partial disks are residue of a failed snapshot operation caused by SSVM > reboot/shutdown. The disks do not get cleaned up on secondary storage and > need to be cleaned up manually to release storage. > +Steps to reproduce+ > 1. Initiate a volume snapshot operation. > 2. Destroy SSVM while the operation is in progress. > 3. Check the snapshot folder in secondary storage - Files including disks are > present in the folder and are never cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9446) Package marvin and integration-tests for making testing easier
Rohit Yadav created CLOUDSTACK-9446: --- Summary: Package marvin and integration-tests for making testing easier Key: CLOUDSTACK-9446 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9446 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav CloudStack is tested using deb/rpm packages by CI systems like Trillian, Bubble etc. When we test using packages we don't know exactly which integration tests or marvin to install/run unless the git sha is known. By packaging marvin and integration-tests too, we can make it easier for CI systems and people to install marvin and run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
