[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035479#comment-15035479 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161223389 @ustcweizhou @bhaisaab @wido Did you actually test this PR? Cheers, Wilder > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035484#comment-15035484 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161224861 @wilderrodrigues no, just code review > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035490#comment-15035490 ] ASF GitHub Bot commented on CLOUDSTACK-9051: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1086#issuecomment-161226000 @ustcweizhou @DaanHoogland I was on holidays last week... just got back to the PR-Pool. I saw that @DaanHoogland already tested, so I will do a code review and give my vote depending on the outcome. Talk to you later. Cheers, Wilder > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035515#comment-15035515
]
ASF GitHub Bot commented on CLOUDSTACK-9074:
Github user miguelaferreira commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1094#discussion_r46391389
--- Diff:
plugins/network-elements/nicira-nvp/src/main/java/com/cloud/network/element/NiciraNvpElement.java
---
@@ -239,8 +244,51 @@ public boolean implement(Network network,
NetworkOffering offering, DeployDestin
* multiple operations that should be done only once.
*/
-// Implement SourceNat immediately as we have al the info already
-if
(networkModel.isProviderSupportServiceInNetwork(network.getId(),
Service.SourceNat, Provider.NiciraNvp)) {
+if (network.getGuestType().equals(GuestType.Shared)){
--- End diff --
Yes! Much better. Thanks!
> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.7.0
>Reporter: Nicolas Vazquez
> Fix For: 4.7.0
>
>
> h3. Introduction
> Currently NiciraNVP plugin supports only Isolated networking. In this mode of
> operations networks are assigned to individual Cloudstack accounts and on NSX
> side are completely isolated on the L3 level. Many use cases especially in
> corporate environment call for shared networking mode support. In some
> circumstances there also may be a need to translate shared NSX network over
> to a physical VLAN via L2 NSX gateway.
> Features that will be introduced to support Cloudstack shared networks in two
> modes of NiciraNVP plugin:
> * Shared networks mapped to a physical VLAN with L2 NSX gateway
> * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will
> be supported.
> h3. Features
> h4. 1) Shared networking model support
> # Support native Cloudstack shared network in NiciraNVP plugin.
> # Current code that implements isolated networking mode support will stay
> intact.
> # Designate network service offering by configuring VirtualNetworking
> provider with NiciraNVP.
> # Static/Source NAT is not used and ignored if defined in the network
> offering.
> # Nicira_vvp_router_map table will support non-unique logical routers to
> implement L3 NSX routing domains where multiple Cloudstack networks are
> attached to the same logical router.
> # Shared network with NSX based Virtual networking will go through the
> following states:
> ## Allocated
> ## Implementing
> ## Implemented
> ## Destroy
> h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network
> # Optional L2gatewayserviceuuid parameter for NiciraNVP controller
> # VLAN ID of a Shared network represents VLAN to pass through L2 gateway
> similar to native Cloudstack shared networking
> # NSX workflow for network allocation
> ## Check if l2gatewayservice defined
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_doamin
> ### Vlan://vlan_id as broadcast_uri
> ## Create record in VLAN table
> # NSX workflow for network implementation
> ## Check if l2gatewayservice defined and valid
> ## Create logical switch
> ## Map logical switch to L2gateway service assigning shared network VLAN ID
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 3) Support NSX L3 multiple routing domains
> # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a
> particular routing domain. We will support UUID style notation for VLAN ID.
> l3gatewayservice option is not used in shared networking
> # It is assumed that if connectivity to the physical networking is required
> then logical router is configured and connected to the physical network in
> advance. NiciraNVP plugin will not perform any task beyond basic connectivity
> to the logical router
> # Support NSX L3 multiple routing domains
> # NSX workflow for network allocation
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_domain
> ### NULL as broadcast_uri
> ## Create record in VLAN table
> ## Create record in nicira_nvp_router_map table
> # NSX workflow for network implementation
> ## Check if logical router exists on NSX side which UUID matches the one
> defined during shared network creation. This mode is activated if VLAN ID
> supplied in UUID style notation
> ## Create logical switch
> ## Attach logical switch to the logical router
> ## Assign
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035533#comment-15035533
]
ASF GitHub Bot commented on CLOUDSTACK-9074:
Github user miguelaferreira commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1094#discussion_r46392407
--- Diff:
plugins/network-elements/nicira-nvp/src/main/java/com/cloud/network/resource/wrapper/NiciraNvpConfigureSharedNetworkUuidCommandWrapper.java
---
@@ -0,0 +1,110 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.network.resource.wrapper;
+
+import static com.cloud.network.resource.NiciraNvpResource.NAME_MAX_LEN;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import org.apache.log4j.Logger;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.ConfigureSharedNetworkUuidAnswer;
+import com.cloud.agent.api.ConfigureSharedNetworkUuidCommand;
+import com.cloud.network.nicira.LogicalRouterPort;
+import com.cloud.network.nicira.LogicalSwitchPort;
+import com.cloud.network.nicira.NiciraNvpApi;
+import com.cloud.network.nicira.NiciraNvpApiException;
+import com.cloud.network.nicira.NiciraNvpTag;
+import com.cloud.network.nicira.PatchAttachment;
+import com.cloud.network.resource.NiciraNvpResource;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+
+@ResourceWrapper(handles = ConfigureSharedNetworkUuidCommand.class)
+public final class NiciraNvpConfigureSharedNetworkUuidCommandWrapper
extends CommandWrapper{
+
+private static final Logger s_logger =
Logger.getLogger(NiciraNvpConfigureSharedNetworkUuidCommandWrapper.class);
+
+@Override
+public Answer execute(ConfigureSharedNetworkUuidCommand command,
NiciraNvpResource niciraNvpResource) {
+final String logicalRouterUuid = command.getLogicalRouterUuid();
+final String logicalSwitchUuid = command.getLogicalSwitchUuid();
+final String portIpAddress = command.getPortIpAddress();
+final List tags = new ArrayList();
+tags.add(new NiciraNvpTag("cs_account", command.getOwnerName()));
+final long networkId = command.getNetworkId();
+
+final NiciraNvpApi niciraNvpApi =
niciraNvpResource.getNiciraNvpApi();
+
+s_logger.debug("Attaching Logical Switch " + logicalSwitchUuid + "
on Logical Router " + logicalRouterUuid + " for Shared Network" + networkId);
+
+//Stored for rollback
+LogicalRouterPort lrpi = null;
+LogicalSwitchPort lsp = null;
+try {
+// Create the inside port for the router
+lrpi = new LogicalRouterPort();
+lrpi.setAdminStatusEnabled(true);
+lrpi.setDisplayName(niciraNvpResource.truncate(networkId +
"-shared-att-port", NAME_MAX_LEN));
+lrpi.setTags(tags);
+final List ipAddresses = new ArrayList();
+ipAddresses.add(portIpAddress);
+lrpi.setIpAddresses(ipAddresses);
+lrpi = niciraNvpApi.createLogicalRouterPort(logicalRouterUuid,
lrpi);
+
+try {
+// Create the inside port on the lswitch
+lsp = new
LogicalSwitchPort(niciraNvpResource.truncate(networkId + "-shared-att-port",
NAME_MAX_LEN), tags, true);
+lsp =
niciraNvpApi.createLogicalSwitchPort(logicalSwitchUuid, lsp);
+
+// Attach the inside router port to the lswitch port with
a PatchAttachment
+
niciraNvpApi.updateLogicalRouterPortAttachment(logicalRouterUuid,
lrpi.getUuid(), new PatchAttachment(lsp.getUuid()));
+
+// Attach the inside lswitch port to the router with a
PatchAttachment
+
niciraNvpApi.updateLogicalSwitchPortAttachment(logicalSwitchUuid,
lsp.getUuid(), new Patc
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035543#comment-15035543 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user miguelaferreira commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-161235643 @nvazquez I have one more request for you, and (if you agree, of course) that should be the end of it on a code level. With the marvin test then this would be ready for 4.7, but be aware that feature freeze is planned for December 7, so we need to work fast. However, if we do not make that deadline we can always include this feature in 4.8 (as you have probably seen, we are releaseing more often these days :smile:) I have to say I've never really liked reviewing code for other people, but it has been a pleasure to do it with you :+1:. > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX w
[jira] [Commented] (CLOUDSTACK-9055) NPE in update Redundant State of VPC networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035565#comment-15035565
]
ASF GitHub Bot commented on CLOUDSTACK-9055:
Github user ustcweizhou commented on the pull request:
https://github.com/apache/cloudstack/pull/1073#issuecomment-161242475
today one of my nodes was rebooted unexpectedly, I got the same error
2015-12-02 09:59:53,224 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(RedundantRouterStatusMonitor-9:ctx-417ced5f) Fail to complete the
RvRStatusUpdateTask!
java.lang.NullPointerException
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateRoutersRedundantState(VirtualNetworkApplianceManagerImpl.java:1019)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl$RvRStatusUpdateTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1201)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
> NPE in update Redundant State of VPC networks
> -
>
> Key: CLOUDSTACK-9055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9055
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> 2015-11-11 08:32:48,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 4 routers to update status.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 1 VPC networks to update Redundant
> State.
> 2015-11-11 08:32:48,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-ee477aaa) Found 0 networks to update RvR status.
> 2015-11-11 08:32:48,705 DEBUG [c.c.a.t.Request]
> (RedundantRouterStatusMonitor-7:ctx-195132c6) Seq 22-1391893759834266981:
> Sending { Cmd , MgmtId: 345051313197, via: 22(node12), Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":{"accessDetails":{"router.name":"r-7548-VM","router.ip":"169.254.2.52"},"wait":30}}]
> }
> 2015-11-11 08:32:58,451 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) Begin cleanup expired async-jobs
> 2015-11-11 08:32:58,455 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-f907d806) End cleanup expired async-jobs
> 2015-11-11 08:33:06,370 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-ab0d6092) Zone 1 is ready to launch console proxy
> 2015-11-11 08:33:06,435 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-2b4d78f6) Zone 1 is ready to launch secondary storage VM
> 2015-11-11 08:33:08,451 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) Begin cleanup expired async-jobs
> 2015-11-11 08:33:08,455 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-a8a81c83) End cleanup expired async-jobs
> 2015-11-11 08:33:15,441 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-6:ctx-bba99e59) HostStatsCollector is running...
> 2015-11-11 08:33:17,649 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-c64bf7b6) AutoScaling Monitor is running...
> 2015-11-11 08:33:18,451 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) Begin cleanup expired async-jobs
> 2015-11-11 08:33:18,455 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-73c3e11b) End cleanup expired async-jobs
> 2015-11-11 08:33:18,660 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 4 routers to update status.
> 2015-11-11 08:33:18,663 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 1 VPC networks to update Redundant
> State.
> 2015-11-11 08:33:18,664 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-25d2c01c) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,673 DEBUG [c.c.a.t.Request]
> (Redun
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035572#comment-15035572 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161243997 @wilderrodrigues I just tested. I set the storage.cleanup.interval to 60s, the storage.cleanup.delay to 120s. I restored a VM, then the old volume of the vm will be in 'Destroy' state ``` mysql> select id,name,uuid,created,updated,removed,state from volumes where id=7574\G *** 1. row *** id: 7574 name: ROOT-7558 uuid: 82c5991d-5211-4fd8-bd8b-f1285cc50574 created: 2015-11-30 08:27:36 updated: 2015-12-02 09:50:34 removed: NULL state: Destroy 1 row in set (0.00 sec) ``` The volume is expunged after 2-3 minutes. ``` mysql> select id,name,uuid,created,updated,removed,state from volumes where id=7574\G *** 1. row *** id: 7574 name: ROOT-7558 uuid: 82c5991d-5211-4fd8-bd8b-f1285cc50574 created: 2015-11-30 08:27:36 updated: 2015-12-02 09:53:31 removed: 2015-12-02 09:53:31 state: Expunged 1 row in set (0.00 sec) ``` > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035593#comment-15035593 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161249455 @remibergsma @wilderrodrigues checked the code (java and test_vm_life_cycle.py), I think this PR is not related to the failure in integration test. Can you please run testing again? > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035601#comment-15035601 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161250671 test/integration/component/test_browse_volumes.py this test might be impacted. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035626#comment-15035626 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/1082#issuecomment-161256224 I checked in Internet Explorer and Chromium browser also. It is working fine. > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8968) UI icon over VM snapshot to deploy user instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035641#comment-15035641 ] ASF GitHub Bot commented on CLOUDSTACK-8968: GitHub user nitin-maharana opened a pull request: https://github.com/apache/cloudstack/pull/1150 CLOUDSTACK-8968: UI icon over VM snapshot to deploy user instance Added a new Icon in Instance page to launch the VM from the snapshot. A new icon over VM snapshot object, which upon invoked will open a deploy user instance wizard, where there is no choice to choose zone and ISO or template to deploy the user instance from. 1) A new icon to indicate deploy user instance from VM snapshot 2) The new icon is placed as an operation over each VM snapshot object. 3) Clicking this icon will show the wizard to deploy user instance, which is same as wizard for normal user instance except that zone selection page and ISO/template selection page would not be present in this wizard. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nitin-maharana/CloudStack CloudStack-Nitin12 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1150.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1150 commit 0fddcc663e201edaff7ed80eb09cf2e1197ae08c Author: Nitin Kumar Maharana Date: 2015-10-19T19:07:56Z CLOUDSTACK-8968: UI icon over VM snapshot to deploy user instance Added a new Icon in Instance page to launch the VM from the snapshot. > UI icon over VM snapshot to deploy user instance > > > Key: CLOUDSTACK-8968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8968 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > A new icon over VM snapshot object, which upon invoked will open a deploy > user instance wizard, where there is no choice to choose zone and ISO or > template to deploy the user instance from. > 1) A new icon to indicate deploy user instance from VM snapshot > 2) The new icon is placed as an operation over each VM snapshot object. > 3) Clicking this icon will show the wizard to deploy user instance, which is > same as wizard for normal user instance except that zone selection page and > ISO/template selection page would not be present in this wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8968) UI icon over VM snapshot to deploy user instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035647#comment-15035647 ] ASF GitHub Bot commented on CLOUDSTACK-8968: Github user nitin-maharana closed the pull request at: https://github.com/apache/cloudstack/pull/953 > UI icon over VM snapshot to deploy user instance > > > Key: CLOUDSTACK-8968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8968 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > A new icon over VM snapshot object, which upon invoked will open a deploy > user instance wizard, where there is no choice to choose zone and ISO or > template to deploy the user instance from. > 1) A new icon to indicate deploy user instance from VM snapshot > 2) The new icon is placed as an operation over each VM snapshot object. > 3) Clicking this icon will show the wizard to deploy user instance, which is > same as wizard for normal user instance except that zone selection page and > ISO/template selection page would not be present in this wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8968) UI icon over VM snapshot to deploy user instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035646#comment-15035646 ] ASF GitHub Bot commented on CLOUDSTACK-8968: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/953#issuecomment-161262674 Made a pull request to merge in 4.6. So closing this PR. Thanks. > UI icon over VM snapshot to deploy user instance > > > Key: CLOUDSTACK-8968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8968 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > A new icon over VM snapshot object, which upon invoked will open a deploy > user instance wizard, where there is no choice to choose zone and ISO or > template to deploy the user instance from. > 1) A new icon to indicate deploy user instance from VM snapshot > 2) The new icon is placed as an operation over each VM snapshot object. > 3) Clicking this icon will show the wizard to deploy user instance, which is > same as wizard for normal user instance except that zone selection page and > ISO/template selection page would not be present in this wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035652#comment-15035652 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user nitin-maharana closed the pull request at: https://github.com/apache/cloudstack/pull/1077 > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035651#comment-15035651 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/1077#issuecomment-161263377 Closing this PR. As #1082 is there to merge in 4.6. Thanks. > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035664#comment-15035664 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161266056 @remibergsma @DaanHoogland @wido @bhaisaab @ustcweizhou @karuturi @runseb @borisroman @jburwell If test_vm_life_cycle.py is failing because the current 4.6 and/or master is broken/unstable, we have to get it working again before any other PR gets merged. We cannot, for any imaginable reason, get into the situation we were at few months ago. I will run tests against current 4.6 branch and Master to see if that's actually broken. Who can help me on testing as well? Cheers, Wilder > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035691#comment-15035691 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161270573 @wilderrodrigues I'm approaching EOD today, but can help test master tomorrow. I tested vm lifecycle manually with 4.6.1 RC1 and KVM, so I suppose 4.6 should be stable. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035695#comment-15035695 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161272059 Thanks, @bhaisaab! I will test it and and also see if I have time tomorrow to run the same tests agains this PR. We need to be 100% sure that it works on both branches and with this PR. Cheers, Wilder > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035705#comment-15035705 ] ASF GitHub Bot commented on CLOUDSTACK-9075: GitHub user wilderrodrigues opened a pull request: https://github.com/apache/cloudstack/pull/1151 [4.6] CLOUDSTACK-9075 - As a Developer I want the Private GW feature fixed on single VPCs This PR fixes the issue we faced with Private Gateways on single VPC when using ACS 4.6.0 and onwards. The root cause: during the VR refactor, the static routes configuration was left unimplemented. This PR also improves the existing Replace ACL test and adds a new test, that cover the Private Gateway in a more complete way. The new test does the following: 1. Create 2 VPCs 2. Create 2 Tiers - 1 per VPC 3. Deploy 2 VMs - 1 per Tier 4. Acquire 2 pub IPs - 1 per VPC 5. Create 2 PF rules - 1 per pub IP 6. Create 2 ACLs + rules - 1 per VPC 7. Assign new ACLs to Tiers 8. Create 2 Private GWs - 1 per VPC 9. Replace the Pvt GWs ACLs 10. Create 2 Static routes - 1 per Pvt GW 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) There is also a test for Private Gateways on Redundant VPCs. But I found out that the feature is broken in when used with rVPCs. It will be addressed in a separate Issue/PR. I'm running the tests. Will post results as soon as they are ready. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ekholabs/cloudstack fix/private_gw_rVPC-CLOUDSTACK-9075 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1151.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1151 commit 4ea4e7e687527cc8c06489d4deaedf4ed1c3c91c Author: Wilder Rodrigues Date: 2015-11-19T11:03:32Z CLOUDSTACK-9075 - Add method to get list of Physical Networks per zone commit 3e02b8999bb7f1f79d99b32955c842fbda4d29a9 Author: Wilder Rodrigues Date: 2015-11-19T11:04:01Z CLOUDSTACK-9075 - Covers Private GW ACL with Redundant VPCs commit a17fa48de1cfa4f0f4425f90b0f435d6cf8e6540 Author: Wilder Rodrigues Date: 2015-11-19T11:28:32Z CLOUDSTACK-9075 - Adds VPC static routes test - Adds redundant VPC tests - Adds support to Static Routes on VPC private gatways - Removes the route configuration in case static route is deleted. commit 6d9a3d82f9b617d40d0ee1472bef87cb630595d6 Author: Wilder Rodrigues Date: 2015-12-02T06:30:06Z CLOUDSTACK-9075 - Uses the same vlan since it should have been already released - After the first test is done, the clean up will delete the whole VPC, also releasing the VLAN that was in use. > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035709#comment-15035709 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161274671 Ping @remibergsma @DaanHoogland @borisroman You can start testing now... just a matter of running the following: ``` cd test/integration nosetests --with-marvin --marvin-config=[your configuration here]-s -a tags=advanced,required_hardware=true smoke/test_privategw_acl.py ``` I will post my results soon. Cheers, Wilder > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9099) SecretKey is returned from the APIs
Kshitij Kansal created CLOUDSTACK-9099: -- Summary: SecretKey is returned from the APIs Key: CLOUDSTACK-9099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kshitij Kansal Assignee: Kshitij Kansal The sercreKey parameter is returned from the following APIs: createAccount createUser disableAccount disableUser enableAccount enableUser listAccounts listUsers lockAccount lockUser registerUserKeys updateAccount updateUser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035740#comment-15035740 ] ASF GitHub Bot commented on CLOUDSTACK-9099: GitHub user kansal opened a pull request: https://github.com/apache/cloudstack/pull/1152 CLOUDSTACK-9099: SecretKey is returned from the APIs - Fixed The current implementation of User and account management API (in general) return the secret key as a user or account response. Fix: Added a new API to explicitly return the secretKey and removed it from the user and account response. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kansal/cloudstack CLOUDSTACK-9099 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1152.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1152 commit 410045a97a75fd1e43972c66bc4882a30a5098bf Author: Kshitij Kansal Date: 2015-12-02T10:43:45Z CLOUDSTACK-9099: SecretKey is returned from the APIs - Fixed > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035763#comment-15035763 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user resmo commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-161286193 Code LGTM, not yet tested though. > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035785#comment-15035785 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161290470 Ping @remibergsma @DaanHoogland @borisroman Since I touched the router code, I also executed the rVPC tests to make sure those are working fine! I will now run more tests. * Environment: * ACS 4.6 branch * Hardware required: TRUE * Management Server + MySQL on CentOS 7.1 * One KVM Host on CentOS 7.1 * Agent + Common RPMs built from source * Test results: ``` test_01_vpc_privategw_acl (integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: test_01_vpc_privategw_acl | Status : SUCCESS === ok test_02_vpc_privategw_static_routes (integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: test_02_vpc_privategw_static_routes | Status : SUCCESS === ok test_03_rvpc_privategw_static_routes (integration.smoke.test_privategw_acl.TestPrivateGwACL) ... SKIP: Redundant VPC Routers have to be fixed. Private Gateway not working yet. Create a redundant VPC with two networks with two VMs in each network ... === TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : SUCCESS === ok Create a redundant VPC with two networks with two VMs in each network and check default routes ... === TestName: test_02_redundant_VPC_default_routes | Status : SUCCESS === ok Create a redundant VPC with two networks with two VMs in each network ... === TestName: test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status : SUCCESS === ok -- Ran 6 tests in 5188.110s OK (SKIP=1) /tmp//MarvinLogs/test_vpc_redundant_2QYZ59/results.txt (END) ``` > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035792#comment-15035792 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161291156 Jenkins error is related to this:  Which doesn't ring any bell and seems completely unrelated. Cheers, Wilder > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035859#comment-15035859 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161310807 Ping @remibergsma @DaanHoogland @ustcweizhou @bhaisaab The test fails on latest 4.6 branch! ``` === TestName: test_01_stop_vm | Status : SUCCESS === === TestName: test_02_start_vm | Status : SUCCESS === === TestName: test_03_reboot_vm | Status : SUCCESS === === TestName: test_06_destroy_vm | Status : SUCCESS === === TestName: test_07_restore_vm | Status : SUCCESS === === TestName: test_09_expunge_vm | Status : FAILED === ``` And here is the failure: ``` 2015-12-02 14:12:47,260 - CRITICAL - FAILED: test_09_expunge_vm: ['Traceback (most recent call last):\n', ' File "/usr/lib64/python2.7/unittest/case.py", line 369, in run\ntestMethod()\n', ' File "/data/git/cs2/cloudstack/test/integration/smoke/test_vm_life_cycle.py", line 646, in test_09_expunge_vm\nself.assertEqual(list_vm_response,None,"Check Expunged virtual machine is in listVirtualMachines response")\n', ' File "/usr/lib64/python2.7/unittest/case.py", line 553, in assertEqual\n assertion_func(first, second, msg=msg)\n', ' File "/usr/lib64/python2.7/unittest/case.py", line 546, in _baseAssertEqual\n raise self.failureException(msg)\n', 'AssertionError: Check Expunged virtual machine is in listVirtualMachines response\n'] /tmp//MarvinLogs//Dec_02_2015_13_33_23_C9WHUF/failed_plus_exceptions.txt (END) ``` Cheers, Wilder > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035874#comment-15035874 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-161315034 Thanks @miguelaferreira I really appreciate that! Thanks a lot for your help! I'll try to make it before the deadline. I'm not that into Python but I'll do my best with Marvin tests > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNiciraNvpDevices will be updated > ## Adding 1 new response tag – l2gatew
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035884#comment-15035884 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user miguelaferreira commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-161317452 I'm working on adding a new test case to the test file we already have, but unfortunately I don't know how to cover your change. What I do know is how marvin works, and how a test case should look like, so please do ping me (here, or by mail) so that we can setup a chat somewhere and I'll be happy to help you. > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035903#comment-15035903 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-161320788 Sure, I couldn't find you mail address, mine is in my profile > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNiciraNvpDevices will be updated > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNics will be updated > ## Adding 2 new optional response tag – nsxlogicalswitch, nsxlogical
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035986#comment-15035986 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161337904 Okay... no panic! I might have been some expunge global settings that is deployed on all of our test environments. It has been reverted and I will run the tests again. Cheers, Wilder > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036061#comment-15036061
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/943#discussion_r46436064
--- Diff: server/test/async-job-component.xml ---
@@ -108,11 +108,7 @@
--- End diff --
Not sure about this, anyone using this?
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9084) Domain Admin should be able to delet the public IP Address Tags
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036119#comment-15036119 ] ASF subversion and git services commented on CLOUDSTACK-9084: - Commit cd15c66c0cbf2de93f520d8dc813b5d5479d9df1 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd15c66 ] Merge pull request #1122 from sanju1010/ip_tags Add marvin test to verify if DomainAdmin is able to delete the tags on public ip addressPlease go through bug https://issues.apache.org/jira/browse/CLOUDSTACK-9084 for more details. Testcreation, adding and removing tag on public IP address ... === TestName: test_24_public_IP_tag | Status : SUCCESS === ok -- Ran 1 test in 254.724s OK * pr/1122: Incorporated review comments from the PR Add marvin test for bug CS-38356 Bug-Id: CS-38356 Reviewed-By: Self Signed-off-by: Daan Hoogland > Domain Admin should be able to delet the public IP Address Tags > --- > > Key: CLOUDSTACK-9084 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9084 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Sanjeev N >Assignee: Sanjeev N > > Adding marvin test to verify that domain admin can delete the resource tags > created on Public IP Address. > Steps to perform this test: > > 1.Create sub domain under root domain > 2.Add admin account in the domain created > 3.Create network > 4.Acquire public IP address > 5.Add and remove tag on IP Address acquired above > Perform steps 3-5 using domain admin account created in steps 1 and 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9084) Domain Admin should be able to delet the public IP Address Tags
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036121#comment-15036121 ] ASF GitHub Bot commented on CLOUDSTACK-9084: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1122 > Domain Admin should be able to delet the public IP Address Tags > --- > > Key: CLOUDSTACK-9084 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9084 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Sanjeev N >Assignee: Sanjeev N > > Adding marvin test to verify that domain admin can delete the resource tags > created on Public IP Address. > Steps to perform this test: > > 1.Create sub domain under root domain > 2.Add admin account in the domain created > 3.Create network > 4.Acquire public IP address > 5.Add and remove tag on IP Address acquired above > Perform steps 3-5 using domain admin account created in steps 1 and 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9004) Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036154#comment-15036154 ] ASF GitHub Bot commented on CLOUDSTACK-9004: Github user jharshman commented on the pull request: https://github.com/apache/cloudstack/pull/1013#issuecomment-161367693 @DaanHoogland from reading the mailing lists. Looks like there is a freeze for 4.7 features starting Dec 7. Can we get this change merged in before then? The change is very simplistic but it lays some ground work for making CloudStack a bit more stable for windows guests. > Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef > --- > > Key: CLOUDSTACK-9004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9004 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.2 >Reporter: Josh Harshman >Assignee: Josh Harshman >Priority: Minor > Labels: easyfix, patch, perfomance, windows > > LibvirtVMDef.HyperVEnlightenmentFeatureDef only supports the setting of the > relaxed mode feature. This change will expand the subclass to be able to set > vapic and spinlock boolean values, as well as spinlock retry value. > These values will then be written out to the XML appropriately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8936) wrong values from network.throttling.rate / vm.network.throttling.rate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036339#comment-15036339 ] Rohit Yadav commented on CLOUDSTACK-8936: - [~aprateek] can you take a peak at this one? I think users will appreciate this if we can get this fixed for 4.5.3; and 4.6/4.7/master. > wrong values from network.throttling.rate / vm.network.throttling.rate > -- > > Key: CLOUDSTACK-8936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: ACS 4.5.2 / XenServer 6.5 >Reporter: Stephan Seitz > > When setting network.throttling.rate or/and vm.network.throttling.rate the > effective values (at least in XenServer 6.5) are not correct. > Setting 200 MBit/s results in 25600 kBit/s. > Detail (at 200 MBit/s unchanged, left as ACS default): > uuid ( RO): cca4aac4-9b6c-438c-a6a1-c9958cc53f61 > vm-uuid ( RO): cbcca862-e2fa-b3be-d100-c849a0775384 >vm-name-label ( RO): i-31-118-VM > allowed-operations (SRO): attach; unplug > current-operations (SRO): > device ( RO): 1 > MAC ( RO): 06:84:74:00:04:0b >MAC-autogenerated ( RO): false > MTU ( RO): 0 > currently-attached ( RO): true > qos_algorithm_type ( RW): ratelimit > qos_algorithm_params (MRW): kbps: 25600 > qos_supported_algorithms (SRO): > other-config (MRW): cloudstack-network-id: > 90d30b3f-9b9a-407f-b206-9d17dada6093; nicira-iface-id: > f10bcc93-5e4e-4661-a4c0-714bbd26859b; nicira-vm-id: > cbcca862-e2fa-b3be-d100-c849a0775384; cloudstack-nic-id: > f10bcc93-5e4e-4661-a4c0-714bbd26859b; cloudstack-vm-id: > c09b335a-9f69-463a-b521-a2ae120d8e51 > network-uuid ( RO): 81d27813-c7e9-c437-a407-0ae195c75632 > network-name-label ( RO): > VLAN-08d3e9ba-6cea-f91d-cca1-40a01433afdb-172 > io_read_kbs ( RO): 0.019 > io_write_kbs ( RO): 0.018 > locking-mode ( RW): network_default > ipv4-allowed (SRW): > ipv6-allowed (SRW): -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036346#comment-15036346
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user rafaelweingartner commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/943#discussion_r46455242
--- Diff: server/test/async-job-component.xml ---
@@ -108,11 +108,7 @@
--- End diff --
@bhaisaab , probably note (I would say that no one uses it) that class does
not exist.
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036565#comment-15036565 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161428530 @wilderrodrigues Will start some tests! > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036574#comment-15036574 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1145#issuecomment-161429404 @ustcweizhou Took me a while, but the issue is not in this PR. Will post test results soon. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036579#comment-15036579
]
ASF GitHub Bot commented on CLOUDSTACK-9022:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1145#issuecomment-161430026
LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS
===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
SUCCESS ===
ok
--
Ran 33 tests in 16226.348s
OK
```
And:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,requir
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036593#comment-15036593 ] ASF subversion and git services commented on CLOUDSTACK-9022: - Commit 4ed1e0d5f809d1bb2845b6e076d55eeb1ce3f0f4 in cloudstack's branch refs/heads/4.6 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4ed1e0d ] CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036598#comment-15036598 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1145 > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036596#comment-15036596 ] ASF subversion and git services commented on CLOUDSTACK-9022: - Commit 5b7d935ab0b35bec936785e44023ac0d8552e72b in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b7d935 ] Merge pull request #1145 from ustcweizhou/storage-cleanup-delay-4.6 [4.6.1] CLOUDSTACK-9022: keep Destroyed volumes for sometimefor now, the Destroyed volumes will be expunged in Storage cleanup thread, no matter when they are destroyed. In Expunging vm thread, we expunge the Destroyed vms which have been destroyed at least 'expunge.delay' seconds. We add the similar configuration for volumes. same to #1029 , for 4.6 * pr/1145: CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager CLOUDSTACK-9022: keep Destroyed volumes for sometime This closes #1029 Signed-off-by: Remi Bergsma > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036595#comment-15036595 ] ASF subversion and git services commented on CLOUDSTACK-9022: - Commit 5b7d935ab0b35bec936785e44023ac0d8552e72b in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b7d935 ] Merge pull request #1145 from ustcweizhou/storage-cleanup-delay-4.6 [4.6.1] CLOUDSTACK-9022: keep Destroyed volumes for sometimefor now, the Destroyed volumes will be expunged in Storage cleanup thread, no matter when they are destroyed. In Expunging vm thread, we expunge the Destroyed vms which have been destroyed at least 'expunge.delay' seconds. We add the similar configuration for volumes. same to #1029 , for 4.6 * pr/1145: CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager CLOUDSTACK-9022: keep Destroyed volumes for sometime This closes #1029 Signed-off-by: Remi Bergsma > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036592#comment-15036592 ] ASF subversion and git services commented on CLOUDSTACK-9022: - Commit 9077c9a5b47224b2d00978ff67e9af6957ec589b in cloudstack's branch refs/heads/4.6 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9077c9a ] CLOUDSTACK-9022: keep Destroyed volumes for sometime > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036594#comment-15036594 ] ASF subversion and git services commented on CLOUDSTACK-9022: - Commit 5b7d935ab0b35bec936785e44023ac0d8552e72b in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b7d935 ] Merge pull request #1145 from ustcweizhou/storage-cleanup-delay-4.6 [4.6.1] CLOUDSTACK-9022: keep Destroyed volumes for sometimefor now, the Destroyed volumes will be expunged in Storage cleanup thread, no matter when they are destroyed. In Expunging vm thread, we expunge the Destroyed vms which have been destroyed at least 'expunge.delay' seconds. We add the similar configuration for volumes. same to #1029 , for 4.6 * pr/1145: CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager CLOUDSTACK-9022: keep Destroyed volumes for sometime This closes #1029 Signed-off-by: Remi Bergsma > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036602#comment-15036602 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-161431453 @ustcweizhou PR #1145 is merged to 4.6, please close this PR. Thanks! > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036607#comment-15036607 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-161431929 @pdube will run some integration tests against this branch. > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036632#comment-15036632 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161434770 Ping @DaanHoogland @remibergsma @borisroman @bhaisaab More tests! * Tests executed ``` nosetests --with-marvin --marvin-config=/data/shared/marvin/mct-zone2-kvm2-ISOLATED.cfg -s -a tags=advanced,required_hardware=false smoke/test_routers.py smoke/test_reset_vm_on_reboot.py smoke/test_vm_life_cycle.py component/test_vpc_routers.py smoke/test_service_offerings.py component/test_vpc_offerings.py smoke/test_network_acl.py smoke/test_network.py ``` * Results ``` Test router internal advanced zone ... === TestName: test_02_router_internal_adv | Status : SUCCESS === ok Test restart network ... === TestName: test_03_restart_network_cleanup | Status : SUCCESS === ok Test router basic setup ... === TestName: test_05_router_basic | Status : SUCCESS === ok Test router advanced setup ... === TestName: test_06_router_advanced | Status : SUCCESS === ok Test stop router ... === TestName: test_07_stop_router | Status : SUCCESS === ok Test start router ... === TestName: test_08_start_router | Status : SUCCESS === ok Test reboot router ... === TestName: test_09_reboot_router | Status : SUCCESS === ok Test reset virtual machine on reboot ... === TestName: test_01_reset_vm_on_reboot | Status : SUCCESS === ok Test advanced zone virtual router ... === TestName: test_advZoneVirtualRouter | Status : SUCCESS === ok Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status : SUCCESS === ok Test Multiple Deploy Virtual Machine ... === TestName: test_deploy_vm_multiple | Status : SUCCESS === ok Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : SUCCESS === ok Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : SUCCESS === ok Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : SUCCESS === ok Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status : SUCCESS === ok Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status : SUCCESS === ok Test migrate VM ... SKIP: At least two hosts should be present in the zone for migration Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm | Status : SUCCESS === ok Test start/stop of router after addition of one guest network ... === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test reboot of router after addition of one guest network ... === TestName: test_02_reboot_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test to change service offering of router after addition of one guest network ... === TestName: test_04_chg_srv_off_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test destroy of router after addition of one guest network ... === TestName: test_05_destroy_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test to stop and start router after creation of VPC ... === TestName: test_01_stop_start_router_after_creating_vpc | Status : SUCCESS === ok Test to reboot the router after creating a VPC ... === TestName: test_02_reboot_router_after_creating_vpc | Status : SUCCESS === ok Tests to change service offering of the Router after ... === TestName: test_04_change_service_offerring_vpc | Status : SUCCESS === ok Test to destroy the router after creating a VPC ... === TestName: test_05_destroy_router_after_creating_vpc | Status : SUCCESS === ok Test to create service offering ... === TestName: test_01_create_service_offering | Status : SUCCESS === ok Test to update existing service offering ... === TestName: test_02_edit_service_offering | Status : SUCCESS === ok Test to delete service offering ... === TestName: test_03_delete_service_offering | Status : SUCCESS === ok Test create VPC offering ... === TestName: test_01_create_vpc_offering | Status : SUCCESS === ok Test VPC offering without load balancing service ... === TestName: test_03_vpc_off_without_lb | Status : SUCCESS === ok Test VPC offering without static NAT service ... === TestName: test_04_vpc_off_without_static_nat | Status : SUCCESS === ok Test VPC offering without port forwarding service ... === TestName: test_05_vpc_off_without_pf | Status : SUCCESS === ok Test VPC offering with invalid services ... === TestName: test_06_vpc_off_in
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036682#comment-15036682 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-161439739 @remibergsma #1145 has conflict with master branch. you can merge this PR instead. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9004) Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036976#comment-15036976 ] ASF GitHub Bot commented on CLOUDSTACK-9004: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1013#issuecomment-161480457 sure, that is the goal. @borisroman @remibergsma @wilderrodrigues @wido @ustcweizhou Can you review? > Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef > --- > > Key: CLOUDSTACK-9004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9004 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.2 >Reporter: Josh Harshman >Assignee: Josh Harshman >Priority: Minor > Labels: easyfix, patch, perfomance, windows > > LibvirtVMDef.HyperVEnlightenmentFeatureDef only supports the setting of the > relaxed mode feature. This change will expand the subclass to be able to set > vapic and spinlock boolean values, as well as spinlock retry value. > These values will then be written out to the XML appropriately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036995#comment-15036995 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161484253 given the number of tests done I am fine with this. I also reviewed the code, lgtm, I am not confident to put it in capitals but am floating on my experience ;) The exception is a known problem in jenkins and has no correlation whatsoever with the proposed code change: ``` org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalStateException: Invalid object ID 14 iota=593 ``` > As a Developer I want the Private GW feature fixed on single VPCs > - > > Key: CLOUDSTACK-9075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > The Private GW feature is broken since the VR refactor. it should be fixed > for single VPCs and more tests should be included in order to cover it as a > whole. > 1. Test Private GW ACL replace > - existing tests > 2. Test Private GW connectivity through 2 VPCs >- New test > The new test should perform the following steps: > 1. Create 2 VPCs > 2. Create 2 Tiers - 1 per VPC > 3. Deploy 2 VMs - 1 per Tier > 4. Acquire 2 pub IPs - 1 per VPC > 5. Create 2 PF rules - 1 per pub IP > 6. Create 2 ACLs + rules - 1 per VPC > 7. Assign new ACLs to Tiers > 8. Create 2 Private GWs - 1 per VPC > 9. Replace the Pvt GWs ACLs > 10. Create 2 Static routes - 1 per Pvt GW > 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2) > Please note that the Private GWs have to be in the same VLAN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036999#comment-15036999 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-161484620 @ustcweizhou this PR is not needed as the code from 4.6 will be merged into master. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037327#comment-15037327 ] ASF GitHub Bot commented on CLOUDSTACK-9075: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1151#issuecomment-161528070 Ping @remibergsma @DaanHoogland @borisroman Before testing, please note that the smoke/test_privategw_acl.py now requires hardware! * Environment: * ACS 4.6 branch * Hardware required: TRUE * Management Server + MySQL on CentOS 7.1 * One KVM Host on CentOS 7.1 * Agent + Common RPMs built from source * Tests executed ``` nosetests --with-marvin --marvin-config=/data/shared/marvin/mct-zone2-kvm2-ISOLATED.cfg -s -a tags=advanced,required_hardware=true component/test_routers_iptables_default_policy.py component/test_routers_network_ops.py component/test_vpc_router_nics.py component/test_password_server.py component/test_router_dhcphosts.py smoke/test_loadbalance.py smoke/test_internal_lb.py smoke/test_ssvm.py smoke/test_vpc_vpn.py smoke/test_network.py ``` * Results ``` Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: test_02_routervm_iptables_policies | Status : SUCCESS === ok Test iptables default INPUT/FORWARD policies on VPC router ... === TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS === ok Create a VPC with two networks with one VM in each network and test nics after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : SUCCESS === ok Create a VPC with two networks with one VM in each network and test default routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS === ok Check the password file in the Router VM ... === TestName: test_isolate_network_password_server | Status : SUCCESS === ok Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === TestName: test_router_dhcphosts | Status : SUCCESS === ok Test to create Load balancing rule with source NAT ... === TestName: test_01_create_lb_rule_src_nat | Status : SUCCESS === ok Test to create Load balancing rule with non source NAT ... === TestName: test_02_create_lb_rule_non_nat | Status : SUCCESS === ok Test for assign & removing load balancing rule ... === TestName: test_assign_and_removal_lb | Status : SUCCESS === ok Test to verify access to loadbalancer haproxy admin stats page ... === TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS === ok Test create, assign, remove of an Internal LB with roundrobin http traffic to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | Status : SUCCESS === ok Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : SUCCESS === ok Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : SUCCESS === ok Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS === ok Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS === ok Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS === ok Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS === ok Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS === ok Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS === ok Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS === ok Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS === ok Test for port forwarding on source NAT ... === TestName: test_01_port_fwd_on_src_nat | Status : SUCCESS === ok Test for port forwarding on non source NAT ... === TestName: test_02_port_fwd_on_non_src_nat | Status : SUCCESS === ok Test for reboot router ... === TestName: test_reboot_router | Status : SUCCESS === ok Test for Router rules for network rules on acquired public IP ... === TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : SUCCESS === ok Test for Router rules for network rul
[jira] [Commented] (CLOUDSTACK-9087) [marvin]modifying a method(create method of class vmshanpshot) signature in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037373#comment-15037373 ] ASF GitHub Bot commented on CLOUDSTACK-9087: GitHub user nitt10prashant opened a pull request: https://github.com/apache/cloudstack/pull/1153 CLOUDSTACK-9087:adding projectid parameter to create method of class VmSnapshot Adding projectid parameter to class VmSnapshot of base.py . You can merge this pull request into a Git repository by running: $ git pull https://github.com/nitt10prashant/cloudstack mvr Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1153.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1153 commit bf24ad8099366a3f17bc4e3a94236a75a2e673de Author: nitt10prashant Date: 2015-11-26T10:57:15Z CLOUDSTACK-9087:adding projectid parameter to create method of class VmSnapshot > [marvin]modifying a method(create method of class vmshanpshot) signature in > base.py > > > Key: CLOUDSTACK-9087 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9087 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > adding projectid parameter to create method of class VmSnapshot . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9087) [marvin]modifying a method(create method of class vmshanpshot) signature in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-9087: -- Description: currently create method does not support create vm snpashot under a project . modifying create method for the same was: adding projectid parameter to create method of class VmSnapshot . > [marvin]modifying a method(create method of class vmshanpshot) signature in > base.py > > > Key: CLOUDSTACK-9087 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9087 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > currently create method does not support create vm snpashot under a project . > modifying create method for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037402#comment-15037402 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou closed the pull request at: https://github.com/apache/cloudstack/pull/1029 > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037401#comment-15037401 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-161535590 @DaanHoogland @remibergsma OK, I close this PR, You need to fix the conflict manually when you merge 4.6 to master. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037419#comment-15037419
]
ASF GitHub Bot commented on CLOUDSTACK-6276:
Github user ustcweizhou commented on the pull request:
https://github.com/apache/cloudstack/pull/1134#issuecomment-161537378
LGTM. tested
(1) create affinity group in project
(2) deploy vm with affinity group
(3) update vm affinity group
(4) delete affinity group.
one suggestion,
```
diff --git
a/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
b/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
index 5da1f88..e2de220 100644
---
a/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
+++
b/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
@@ -434,7 +434,7 @@ public class AffinityGroupServiceImpl extends
ManagerBase implements AffinityGro
throw new InvalidParameterValueException("Unable to find
affinity group by id " + affinityGroupId);
} else {
// verify permissions
-_accountMgr.checkAccess(caller, null, true, owner, ag);
+_accountMgr.checkAccess(caller, AccessType.OperateEntry,
true, owner, ag);
// Root admin has access to both VM and AG by default, but
make sure the
// owner of these entities is same
if (caller.getId() == Account.ACCOUNT_ID_SYSTEM ||
_accountMgr.isRootAdmin(caller.getId())) {
```
> Affinity Groups within projects
> ---
>
> Key: CLOUDSTACK-6276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Ingo Jochim
>
> Hello,
> I like to have the features "Affinity Group" and "Project" combined.
> As far as I know I cannot use Affinity Groups within Projects.
> Thanks and regards,
> Ingo
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037422#comment-15037422
]
ASF GitHub Bot commented on CLOUDSTACK-6276:
Github user ustcweizhou commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1134#discussion_r46519549
--- Diff:
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java ---
@@ -229,59 +205,99 @@ public AffinityGroupVO
doInTransaction(TransactionStatus status) {
return group;
}
});
+}
-if (s_logger.isDebugEnabled()) {
-s_logger.debug("Created affinity group =" + affinityGroupName);
+private DomainVO getDomain(Long domainId) {
+DomainVO domain = _domainDao.findById(domainId);
+if (domain == null) {
+throw new InvalidParameterValueException("Unable to find
domain by specified id");
}
+return domain;
+}
-return group;
+private void verifyAffinityGroupNameInUse(long accountId, long
domainId, String affinityGroupName) {
+if (_affinityGroupDao.isNameInUse(accountId, domainId,
affinityGroupName)) {
+throw new InvalidParameterValueException("Unable to create
affinity group, a group with name " + affinityGroupName + " already exists.");
+}
+}
+
+private void verifyDomainLevelAffinityGroupName(boolean domainLevel,
long domainId, String affinityGroupName) {
+if (domainLevel &&
_affinityGroupDao.findDomainLevelGroupByName(domainId, affinityGroupName) !=
null) {
+throw new InvalidParameterValueException("Unable to create
affinity group, a group with name " + affinityGroupName + " already exists
under the domain.");
+}
}
@DB
-@Override
@ActionEvent(eventType = EventTypes.EVENT_AFFINITY_GROUP_DELETE,
eventDescription = "Deleting affinity group")
-public boolean deleteAffinityGroup(Long affinityGroupId, String
account, Long domainId, String affinityGroupName) {
+public boolean deleteAffinityGroup(Long affinityGroupId, String
account, Long projectId, Long domainId, String affinityGroupName) {
+
+AffinityGroupVO group = getAffinityGroup(affinityGroupId, account,
projectId, domainId, affinityGroupName);
+// check permissions
Account caller = CallContext.current().getCallingAccount();
-Account owner = _accountMgr.finalizeOwner(caller, account,
domainId, null);
+_accountMgr.checkAccess(caller, AccessType.OperateEntry, true,
group);
--- End diff --
why not AccessType.ModifyProject ?
If AccessType.OperateEntry, all normal uses (not only admin) can delete the
affinity group.
> Affinity Groups within projects
> ---
>
> Key: CLOUDSTACK-6276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Ingo Jochim
>
> Hello,
> I like to have the features "Affinity Group" and "Project" combined.
> As far as I know I cannot use Affinity Groups within Projects.
> Thanks and regards,
> Ingo
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
