date:20180219

[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10054:
-

mrunalinikankariya commented on issue #2244: CLOUDSTACK-10054:Volume download 
times out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#issuecomment-366866181
 
 
   @DaanHoogland 
   test_hostha_enable_ha_when_host_in_maintenance test is faling with error 
code 530 and error 'Unable to prepare for maintenance host 2'. Seems some issue 
with authentication or connection. It should not be related to changes in this 
PR


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


> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in 
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed 
> out in an hour. The volume is of 800GB and we should be able to increase the 
> timeout. Unfortunately there is not method to do that. There is no global 
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar 
> commands(commands taking long time)



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

[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10301:
-

rafaelweingartner opened a new pull request #2462: [CLOUDSTACK-10301] Allow 
updating the network ACL list name and Description
URL: https://github.com/apache/cloudstack/pull/2462
 
 
   Currently, it is not possible to update the Network ACL name or Description 
of an ACL after it has been created. It might be interesting to expose this 
option via API and to add this feature to the UI.


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


> Allow updating the network ACL list name and Description 
> -
>
> Key: CLOUDSTACK-10301
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> Currently, it is not possible to update the Network ACL name or Description 
> of an ACL after it has been created. It might be interesting to expose this 
> option via API and to add this feature to the UI.



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

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

rafaelweingartner closed pull request #2402: [CLOUDSTACK-10128] Simplify the 
search for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402
 
 
   

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

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

diff --git a/engine/schema/src/com/cloud/host/dao/HostDao.java 
b/engine/schema/src/com/cloud/host/dao/HostDao.java
index 9e967e34efd..71c9cd23867 100644
--- a/engine/schema/src/com/cloud/host/dao/HostDao.java
+++ b/engine/schema/src/com/cloud/host/dao/HostDao.java
@@ -19,13 +19,12 @@
 import java.util.Date;
 import java.util.List;
 
-import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
-
 import com.cloud.host.Host;
 import com.cloud.host.Host.Type;
 import com.cloud.host.HostVO;
 import com.cloud.host.Status;
 import com.cloud.hypervisor.Hypervisor;
+import com.cloud.hypervisor.Hypervisor.HypervisorType;
 import com.cloud.info.RunningHostCountInfo;
 import com.cloud.resource.ResourceState;
 import com.cloud.utils.db.GenericDao;
@@ -99,14 +98,13 @@
 HostVO findByIp(String ip);
 
 /**
- * This method will look for a host that is of the same hypervisor and 
same zone as the storage pool where the volume of the Snapshot is stored.
+ * This method will look for a host that is of the same hypervisor and 
zone as indicated in its parameters.
  * 
- * (this is applicable only for XenServer) If the storage pool is 
managed, then we will look for a host that has the property 'supportsResign' in 
cloud.cluster_details
  * We give priority to 'Enabled' hosts, but if no 'Enabled' hosts are 
found, we use 'Disabled' hosts
  * If no host is found, we throw a runtime exception
  * 
  *
  * Side note: this method is currently only used in XenServerGuru; 
therefore, it was designed to meet XenServer deployment scenarios requirements.
  */
-HostVO findHostToOperateOnSnapshotBasedOnStoragePool(StoragePoolVO 
storagePoolVO);
+HostVO findHostInZoneToExecuteCommand(long zoneId, HypervisorType 
hypervisorType);
 }
diff --git a/engine/schema/src/com/cloud/host/dao/HostDaoImpl.java 
b/engine/schema/src/com/cloud/host/dao/HostDaoImpl.java
index c1403d08609..e48bfd58a6a 100644
--- a/engine/schema/src/com/cloud/host/dao/HostDaoImpl.java
+++ b/engine/schema/src/com/cloud/host/dao/HostDaoImpl.java
@@ -24,14 +24,13 @@
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
+import java.util.Objects;
 import java.util.TimeZone;
 
 import javax.annotation.PostConstruct;
 import javax.inject.Inject;
 import javax.persistence.TableGenerator;
 
-import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
-import org.apache.commons.lang3.StringUtils;
 import org.apache.log4j.Logger;
 import org.springframework.stereotype.Component;
 
@@ -50,6 +49,7 @@
 import com.cloud.host.Status;
 import com.cloud.host.Status.Event;
 import com.cloud.hypervisor.Hypervisor;
+import com.cloud.hypervisor.Hypervisor.HypervisorType;
 import com.cloud.info.RunningHostCountInfo;
 import com.cloud.org.Grouping;
 import com.cloud.org.Managed;
@@ -1168,25 +1168,23 @@ public HostVO findByIp(final String ipAddress) {
 return listBy(sc);
 }
 
-String sqlFindHostConnectedToStoragePoolToExecuteCommand = "select h.id 
from storage_pool pool "
-+ " join cluster c on pool.cluster_id = c.id "
-+ " %s "
-+ " join host h on h.data_center_id = c.data_center_id and 
h.hypervisor_type = c.hypervisor_type"
-+ " where pool.id = ? and h.status = 'Up' and h.type = 'Routing' 
and resource_state = '%s' "
-+ " ORDER by rand() limit 1 ";
+String sqlFindHostInZoneToExecuteCommand = "Select  id from host "
++ " where type = 'Routing' and hypervisor_type = ? and 
data_center_id = ? and status = 'Up' "
++ " and resource_state = '%s' "
++ " ORDER by rand() limit 1";
 
 @Override
-public HostVO findHostToOperateOnSnapshotBasedOnStoragePool(StoragePoolVO 
storagePoolVO) {
+public HostVO findHostInZoneToExecuteCommand(long zoneId, HypervisorType 
hypervisorType) {
 try (TransactionLegacy tx = TransactionLegacy.currentTxn()) {
-String sql = 
createSqlFindHostConnectedToStoragePoolToExecuteCommand(storagePoolVO, false);
-ResultSet rs = 
executeSqlGetResultSetForMethodFindHostToOperateBasedOnStoragePool(storagePoolVO,
 tx, sql);
+String sql = createSqlFindHostToExecuteCommand(false);
+ResultSet rs =

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

mike-tutkowski commented on issue #2402: [CLOUDSTACK-10128] Simplify the search 
for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402#issuecomment-366800222
 
 
   Sounds good - we should all get used to marking that field.
   
   On Feb 19, 2018, at 12:46 PM, Rafael Weingärtner 
> wrote:
   
   
   @mike-tutkowski thanks!
   I am getting used to look directly to the "reviweres" section on Github and 
checking the approved ones. I did not seen any for this PR, that is why I asked 
again.
   
   —
   You are receiving this because you were mentioned.
   Reply to this email directly, view it on 
GitHub, 
or mute the 
thread.
   


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


> Template from snapshot not merging vhd files
> 
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0, 
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
>Reporter: Marcelo Lima
>Assignee: Rafael Weingärtner
>Priority: Critical
> Fix For: 4.11.0.0
>
>
> If we have two or more snapshots of a ROOT disk and try to create a template 
> from differencial snapshots, CloudStack not merging the vhd files on 
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage 
> correctly
> [root@acs01 6]# ls -l 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> 
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>  
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:17 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>   
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/ 
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:21 
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>  
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:30 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second 
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:34 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l 
>

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

rafaelweingartner commented on issue #2402: [CLOUDSTACK-10128] Simplify the 
search for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402#issuecomment-366800251
 
 
   Since everything is ok, I will merge this one. 
   
   Let's see if I still know how to do it :)


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


> Template from snapshot not merging vhd files
> 
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0, 
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
>Reporter: Marcelo Lima
>Assignee: Rafael Weingärtner
>Priority: Critical
> Fix For: 4.11.0.0
>
>
> If we have two or more snapshots of a ROOT disk and try to create a template 
> from differencial snapshots, CloudStack not merging the vhd files on 
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage 
> correctly
> [root@acs01 6]# ls -l 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> 
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>  
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:17 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>   
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/ 
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:21 
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>  
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:30 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second 
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:34 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:35 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> We test on 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10. XenServer 6.5 with SP1 and 
> XenServer 6.5 with all patches.
> A workaround is create a volume (data-disk) from latest snapshot, create new 
> snapshot from data-disk and convert to template.



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

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

rafaelweingartner commented on issue #2402: [CLOUDSTACK-10128] Simplify the 
search for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402#issuecomment-366798899
 
 
   @mike-tutkowski thanks!
   I am getting used to look directly to the "reviweres" section on Github and 
checking the approved ones. I did not seen any for this PR, that is why I asked 
again.


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


> Template from snapshot not merging vhd files
> 
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0, 
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
>Reporter: Marcelo Lima
>Assignee: Rafael Weingärtner
>Priority: Critical
> Fix For: 4.11.0.0
>
>
> If we have two or more snapshots of a ROOT disk and try to create a template 
> from differencial snapshots, CloudStack not merging the vhd files on 
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage 
> correctly
> [root@acs01 6]# ls -l 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> 
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>  
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:17 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>   
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/ 
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:21 
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>  
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:30 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second 
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:34 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:35 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> We test on 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10. XenServer 6.5 with SP1 and 
> XenServer 6.5 with all patches.
> A workaround is create a volume (data-disk) from latest snapshot, create new 
> snapshot from data-disk and convert to template.



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

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

mike-tutkowski commented on issue #2402: [CLOUDSTACK-10128] Simplify the search 
for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402#issuecomment-366797995
 
 
   Yes, per my prior comments, the code LGTM and the two tests that previously 
failed now pass.


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


> Template from snapshot not merging vhd files
> 
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0, 
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
>Reporter: Marcelo Lima
>Assignee: Rafael Weingärtner
>Priority: Critical
> Fix For: 4.11.0.0
>
>
> If we have two or more snapshots of a ROOT disk and try to create a template 
> from differencial snapshots, CloudStack not merging the vhd files on 
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage 
> correctly
> [root@acs01 6]# ls -l 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> 
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>  
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:17 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>   
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/ 
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:21 
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>  
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:30 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second 
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:34 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:35 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> We test on 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10. XenServer 6.5 with SP1 and 
> XenServer 6.5 with all patches.
> A workaround is create a volume (data-disk) from latest snapshot, create new 
> snapshot from data-disk and convert to template.



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

[jira] [Commented] (CLOUDSTACK-10128) Template from snapshot not merging vhd files

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10128:
-

rafaelweingartner commented on issue #2402: [CLOUDSTACK-10128] Simplify the 
search for host to execute command
URL: https://github.com/apache/cloudstack/pull/2402#issuecomment-366796206
 
 
   reviewers (@DaanHoogland, @mike-tutkowski, @rhtyd ) what is your positions 
here? It seems that the tests passed and we have a consensus. If you are ok 
with this one, I would like to proceed and merge this to 4.11 and then forward 
to 4.12 (master branch)


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


> Template from snapshot not merging vhd files
> 
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0, 
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
>Reporter: Marcelo Lima
>Assignee: Rafael Weingärtner
>Priority: Critical
> Fix For: 4.11.0.0
>
>
> If we have two or more snapshots of a ROOT disk and try to create a template 
> from differencial snapshots, CloudStack not merging the vhd files on 
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage 
> correctly
> [root@acs01 6]# ls -l 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd 
> 
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>  
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:17 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum 
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>   
> 240e5e424552d44b5d297895b064beee  
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/ 
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov  1 12:12 
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:21 
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>  
> -rw-r--r-- 1 root root 1141019136 Nov  1 12:30 
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second 
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:34 
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd 
> -rw-r--r-- 1 root root 2843030016 Nov  1 12:35 
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> We test on 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10. XenServer 6.5 with SP1 and 
> XenServer 6.5 with all patches.
> A workaround is create a volume (data-disk) from latest snapshot, create new 
> snapshot from data-disk and convert to template.



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

[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10301:
-

rafaelweingartner opened a new pull request #2461: [CLOUDSTACK-10301] Allow 
updating the network ACL list name and Description
URL: https://github.com/apache/cloudstack/pull/2461
 
 
   Currently, it is not possible to update the Network ACL name or Description 
of an ACL after it has been created. It might be interesting to expose this 
option via API and to add this feature to the UI.


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


> Allow updating the network ACL list name and Description 
> -
>
> Key: CLOUDSTACK-10301
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> Currently, it is not possible to update the Network ACL name or Description 
> of an ACL after it has been created. It might be interesting to expose this 
> option via API and to add this feature to the UI.



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

[jira] [Created] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description

2018-02-19 Thread JIRA

Rafael Weingärtner created CLOUDSTACK-10301:
---

 Summary: Allow updating the network ACL list name and Description 
 Key: CLOUDSTACK-10301
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rafael Weingärtner
Assignee: Rafael Weingärtner


Currently, it is not possible to update the Network ACL name or Description of 
an ACL after it has been created. It might be interesting to expose this option 
via API and to add this feature to the UI.



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

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

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10268:
-

khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package 
script
URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-366770781
 
 
   @rafaelweingartner @DaanHoogland @rhtyd I updated the scripts and 
description of the PR again.
   Now when `--use-timestamp` is specified it will be applied 1) final name of 
the jar 2) final name of artifacts (rpm, deb) 3) ACS version itself


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


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



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

[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10054:
-

blueorangutan commented on issue #2244: CLOUDSTACK-10054:Volume download times 
out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#issuecomment-366733669
 
 
   Trillian test result (tid-2272)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 22954 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2244-t2272-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Smoke tests completed. 67 look OK, 0 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   


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


> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in 
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed 
> out in an hour. The volume is of 800GB and we should be able to increase the 
> timeout. Unfortunately there is not method to do that. There is no global 
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar 
> commands(commands taking long time)



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

[jira] [Updated] (CLOUDSTACK-10300) deployVirtualMachines fails with error when in Project mode

2018-02-19 Thread JIRA


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

René Moser updated CLOUDSTACK-10300:

Attachment: Selection_144.png

> deployVirtualMachines fails with error when in Project mode
> ---
>
> Key: CLOUDSTACK-10300
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10300
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Projects
>Affects Versions: 4.11.0.0
>Reporter: René Moser
>Priority: Blocker
> Attachments: Selection_144.png
>
>
> Deployment of a VM fails with
>  
> {{{"deployvirtualmachineresponse":{"uuidList":[],"errorcode":531,"cserrorcode":4365,"errortext":"There's}}{{
>  no way to confirm 
> Acct[b442701b-28d2-48ef-92ef-4f31250676b5-PrjAcct-STXT_TEST-1] has access to 
> org.apache}}{{.cloudstack.quota.vo.ServiceOfferingVO$$EnhancerByCGLIB$$ac9cd3cc@4d2f2827"
>  
>  
> {{Params:}}
>  
> |_|{{1519054700895}}|
> |command|{{deployVirtualMachine}}|
> |domainid|{{1}}|
> |hypervisor|{{VMware}}|
> |iptonetworklist[0].networ...|{{9a481cfb-381e-4c9a-83fa-85a42e85152c}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |response|{{json}}|
> |rootdisksize|{{40}}|
> |serviceofferingid|{{d115cf30-1d4c-4e25-86f4-4aee595db732}}|
> |templateid|{{7}}|
> |zoneid|{{c335aa1b-063a-4fe7-a8f2-f2d3bf42d6ce}}|
>  



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

[jira] [Updated] (CLOUDSTACK-10300) deployVirtualMachines fails with error when in Project mode

2018-02-19 Thread JIRA


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

René Moser updated CLOUDSTACK-10300:

Attachment: (was: Screenshot from 2018-02-19 16-37-39.png)

> deployVirtualMachines fails with error when in Project mode
> ---
>
> Key: CLOUDSTACK-10300
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10300
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Projects
>Affects Versions: 4.11.0.0
>Reporter: René Moser
>Priority: Blocker
>
> Deployment of a VM fails with
>  
> {{{"deployvirtualmachineresponse":{"uuidList":[],"errorcode":531,"cserrorcode":4365,"errortext":"There's}}{{
>  no way to confirm 
> Acct[b442701b-28d2-48ef-92ef-4f31250676b5-PrjAcct-STXT_TEST-1] has access to 
> org.apache}}{{.cloudstack.quota.vo.ServiceOfferingVO$$EnhancerByCGLIB$$ac9cd3cc@4d2f2827"
>  
>  
> {{Params:}}
>  
> |_|{{1519054700895}}|
> |command|{{deployVirtualMachine}}|
> |domainid|{{1}}|
> |hypervisor|{{VMware}}|
> |iptonetworklist[0].networ...|{{9a481cfb-381e-4c9a-83fa-85a42e85152c}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |response|{{json}}|
> |rootdisksize|{{40}}|
> |serviceofferingid|{{d115cf30-1d4c-4e25-86f4-4aee595db732}}|
> |templateid|{{7}}|
> |zoneid|{{c335aa1b-063a-4fe7-a8f2-f2d3bf42d6ce}}|
>  



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

[jira] [Updated] (CLOUDSTACK-10300) deployVirtualMachines fails with error when in Project mode

2018-02-19 Thread JIRA


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

René Moser updated CLOUDSTACK-10300:

Attachment: Screenshot from 2018-02-19 16-37-39.png

> deployVirtualMachines fails with error when in Project mode
> ---
>
> Key: CLOUDSTACK-10300
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10300
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Projects
>Affects Versions: 4.11.0.0
>Reporter: René Moser
>Priority: Blocker
>
> Deployment of a VM fails with
>  
> {{{"deployvirtualmachineresponse":{"uuidList":[],"errorcode":531,"cserrorcode":4365,"errortext":"There's}}{{
>  no way to confirm 
> Acct[b442701b-28d2-48ef-92ef-4f31250676b5-PrjAcct-STXT_TEST-1] has access to 
> org.apache}}{{.cloudstack.quota.vo.ServiceOfferingVO$$EnhancerByCGLIB$$ac9cd3cc@4d2f2827"
>  
>  
> {{Params:}}
>  
> |_|{{1519054700895}}|
> |command|{{deployVirtualMachine}}|
> |domainid|{{1}}|
> |hypervisor|{{VMware}}|
> |iptonetworklist[0].networ...|{{9a481cfb-381e-4c9a-83fa-85a42e85152c}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
> |response|{{json}}|
> |rootdisksize|{{40}}|
> |serviceofferingid|{{d115cf30-1d4c-4e25-86f4-4aee595db732}}|
> |templateid|{{7}}|
> |zoneid|{{c335aa1b-063a-4fe7-a8f2-f2d3bf42d6ce}}|
>  



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

[jira] [Created] (CLOUDSTACK-10300) deployVirtualMachines fails with error when in Project mode

2018-02-19 Thread JIRA

René Moser created CLOUDSTACK-10300:
---

 Summary: deployVirtualMachines fails with error when in Project 
mode
 Key: CLOUDSTACK-10300
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10300
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Projects
Affects Versions: 4.11.0.0
Reporter: René Moser


Deployment of a VM fails with
 
{{{"deployvirtualmachineresponse":{"uuidList":[],"errorcode":531,"cserrorcode":4365,"errortext":"There's}}{{
 no way to confirm 
Acct[b442701b-28d2-48ef-92ef-4f31250676b5-PrjAcct-STXT_TEST-1] has access to 
org.apache}}{{.cloudstack.quota.vo.ServiceOfferingVO$$EnhancerByCGLIB$$ac9cd3cc@4d2f2827"
 
 
{{Params:}}
 
|_|{{1519054700895}}|
|command|{{deployVirtualMachine}}|
|domainid|{{1}}|
|hypervisor|{{VMware}}|
|iptonetworklist[0].networ...|{{9a481cfb-381e-4c9a-83fa-85a42e85152c}}|
|projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
|projectid|{{da61b0ec-ee7f-4140-906b-e9874d3f1894}}|
|response|{{json}}|
|rootdisksize|{{40}}|
|serviceofferingid|{{d115cf30-1d4c-4e25-86f4-4aee595db732}}|
|templateid|{{7}}|
|zoneid|{{c335aa1b-063a-4fe7-a8f2-f2d3bf42d6ce}}|
 



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

[jira] [Closed] (CLOUDSTACK-9765) broken db.properties after upgrade

2018-02-19 Thread JIRA


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

René Moser closed CLOUDSTACK-9765.
--
   Resolution: Fixed
Fix Version/s: 4.9.3.0

> broken db.properties after upgrade
> --
>
> Key: CLOUDSTACK-9765
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9765
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.9.2.0
>Reporter: René Moser
>Assignee: René Moser
>Priority: Major
> Fix For: 4.9.3.0
>
>
> {code}
> shapeblue0.el6.x86_64 
>4/8 
>   Updating   : cloudstack-management-4.9.2.0-shapeblue0.el6.x86_64
>   
>   5/8 
> warning: /etc/cloudstack/management/db.properties created as 
> /etc/cloudstack/management/db.properties.rpmnew
> sed: can't read db.properties: No such file or directory
> Unable to determine ssl settings for server.xml, please run 
> cloudstack-setup-management manually
> Unable to determine ssl settings for tomcat.conf, please run 
> cloudstack-setup-management manually
> {code}
> Seeing this error while installing the RPM, resulting in cloudstack 
> management server is not able to connect to the DB after MS service start



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

[jira] [Created] (CLOUDSTACK-10299) Network listing return error in project mode

2018-02-19 Thread JIRA

René Moser created CLOUDSTACK-10299:
---

 Summary: Network listing return error in project mode
 Key: CLOUDSTACK-10299
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10299
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.11.0.0
Reporter: René Moser
 Attachments: Selection_142.png

{{Clicking the network button in a project returns the following error:}}
 
{{{"listremoteaccessvpnsresponse":{"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Account}}{{
 and projectId can't be specified together"



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

[jira] [Commented] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10298:
-

sgoeminn opened a new pull request #2460: CLOUDSTACK-10298: fix for recreation 
of an earlier deleted Nuage managed network
URL: https://github.com/apache/cloudstack/pull/2460
 
 
   CLOUDSTACK-10298: Recreation of an earlier deleted Nuage managed isolated or 
vpc tier network fails
   
   Added negative tests for feature vsd managed subnets
   Added fixes for reacreation of an earlier deleted Nuage managed network
   Updated Nuage Vsp CloudStack client to 1.0.8
   Co-authored by: Sigert Goeminne 
   
   https://issues.apache.org/jira/browse/CLOUDSTACK-10298


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


> Recreation of an earlier deleted Nuage managed isolated or vpc tier network 
> fails
> -
>
> Key: CLOUDSTACK-10298
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Raf Smeets
>Assignee: Sigert Goeminne
>Priority: Major
>
> Scenario to reproduce for isolated network: (same applies for vpc tier 
> network)
> Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent 
> NetworkOffering in ACS, then createNetwork by specifying externalID attribute 
> in the request, which refers to the Subnet ID in VSD.
> Then verify VSD objects and verify networking by deploying 2 VM's in this 
> network, enable static nat to one VM and ping to the other VM.
> After that delete tall the VM's in this network and delete the network itself.
> Don't delete data in VSD.
> Recreate same network by specifying same externalID attribute in the request, 
> which refers to the Subnet ID in VSD.
> management-server.log shows following error
> 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] 
> (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET 
> acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D
> 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 
> ctx-3d2464e6) (logid:13bd8add) CIDRs from which account 
> 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API 
> calls: 0.0.0.0/0,::/0
> 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to 
> Domain:1/ by AffinityGroupAccessChecker
> 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Checking if amount of resources of Type = 'network' for Account Name = 
> test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account 
> Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource 
> Amount = 1.
> 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network, the physical isolation type is not 
> BCF_SEGMENT
> 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6

[jira] [Assigned] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails

2018-02-19 Thread Sigert Goeminne (JIRA)


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

Sigert Goeminne reassigned CLOUDSTACK-10298:


Assignee: Sigert Goeminne

> Recreation of an earlier deleted Nuage managed isolated or vpc tier network 
> fails
> -
>
> Key: CLOUDSTACK-10298
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Raf Smeets
>Assignee: Sigert Goeminne
>Priority: Major
>
> Scenario to reproduce for isolated network: (same applies for vpc tier 
> network)
> Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent 
> NetworkOffering in ACS, then createNetwork by specifying externalID attribute 
> in the request, which refers to the Subnet ID in VSD.
> Then verify VSD objects and verify networking by deploying 2 VM's in this 
> network, enable static nat to one VM and ping to the other VM.
> After that delete tall the VM's in this network and delete the network itself.
> Don't delete data in VSD.
> Recreate same network by specifying same externalID attribute in the request, 
> which refers to the Subnet ID in VSD.
> management-server.log shows following error
> 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] 
> (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET 
> acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D
> 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 
> ctx-3d2464e6) (logid:13bd8add) CIDRs from which account 
> 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API 
> calls: 0.0.0.0/0,::/0
> 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to 
> Domain:1/ by AffinityGroupAccessChecker
> 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Checking if amount of resources of Type = 'network' for Account Name = 
> test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account 
> Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource 
> Amount = 1.
> 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network, the physical isolation type is not 
> BCF_SEGMENT
> 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP 
> not configured to be active
> 2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design network. VsdManaged network object already present in zone.
> 2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Releasing lock for 
> Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7]
> 2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by 
>

[jira] [Created] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails

2018-02-19 Thread Raf Smeets (JIRA)

Raf Smeets created CLOUDSTACK-10298:
---

 Summary: Recreation of an earlier deleted Nuage managed isolated 
or vpc tier network fails
 Key: CLOUDSTACK-10298
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.11.0.0
Reporter: Raf Smeets


Scenario to reproduce for isolated network: (same applies for vpc tier network)
Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent 
NetworkOffering in ACS, then createNetwork by specifying externalID attribute 
in the request, which refers to the Subnet ID in VSD.
Then verify VSD objects and verify networking by deploying 2 VM's in this 
network, enable static nat to one VM and ping to the other VM.
After that delete tall the VM's in this network and delete the network itself.
Don't delete data in VSD.
Recreate same network by specifying same externalID attribute in the request, 
which refers to the Subnet ID in VSD.

management-server.log shows following error
2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] (qtp66233253-20:ctx-a9727f69) 
(logid:13bd8add) ===START=== 10.30.39.11 - GET 
acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D
2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 
ctx-3d2464e6) (logid:13bd8add) CIDRs from which account 
'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API 
calls: 0.0.0.0/0,::/0
2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Access 
granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to Domain:1/ by 
AffinityGroupAccessChecker
2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Checking if amount of resources of Type = 'network' for Account Name = 
test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account 
Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource 
Amount = 1.
2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network, the physical isolation type is not BCF_SEGMENT
2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network
2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network
2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network
2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network
2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP 
not configured to be active
2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design this network
2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Refusing to design network. VsdManaged network object already present in zone.
2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Releasing lock for 
Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7]
2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] 
(qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by 
-TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-GeneratedMethodAccessor505.invoke:-1
2018-02-07 00:15:27,551 ERROR

[jira] [Resolved] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails

2018-02-19 Thread Sigert Goeminne (JIRA)


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

Sigert Goeminne resolved CLOUDSTACK-10298.
--
Resolution: Fixed

> Recreation of an earlier deleted Nuage managed isolated or vpc tier network 
> fails
> -
>
> Key: CLOUDSTACK-10298
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Raf Smeets
>Assignee: Sigert Goeminne
>Priority: Major
>
> Scenario to reproduce for isolated network: (same applies for vpc tier 
> network)
> Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent 
> NetworkOffering in ACS, then createNetwork by specifying externalID attribute 
> in the request, which refers to the Subnet ID in VSD.
> Then verify VSD objects and verify networking by deploying 2 VM's in this 
> network, enable static nat to one VM and ping to the other VM.
> After that delete tall the VM's in this network and delete the network itself.
> Don't delete data in VSD.
> Recreate same network by specifying same externalID attribute in the request, 
> which refers to the Subnet ID in VSD.
> management-server.log shows following error
> 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] 
> (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET 
> acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D
> 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 
> ctx-3d2464e6) (logid:13bd8add) CIDRs from which account 
> 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API 
> calls: 0.0.0.0/0,::/0
> 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to 
> Domain:1/ by AffinityGroupAccessChecker
> 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Checking if amount of resources of Type = 'network' for Account Name = 
> test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account 
> Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource 
> Amount = 1.
> 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network, the physical isolation type is not 
> BCF_SEGMENT
> 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP 
> not configured to be active
> 2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design this network
> 2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Refusing to design network. VsdManaged network object already present in zone.
> 2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Releasing lock for 
> Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7]
> 2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] 
> (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) 
> Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by 
>

[jira] [Closed] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password

2018-02-19 Thread Raf Smeets (JIRA)


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

Raf Smeets closed CLOUDSTACK-10245.
---

> ResetPassword for guestVm in nuage isolated networks is not working, unable 
> to login with new password
> --
>
> Key: CLOUDSTACK-10245
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.11.0.0, 4.12
>Reporter: Raf Smeets
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.11.0.0, 4.12
>
>
> ResetPassword functionality for guestVm's in Nuage isolated networks is not 
> working as password_server is not running on VirtualRouter. Unable to login 
> with new password.
> Scenario to reproduce:
>  # Execute ResetPassword on GuestVM
>  # Try to login with new password fails as passwordserver is not running on 
> port 8080 in VR.
> After some further debugging, found that this bug is introduced while fixing 
> CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409]
>  



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

[jira] [Closed] (CLOUDSTACK-10218) forced network update to a nuage network offering with vr fails with IllegalArgumentException

2018-02-19 Thread Raf Smeets (JIRA)


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

Raf Smeets closed CLOUDSTACK-10218.
---

> forced network update to a nuage network offering with vr fails with 
> IllegalArgumentException
> -
>
> Key: CLOUDSTACK-10218
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10218
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.11.0.0
> Environment: NuageVSP
>Reporter: Raf Smeets
>Assignee: Sigert Goeminne
>Priority: Major
> Attachments: configdrivemanagement-server.log
>
>
> a forced network update from a nuage network offering without vr to a nuage 
> network offering with vr fails with  java.lang.IllegalArgumentException
> Message: 'null' is not an IP string literal.
> It looks like this issue was introduced by recalculate broadcasturi 
> introduced by the network migration PR. Cause: 
> VspNetwork.getVirtualRouterIp() == "null" NuageVspElement:287
> Scenario to reproduce:
> update network id  networkofferingid  
> forced=true
> In failing test , existing network offering is one withoutVR, 
> newnetworkoffering is one with VR as DNS requires VR.
> The exception reported in cloudstack is : java.lang.IllegalArgumentException
> Message: 'null' is not an IP string literal.
> Full cloudstack management server logs are attached.



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

[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10295:
-

borisstoyanov commented on issue #2457: CLOUDSTACK-10295 Marvin: add support 
for password-enabled templates
URL: https://github.com/apache/cloudstack/pull/2457#issuecomment-366680629
 
 
   @dmytro-shevchenko ping


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


> Marvin: add support for password-enabled templates
> --
>
> Key: CLOUDSTACK-10295
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Reporter: Dmytro Shevchenko
>Priority: Major
>  Labels: marvin, password
>
> Currently when new VM created, password property always set to 'password' 
> even if it was auto-generated. Because of this impossible establish SSH 
> connection to host during testing.



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

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

nvazquez commented on issue #2456: [CLOUDSTACK-10293] Single view network ACL 
rules listing
URL: https://github.com/apache/cloudstack/pull/2456#issuecomment-366678807
 
 
   Thanks @rafaelweingartner! Now code LGTM


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


> Single view network ACL rules listing
> -
>
> Key: CLOUDSTACK-10293
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>
> The ACL rules editing/addition page is not user-friendly. Users are not able 
> to see in a single view all of the detail of the ACL rule (they need to use a 
> scroll bar on the horizontal). The problem becomes worse when there are a 
> considerable number of rules. Therefore, we are proposing the following 
> changes:
> # Instead of using the table to create new ACL, we can create a button like 
> the one presented in attached pictures, where users can click, and then a 
> modal popup would appear and users would be able to create the new ACL there. 
> This is similar to the workings of the ACL edit button.
> # Remove the ability to add new ACL via table where they are presented. All 
> ACLs should be entered via the “New ACL” button. Therefore, the section “Add 
> ACL” would be removed as well;
> # Move the action section of the list ACL table to the most left position;
>  
> These changes would reduce the information in the table and facilitate users 
> to add new rules and easily edit them as well.



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

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

nvazquez commented on a change in pull request #2456: [CLOUDSTACK-10293] Single 
view network ACL rules listing
URL: https://github.com/apache/cloudstack/pull/2456#discussion_r169060895
 
 

 ##
 File path: ui/scripts/vpc.js
 ##
 @@ -1333,35 +1321,65 @@
 $.ajax({
 url: 
createURL('listNetworkACLs=' + args.context.aclLists[0].id),
 success: function(json) {
-var items = 
json.listnetworkaclsresponse.networkacl.sort(function(a, b) {
-return a.number >= 
b.number;
-}).map(function(acl) {
-if 
(parseInt(acl.protocol)) { // protocol number
-acl.protocolnumber 
= acl.protocol;
-acl.protocol = 
"protocolnumber";
-}
-
-return acl;
-});
+var items = 
json.listnetworkaclsresponse.networkacl;
+
+if(items){
+items.sort(function(a, 
b) {
+return a.number >= 
b.number;
+}).map(function(acl) {
+if 
(parseInt(acl.protocol)) { // protocol number
+
acl.protocolnumber = acl.protocol;
+acl.protocol = 
"protocolnumber";
+}
+
+return acl;
+});
+}
 
 args.response.success({
 data: items
-/* {
-   cidrlist: '10.1.1.0/24',
-   protocol: 'TCP',
-   startport: 22, endport: 22,
-   networkid: 0,
-   traffictype: 'Egress'
-   },
-   {
-   cidrlist: '10.2.1.0/24',
-   protocol: 'UDP',
-   startport: 56, endport: 72,
-   networkid: 0,
-   trafficType: 'Ingress'
-   }
-   ]*/
 });
+
if(jQuery('#details-tab-aclRules').siblings('div.toolbar').children('div.add').size()
 === 0){
+var 
$addAclRuleDivButton = jQuery('').addClass('button add');
+var 
$spanAddAclRuleButtonMessage = jQuery('').html(_l('label.add.ACL'));
+
+
$addAclRuleDivButton.html($spanAddAclRuleButtonMessage);
+
$addAclRuleDivButton.click(function(){
+   
cloudStack.dialog.createForm({
+form: {
+ title: 
'label.add.rule',
+ desc: 
'Create a new ACL rule',
+ fields: 
aclRuleFields
+ },
+ after: 
function(argsLocal) {
+var 
data = argsLocal.data;
+
data.aclid =

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

rafaelweingartner commented on issue #2456: [CLOUDSTACK-10293] Single view 
network ACL rules listing
URL: https://github.com/apache/cloudstack/pull/2456#issuecomment-366658774
 
 
   Thanks for your review @nvazquez !
   I have made the changes you suggested.


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


> Single view network ACL rules listing
> -
>
> Key: CLOUDSTACK-10293
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>
> The ACL rules editing/addition page is not user-friendly. Users are not able 
> to see in a single view all of the detail of the ACL rule (they need to use a 
> scroll bar on the horizontal). The problem becomes worse when there are a 
> considerable number of rules. Therefore, we are proposing the following 
> changes:
> # Instead of using the table to create new ACL, we can create a button like 
> the one presented in attached pictures, where users can click, and then a 
> modal popup would appear and users would be able to create the new ACL there. 
> This is similar to the workings of the ACL edit button.
> # Remove the ability to add new ACL via table where they are presented. All 
> ACLs should be entered via the “New ACL” button. Therefore, the section “Add 
> ACL” would be removed as well;
> # Move the action section of the list ACL table to the most left position;
>  
> These changes would reduce the information in the table and facilitate users 
> to add new rules and easily edit them as well.



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

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

rafaelweingartner commented on a change in pull request #2456: 
[CLOUDSTACK-10293] Single view network ACL rules listing
URL: https://github.com/apache/cloudstack/pull/2456#discussion_r169045024
 
 

 ##
 File path: ui/scripts/vpc.js
 ##
 @@ -436,6 +401,38 @@
 isOptional: true,
 isEditable: true
 },
+'icmptype': {
+edit: true,
+label: 'ICMP.type',
+desc: 'Please specify -1 if you want to allow all ICMP types',
 
 Review comment:
   Done


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


> Single view network ACL rules listing
> -
>
> Key: CLOUDSTACK-10293
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
> Fix For: 4.12
>
>
> The ACL rules editing/addition page is not user-friendly. Users are not able 
> to see in a single view all of the detail of the ACL rule (they need to use a 
> scroll bar on the horizontal). The problem becomes worse when there are a 
> considerable number of rules. Therefore, we are proposing the following 
> changes:
> # Instead of using the table to create new ACL, we can create a button like 
> the one presented in attached pictures, where users can click, and then a 
> modal popup would appear and users would be able to create the new ACL there. 
> This is similar to the workings of the ACL edit button.
> # Remove the ability to add new ACL via table where they are presented. All 
> ACLs should be entered via the “New ACL” button. Therefore, the section “Add 
> ACL” would be removed as well;
> # Move the action section of the list ACL table to the most left position;
>  
> These changes would reduce the information in the table and facilitate users 
> to add new rules and easily edit them as well.



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

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

rafaelweingartner commented on a change in pull request #2456: 
[CLOUDSTACK-10293] Single view network ACL rules listing
URL: https://github.com/apache/cloudstack/pull/2456#discussion_r169043241
 
 

 ##
 File path: ui/scripts/vpc.js
 ##
 @@ -1333,35 +1321,65 @@
 $.ajax({
 url: 
createURL('listNetworkACLs=' + args.context.aclLists[0].id),
 success: function(json) {
-var items = 
json.listnetworkaclsresponse.networkacl.sort(function(a, b) {
-return a.number >= 
b.number;
-}).map(function(acl) {
-if 
(parseInt(acl.protocol)) { // protocol number
-acl.protocolnumber 
= acl.protocol;
-acl.protocol = 
"protocolnumber";
-}
-
-return acl;
-});
+var items = 
json.listnetworkaclsresponse.networkacl;
+
+if(items){
+items.sort(function(a, 
b) {
+return a.number >= 
b.number;
+}).map(function(acl) {
+if 
(parseInt(acl.protocol)) { // protocol number
+
acl.protocolnumber = acl.protocol;
+acl.protocol = 
"protocolnumber";
+}
+
+return acl;
+});
+}
 
 args.response.success({
 data: items
-/* {
-   cidrlist: '10.1.1.0/24',
-   protocol: 'TCP',
-   startport: 22, endport: 22,
-   networkid: 0,
-   traffictype: 'Egress'
-   },
-   {
-   cidrlist: '10.2.1.0/24',
-   protocol: 'UDP',
-   startport: 56, endport: 72,
-   networkid: 0,
-   trafficType: 'Ingress'
-   }
-   ]*/
 });
+
if(jQuery('#details-tab-aclRules').siblings('div.toolbar').children('div.add').size()
 === 0){
+var 
$addAclRuleDivButton = jQuery('').addClass('button add');
+var 
$spanAddAclRuleButtonMessage = jQuery('').html(_l('label.add.ACL'));
+
+
$addAclRuleDivButton.html($spanAddAclRuleButtonMessage);
+
$addAclRuleDivButton.click(function(){
+   
cloudStack.dialog.createForm({
+form: {
+ title: 
'label.add.rule',
+ desc: 
'Create a new ACL rule',
 
 Review comment:
   Sure, I was maintaining everything as before, but why not improve this one 
as well.
   I will do that in a sec.


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


>

[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10293:
-

rafaelweingartner commented on a change in pull request #2456: 
[CLOUDSTACK-10293] Single view network ACL rules listing
URL: https://github.com/apache/cloudstack/pull/2456#discussion_r169043024
 
 

 ##
 File path: ui/scripts/vpc.js
 ##
 @@ -1333,35 +1321,65 @@
 $.ajax({
 url: 
createURL('listNetworkACLs=' + args.context.aclLists[0].id),
 success: function(json) {
-var items = 
json.listnetworkaclsresponse.networkacl.sort(function(a, b) {
-return a.number >= 
b.number;
-}).map(function(acl) {
-if 
(parseInt(acl.protocol)) { // protocol number
-acl.protocolnumber 
= acl.protocol;
-acl.protocol = 
"protocolnumber";
-}
-
-return acl;
-});
+var items = 
json.listnetworkaclsresponse.networkacl;
+
+if(items){
+items.sort(function(a, 
b) {
+return a.number >= 
b.number;
+}).map(function(acl) {
+if 
(parseInt(acl.protocol)) { // protocol number
+
acl.protocolnumber = acl.protocol;
+acl.protocol = 
"protocolnumber";
+}
+
+return acl;
+});
+}
 
 args.response.success({
 data: items
-/* {
-   cidrlist: '10.1.1.0/24',
-   protocol: 'TCP',
-   startport: 22, endport: 22,
-   networkid: 0,
-   traffictype: 'Egress'
-   },
-   {
-   cidrlist: '10.2.1.0/24',
-   protocol: 'UDP',
-   startport: 56, endport: 72,
-   networkid: 0,
-   trafficType: 'Ingress'
-   }
-   ]*/
 });
+
if(jQuery('#details-tab-aclRules').siblings('div.toolbar').children('div.add').size()
 === 0){
+var 
$addAclRuleDivButton = jQuery('').addClass('button add');
+var 
$spanAddAclRuleButtonMessage = jQuery('').html(_l('label.add.ACL'));
+
+
$addAclRuleDivButton.html($spanAddAclRuleButtonMessage);
+
$addAclRuleDivButton.click(function(){
+   
cloudStack.dialog.createForm({
+form: {
+ title: 
'label.add.rule',
+ desc: 
'Create a new ACL rule',
+ fields: 
aclRuleFields
+ },
+ after: 
function(argsLocal) {
+var 
data = argsLocal.data;
+
data.aclid =

[jira] [Commented] (CLOUDSTACK-9777) decouple cloudstack UI

2018-02-19 Thread Suthagar Kailayapathy (JIRA)


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

Suthagar Kailayapathy commented on CLOUDSTACK-9777:
---

Hi, 
I am Suthagar, final year undergraduate at Department of Computer Science and 
Engineering, University of Moratuwa, Sri Lanka. I would like to work on this 
project to divide the Cloud Stack UI as a separate project through this year 
GSoC. I went through the comments in this discussions and had a look at the 
code as well. First, let me set up the required environment for the 
development. It would be kind enough If you guide me to get understand this 
project from the beginning.

Thanks.

> decouple cloudstack UI
> --
>
> Key: CLOUDSTACK-9777
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9777
> Project: CloudStack
>  Issue Type: Wish
>Reporter: Rajani Karuturi
>Priority: Major
>  Labels: gsoc2018
>
> just like cloudmonkey, decouple cloudstack UI to a separate project.
> It should be able to talk to any cloudstack endpoint 



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

[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10240:
-

blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a 
local volume to shared storage
URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-366636864
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1726


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


> ACS cannot migrate a volume from local to shared storage (for XenServer)
> 
>
> Key: CLOUDSTACK-10240
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> CloudStack is logically restricting the migration of local storages to shared 
> storage and vice versa. This restriction is a logical one and can be removed 
> for XenServer deployments. Therefore, we will enable migration of volumes 
> between local-shared storages in XenServers independently of their service 
> offering. This will work as an override mechanism to the disk offering used 
> by volumes. If administrators want to migrate local volumes to a shared 
> storage, they should be able to do so (the hypervisor already allows that). 
> The same the other way around.



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

[jira] [Commented] (CLOUDSTACK-10297) Provide a way to override VMware guest VM's hardware version using vm details

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10297:
-

DaanHoogland commented on issue #2459: CLOUDSTACK-10297: Isolation network 
defined subnet mask failure
URL: https://github.com/apache/cloudstack/pull/2459#issuecomment-366628055
 
 
   this is not to go in, it is not based on the right version and takes in 
loads of unwanted stuff in its slur.


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


> Provide a way to override VMware guest VM's hardware version using vm details
> -
>
> Key: CLOUDSTACK-10297
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10297
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Priority: Major
> Fix For: Future
>
>
> Currently, CloudStack provide any mechanism to override hardware version 
> (virtualHW.version) of a VMware VM using the user vm's details. A vm's config 
> can add this details to extraConfig which will make its way to the vmx file. 
> This can allow running VMs with explicit hardware version that may be 
> compatible with say two version of esxis hosts in a mixed vmware env. 



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

[jira] [Commented] (CLOUDSTACK-10297) Provide a way to override VMware guest VM's hardware version using vm details

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10297:
-

DaanHoogland closed pull request #2459: CLOUDSTACK-10297: Isolation network 
defined subnet mask failure
URL: https://github.com/apache/cloudstack/pull/2459
 
 
   


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


> Provide a way to override VMware guest VM's hardware version using vm details
> -
>
> Key: CLOUDSTACK-10297
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10297
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Priority: Major
> Fix For: Future
>
>
> Currently, CloudStack provide any mechanism to override hardware version 
> (virtualHW.version) of a VMware VM using the user vm's details. A vm's config 
> can add this details to extraConfig which will make its way to the vmx file. 
> This can allow running VMs with explicit hardware version that may be 
> compatible with say two version of esxis hosts in a mixed vmware env. 



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

[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10240:
-

blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a 
local volume to shared storage
URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-366627862
 
 
   @DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


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


> ACS cannot migrate a volume from local to shared storage (for XenServer)
> 
>
> Key: CLOUDSTACK-10240
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> CloudStack is logically restricting the migration of local storages to shared 
> storage and vice versa. This restriction is a logical one and can be removed 
> for XenServer deployments. Therefore, we will enable migration of volumes 
> between local-shared storages in XenServers independently of their service 
> offering. This will work as an override mechanism to the disk offering used 
> by volumes. If administrators want to migrate local volumes to a shared 
> storage, they should be able to do so (the hypervisor already allows that). 
> The same the other way around.



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

[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10240:
-

DaanHoogland commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a 
local volume to shared storage
URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-366627617
 
 
   @blueorangutan package


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


> ACS cannot migrate a volume from local to shared storage (for XenServer)
> 
>
> Key: CLOUDSTACK-10240
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> CloudStack is logically restricting the migration of local storages to shared 
> storage and vice versa. This restriction is a logical one and can be removed 
> for XenServer deployments. Therefore, we will enable migration of volumes 
> between local-shared storages in XenServers independently of their service 
> offering. This will work as an override mechanism to the disk offering used 
> by volumes. If administrators want to migrate local volumes to a shared 
> storage, they should be able to do so (the hypervisor already allows that). 
> The same the other way around.



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

[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10054:
-

blueorangutan commented on issue #2244: CLOUDSTACK-10054:Volume download times 
out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#issuecomment-366626935
 
 
   @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


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


> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in 
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed 
> out in an hour. The volume is of 800GB and we should be able to increase the 
> timeout. Unfortunately there is not method to do that. There is no global 
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar 
> commands(commands taking long time)



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

[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds

2018-02-19 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-10054:
-

DaanHoogland commented on issue #2244: CLOUDSTACK-10054:Volume download times 
out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#issuecomment-366626731
 
 
   @rhtyd can you see if your objections are addressed?
   @mrunalinikankariya can you look at the output for 
test_hostha_enable_ha_when_host_in_maintenance? it seems to be a consistent 
error.
   @blueorangutan test


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


> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in 
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed 
> out in an hour. The volume is of 800GB and we should be able to increase the 
> timeout. Unfortunately there is not method to do that. There is no global 
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar 
> commands(commands taking long time)



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

39 matches

Mail list logo