[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=15030832#comment-15030832
]
ASF GitHub Bot commented on CLOUDSTACK-6276:
Github user remibergsma commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1134#discussion_r46088753
--- Diff: test/integration/component/test_affinity_groups_projects.py ---
@@ -0,0 +1,1083 @@
+#!/usr/bin/env python
+# 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.
+from marvin.cloudstackTestCase import cloudstackTestCase, unittest
+from marvin.cloudstackAPI import deleteAffinityGroup
+from marvin.lib.utils import (cleanup_resources,
+random_gen)
+from marvin.lib.base import (Account,
+Project,
+ServiceOffering,
+VirtualMachine,
+AffinityGroup,
+Domain)
+from marvin.lib.common import (get_zone,
+ get_domain,
+ get_template,
+ list_hosts,
+ list_virtual_machines,
+ wait_for_cleanup)
+from nose.plugins.attrib import attr
+
+class Services:
+"""Test Account Services
+"""
+
+def __init__(self):
+ self.services = {
+ "domain": {
+ "name": "NonRootDomain"
+ },
+ "domain_admin_account": {
+ "email": "newt...@test.com",
+ "firstname": "Test",
+ "lastname": "User",
+ "username": "doadmintest",
+ "password": "password"
+ },
+ "account": {
+ "email": "newt...@test.com",
+ "firstname": "Test",
+ "lastname": "User",
+ "username": "acc",
+ "password": "password"
+ },
+ "account_not_in_project": {
+ "email": "newt...@test.com",
+ "firstname": "Test",
+ "lastname": "User",
+ "username": "account_not_in_project",
+ "password": "password"
+ },
+ "project": {
+ "name": "Project",
+ "displaytext": "Project"
+ },
+ "project2": {
+ "name": "Project2",
+ "displaytext": "Project2"
+ },
+ "service_offering": {
+ "name": "Tiny Instance",
+ "displaytext": "Tiny Instance",
+ "cpunumber": 1,
+ "cpuspeed": 100,
+ "memory": 64
+ },
+ "ostype": 'CentOS 5.3 (64-bit)',
+ "host_anti_affinity": {
+"name": "",
+"type": "host anti-affinity"
+ },
+ "virtual_machine" : {
+ "hypervisor" : "KVM"
--- End diff --
@pdube Even better, thanks!
> 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-9083) Add disk serial to vm/libvirt xml in case of KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030834#comment-15030834
]
ASF GitHub Bot commented on CLOUDSTACK-9083:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1121#issuecomment-160390678
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 17559.991s
OK
```
And:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,requir
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030835#comment-15030835
]
ASF GitHub Bot commented on CLOUDSTACK-9081:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1118#issuecomment-160390779
LGTM based on these tests (although I didn't test the actual change).
```
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 17430.478s
OK
```
And:
```
nosetests --with-marvin --marvin-conf
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030838#comment-15030838
]
ASF subversion and git services commented on CLOUDSTACK-9081:
-
Commit f823d06dd9b610ba8e6b3cab9f815feb157a4f68 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f823d06 ]
Merge pull request #1118 from karuturi/CLOUDSTACK-9081
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS
setupStorage motion of vm across clusters/xenserver-pools fails in a
clustered management server setup. In xen storage motion we have to send
a migrate_receive command to the destination host, followed by
migrate_send command to the source host. The sr and network detials of
the destination host have to be passed in migrate_send command on the
source. While migrating across clusters the source and destination
resources are seperate objects. To pass this information across
resources we have to send seperate migrate with storage receive and send
commands to the resource. In a clustered ms setup these commands may
have to be forwarded to another ms as the resource may be owned by it.
The serilization of the command and answer objects fails in such case as
it doesn't understand the xapi sr and network objects. Made a change to
serialize these objects in the resource layer and pass the around as
strings in the command and answer objects.
Reviewed-By: @likitha
Author: @devdeep
Tested-By: @sailajamada
* pr/1118:
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS setup
Signed-off-by: Remi Bergsma
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"def
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030840#comment-15030840
]
ASF GitHub Bot commented on CLOUDSTACK-9081:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1118
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"pxeDisable":false,"nicUuid":"45cd68fb-fe60-454c-9a08-f73fd902cef0","uuid":"38a40e2d-0f12-4015-9753-8c08d76d52dc","ip":"172.27.0.113","netmask":"255.255.0.0","gateway":"172.27.0.1","mac":"02:00:59:6b:00:08","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://1109","isolationUri":"vlan://1109","isSecurityGroupEnabled":false,"name":"cloud-public"},"u":{"ref":"OpaqueRef:c9087c77-81f9-03eb-9cf8-df7868354563"}},{"t":{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"pxeDisable":false,"nicUuid":"1504aed4-4871-48d5-abed-581889cea7c7","uuid":"28f3a4f4-dd3d-42d2-b4a4-5243a50232c8","ip":"10.10.10.2","netmask":"255.255.255.0","gateway":"10.10.10.1","mac":"06:a8:b8:00:10:83","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://3339","isolationUri":"vlan://3339","isSecurityGroupEnabled":false,"name":"cloud-public"},"u":{"ref":"OpaqueRef:0110ebab-607d-f02f-134a-383e77324677"}}],"token":{"session_id":"OpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a","host":"OpaqueRef:0d842514-468d-4dd9-5dfe-015ce3898a66","SM":"http://10.32.1.4/services/SM?session_id\u003dOpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a","master":"http://10.13.4.1/","xenops":"http://10.32.1.4/services/xenops?session_id\u003dOpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a"},"result":true,"contextMap":{},"
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030836#comment-15030836
]
ASF subversion and git services commented on CLOUDSTACK-9081:
-
Commit 00522e475b5b943885476e2c7051c00e3168ebb1 in cloudstack's branch
refs/heads/master from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=00522e4 ]
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS setup
Storage motion of vm across clusters/xenserver-pools fails in a
clustered management server setup. In xen storage motion we have to send
a migrate_receive command to the destination host, followed by
migrate_send command to the source host. The sr and network detials of
the destination host have to be passed in migrate_send command on the
source. While migrating across clusters the source and destination
resources are seperate objects. To pass this information across
resources we have to send seperate migrate with storage receive and send
commands to the resource. In a clustered ms setup these commands may
have to be forwarded to another ms as the resource may be owned by it.
The serilization of the command and answer objects fails in such case as
it doesn't understand the xapi sr and network objects. Made a change to
serialize these objects in the resource layer and pass the around as
strings in the command and answer objects. Reviewed-By: Likitha
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"pxeDisable":false,"nicUuid":"45cd68fb-fe60-454c-9a08-f73fd902cef0","uuid":"38a40e2d-0f12-4015-9753-8c08d76d52dc","ip":"172.27.0.113","netmask":"255.255.0.0","gateway":"172.27.0.1","mac":"02:00:59:6b:00:08"
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030839#comment-15030839
]
ASF subversion and git services commented on CLOUDSTACK-9081:
-
Commit f823d06dd9b610ba8e6b3cab9f815feb157a4f68 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f823d06 ]
Merge pull request #1118 from karuturi/CLOUDSTACK-9081
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS
setupStorage motion of vm across clusters/xenserver-pools fails in a
clustered management server setup. In xen storage motion we have to send
a migrate_receive command to the destination host, followed by
migrate_send command to the source host. The sr and network detials of
the destination host have to be passed in migrate_send command on the
source. While migrating across clusters the source and destination
resources are seperate objects. To pass this information across
resources we have to send seperate migrate with storage receive and send
commands to the resource. In a clustered ms setup these commands may
have to be forwarded to another ms as the resource may be owned by it.
The serilization of the command and answer objects fails in such case as
it doesn't understand the xapi sr and network objects. Made a change to
serialize these objects in the resource layer and pass the around as
strings in the command and answer objects.
Reviewed-By: @likitha
Author: @devdeep
Tested-By: @sailajamada
* pr/1118:
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS setup
Signed-off-by: Remi Bergsma
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"def
[jira] [Commented] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030837#comment-15030837
]
ASF subversion and git services commented on CLOUDSTACK-9081:
-
Commit f823d06dd9b610ba8e6b3cab9f815feb157a4f68 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f823d06 ]
Merge pull request #1118 from karuturi/CLOUDSTACK-9081
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS
setupStorage motion of vm across clusters/xenserver-pools fails in a
clustered management server setup. In xen storage motion we have to send
a migrate_receive command to the destination host, followed by
migrate_send command to the source host. The sr and network detials of
the destination host have to be passed in migrate_send command on the
source. While migrating across clusters the source and destination
resources are seperate objects. To pass this information across
resources we have to send seperate migrate with storage receive and send
commands to the resource. In a clustered ms setup these commands may
have to be forwarded to another ms as the resource may be owned by it.
The serilization of the command and answer objects fails in such case as
it doesn't understand the xapi sr and network objects. Made a change to
serialize these objects in the resource layer and pass the around as
strings in the command and answer objects.
Reviewed-By: @likitha
Author: @devdeep
Tested-By: @sailajamada
* pr/1118:
CLOUDSTACK-9081 Migration of vm across clusters fails in clustered MS setup
Signed-off-by: Remi Bergsma
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"def
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030841#comment-15030841 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1121#issuecomment-160390932 Pinging @DaanHoogland @borisroman to do second review. > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- 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=15030843#comment-15030843 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-160391354 @miguelaferreira @wilderrodrigues Can one of you review this? Once done, I can run the integration tests again.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 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 > ## Addi
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030844#comment-15030844
]
ASF GitHub Bot commented on CLOUDSTACK-8958:
Github user remibergsma commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1007#discussion_r46089078
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java
---
@@ -3310,13 +3331,19 @@ public Vlan dedicatePublicIpRange(final
DedicatePublicIpRangeCmd cmd) throws Res
vlanOwner =
_accountMgr.getAccount(project.getProjectAccountId());
}
+Domain domain = null;
if (accountName != null && domainId != null) {
vlanOwner = _accountDao.findActiveAccount(accountName,
domainId);
-}
-if (vlanOwner == null) {
-throw new InvalidParameterValueException("Unable to find
account by name " + accountName);
-} else if (vlanOwner.getId() == Account.ACCOUNT_ID_SYSTEM) {
-throw new InvalidParameterValueException("Please specify a
valid account. Cannot dedicate IP range to system account");
+if (vlanOwner == null) {
--- End diff --
Looks like the project case is handled by
89ce8bd9e289327f411790eb05a9fb49ef1f9a2f. Since all tests pass, I will merge
this now. Future adjustments can be made in a separate PR.
> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain
> ips are dedicated to Account for now, so other customers and projects in the
> same domain will use the system ip. this is not what we need.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030847#comment-15030847 ] ASF subversion and git services commented on CLOUDSTACK-8958: - Commit a1d2c531f65271f0301a26b4bd4ddb76f2f85ee5 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1d2c53 ] Merge pull request #1007 from ustcweizhou/dedicated-ip-for-domain [4.7] CLOUDSTACK-8958: add dedicated ips to domain (account for now)For now, we dedicate ip pool to account, however, other accounts in the same domain cannot fetch the ip from this ip pool. By dedicating ip pool to domain, accounts in the domain can fetch the public ip from same ip pool. * pr/1007: CLOUDSTACK-8958: throw an exception if project account cannot be found CLOUDSTACK-8958: add dedicated ips to domain (account for now) Signed-off-by: Remi Bergsma > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030848#comment-15030848 ] ASF subversion and git services commented on CLOUDSTACK-8958: - Commit a1d2c531f65271f0301a26b4bd4ddb76f2f85ee5 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1d2c53 ] Merge pull request #1007 from ustcweizhou/dedicated-ip-for-domain [4.7] CLOUDSTACK-8958: add dedicated ips to domain (account for now)For now, we dedicate ip pool to account, however, other accounts in the same domain cannot fetch the ip from this ip pool. By dedicating ip pool to domain, accounts in the domain can fetch the public ip from same ip pool. * pr/1007: CLOUDSTACK-8958: throw an exception if project account cannot be found CLOUDSTACK-8958: add dedicated ips to domain (account for now) Signed-off-by: Remi Bergsma > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030849#comment-15030849 ] ASF subversion and git services commented on CLOUDSTACK-8958: - Commit a1d2c531f65271f0301a26b4bd4ddb76f2f85ee5 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1d2c53 ] Merge pull request #1007 from ustcweizhou/dedicated-ip-for-domain [4.7] CLOUDSTACK-8958: add dedicated ips to domain (account for now)For now, we dedicate ip pool to account, however, other accounts in the same domain cannot fetch the ip from this ip pool. By dedicating ip pool to domain, accounts in the domain can fetch the public ip from same ip pool. * pr/1007: CLOUDSTACK-8958: throw an exception if project account cannot be found CLOUDSTACK-8958: add dedicated ips to domain (account for now) Signed-off-by: Remi Bergsma > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030845#comment-15030845 ] ASF subversion and git services commented on CLOUDSTACK-8958: - Commit 37301ed4540450c29be4f975d58b38dbeec6c296 in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=37301ed ] CLOUDSTACK-8958: add dedicated ips to domain (account for now) > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030846#comment-15030846 ] ASF subversion and git services commented on CLOUDSTACK-8958: - Commit 89ce8bd9e289327f411790eb05a9fb49ef1f9a2f in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=89ce8bd ] CLOUDSTACK-8958: throw an exception if project account cannot be found > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030850#comment-15030850 ] ASF GitHub Bot commented on CLOUDSTACK-8958: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1007 > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030852#comment-15030852 ] ASF subversion and git services commented on CLOUDSTACK-9078: - Commit e2fc270480916901b2bfd4f4bab376a6008f9f57 in cloudstack's branch refs/heads/4.6 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e2fc270 ] CLOUDSTACK-9078: Gave scripts executable permissions. > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9076) Directory /var/lib/cloudstack isn't owned by cloud.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030851#comment-15030851 ] ASF subversion and git services commented on CLOUDSTACK-9076: - Commit 1e73f667c93fe7bc7a765f205e1eb62fb778f99c in cloudstack's branch refs/heads/4.6 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e73f66 ] CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. > Directory /var/lib/cloudstack isn't owned by cloud. > --- > > Key: CLOUDSTACK-9076 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9076 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0, 4.7.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Because the directory /var/lib/cloudstack isn't owned by cloud, the Java > program can't create folders inside for mounting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9076) Directory /var/lib/cloudstack isn't owned by cloud.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030854#comment-15030854 ] ASF subversion and git services commented on CLOUDSTACK-9076: - Commit a44e0b7309e6b65a8d50c016337ced1da5e8990b in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a44e0b7 ] Merge pull request #1105 from borisroman/packagingIssues Debian/Ubuntu packaging issuesSee individual issues. I've installed the management server with and without the fix. See difference bellow. Before: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 root root 4096 Nov 23 00:20 . drwxr-xr-x 46 root root 4096 Nov 23 00:21 .. drwxrwx--- 2 root cloud 4096 Nov 17 01:15 management drwxr-xr-x 2 root root 4096 Nov 17 01:15 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:20 . drwxr-xr-x 4 root root 4096 Nov 23 00:20 .. -rw-r--r-- 1 root root 10092 Nov 17 01:15 cloud-install-sys-tmplt -rw-r--r-- 1 root root 10591 Nov 17 01:15 cloud-install-sys-tmplt.py -rw-r--r-- 1 root root 11254 Nov 23 00:20 cloud-install-sys-tmplt.pyc -rw-r--r-- 1 root root 2362 Nov 17 01:15 create_privatetemplate_from_snapshot_xen.sh -rw-r--r-- 1 root root 5446 Nov 17 01:15 createtmplt.sh -rw-r--r-- 1 root root 5388 Nov 17 01:15 createvolume.sh -rw-r--r-- 1 root root 2532 Nov 17 01:15 installIso.sh -rw-r--r-- 1 root root 1622 Nov 17 01:15 listvmtmplt.sh -rw-r--r-- 1 root root 1621 Nov 17 01:15 listvolume.sh -rw-r--r-- 1 root root 75712 Nov 17 01:15 swift ``` After: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 cloud cloud 4096 Nov 23 00:51 . drwxr-xr-x 46 root root 4096 Nov 23 00:53 .. drwxrwx--- 2 cloud cloud 4096 Nov 23 00:33 management drwxr-xr-x 2 cloud cloud 4096 Nov 23 00:33 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:53 . drwxr-xr-x 4 root root 4096 Nov 23 00:53 .. -rwxr-xr-x 1 root root 10092 Nov 23 00:33 cloud-install-sys-tmplt -rwxr-xr-x 1 root root 10591 Nov 23 00:33 cloud-install-sys-tmplt.py -rwxr-xr-x 1 root root 11254 Nov 23 00:53 cloud-install-sys-tmplt.pyc -rwxr-xr-x 1 root root 2362 Nov 23 00:33 create_privatetemplate_from_snapshot_xen.sh -rwxr-xr-x 1 root root 5446 Nov 23 00:33 createtmplt.sh -rwxr-xr-x 1 root root 5388 Nov 23 00:33 createvolume.sh -rwxr-xr-x 1 root root 2532 Nov 23 00:33 installIso.sh -rwxr-xr-x 1 root root 1622 Nov 23 00:33 listvmtmplt.sh -rwxr-xr-x 1 root root 1621 Nov 23 00:33 listvolume.sh -rwxr-xr-x 1 root root 75712 Nov 23 00:33 swift ``` * pr/1105: CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Signed-off-by: Remi Bergsma > Directory /var/lib/cloudstack isn't owned by cloud. > --- > > Key: CLOUDSTACK-9076 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9076 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0, 4.7.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Because the directory /var/lib/cloudstack isn't owned by cloud, the Java > program can't create folders inside for mounting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030853#comment-15030853 ] ASF subversion and git services commented on CLOUDSTACK-9078: - Commit a44e0b7309e6b65a8d50c016337ced1da5e8990b in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a44e0b7 ] Merge pull request #1105 from borisroman/packagingIssues Debian/Ubuntu packaging issuesSee individual issues. I've installed the management server with and without the fix. See difference bellow. Before: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 root root 4096 Nov 23 00:20 . drwxr-xr-x 46 root root 4096 Nov 23 00:21 .. drwxrwx--- 2 root cloud 4096 Nov 17 01:15 management drwxr-xr-x 2 root root 4096 Nov 17 01:15 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:20 . drwxr-xr-x 4 root root 4096 Nov 23 00:20 .. -rw-r--r-- 1 root root 10092 Nov 17 01:15 cloud-install-sys-tmplt -rw-r--r-- 1 root root 10591 Nov 17 01:15 cloud-install-sys-tmplt.py -rw-r--r-- 1 root root 11254 Nov 23 00:20 cloud-install-sys-tmplt.pyc -rw-r--r-- 1 root root 2362 Nov 17 01:15 create_privatetemplate_from_snapshot_xen.sh -rw-r--r-- 1 root root 5446 Nov 17 01:15 createtmplt.sh -rw-r--r-- 1 root root 5388 Nov 17 01:15 createvolume.sh -rw-r--r-- 1 root root 2532 Nov 17 01:15 installIso.sh -rw-r--r-- 1 root root 1622 Nov 17 01:15 listvmtmplt.sh -rw-r--r-- 1 root root 1621 Nov 17 01:15 listvolume.sh -rw-r--r-- 1 root root 75712 Nov 17 01:15 swift ``` After: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 cloud cloud 4096 Nov 23 00:51 . drwxr-xr-x 46 root root 4096 Nov 23 00:53 .. drwxrwx--- 2 cloud cloud 4096 Nov 23 00:33 management drwxr-xr-x 2 cloud cloud 4096 Nov 23 00:33 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:53 . drwxr-xr-x 4 root root 4096 Nov 23 00:53 .. -rwxr-xr-x 1 root root 10092 Nov 23 00:33 cloud-install-sys-tmplt -rwxr-xr-x 1 root root 10591 Nov 23 00:33 cloud-install-sys-tmplt.py -rwxr-xr-x 1 root root 11254 Nov 23 00:53 cloud-install-sys-tmplt.pyc -rwxr-xr-x 1 root root 2362 Nov 23 00:33 create_privatetemplate_from_snapshot_xen.sh -rwxr-xr-x 1 root root 5446 Nov 23 00:33 createtmplt.sh -rwxr-xr-x 1 root root 5388 Nov 23 00:33 createvolume.sh -rwxr-xr-x 1 root root 2532 Nov 23 00:33 installIso.sh -rwxr-xr-x 1 root root 1622 Nov 23 00:33 listvmtmplt.sh -rwxr-xr-x 1 root root 1621 Nov 23 00:33 listvolume.sh -rwxr-xr-x 1 root root 75712 Nov 23 00:33 swift ``` * pr/1105: CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Signed-off-by: Remi Bergsma > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030855#comment-15030855
]
ASF GitHub Bot commented on CLOUDSTACK-9083:
Github user wido commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1121#discussion_r46089169
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -419,7 +419,7 @@ public String toString() {
public static class DiskDef {
public enum DeviceType {
-FLOPPY("floppy"), DISK("disk"), CDROM("cdrom");
+FLOPPY("floppy"), DISK("disk"), CDROM("cdrom"), LUN("lun");
--- End diff --
So why is the LUN type added here?
> Add disk serial to vm/libvirt xml in case of KVM
>
>
> Key: CLOUDSTACK-9083
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
>
> Certain appliances/software fail on KVM as they require disk serials (inside
> of the VM). The fix would be to add a disk serial (from volume uuid) in the
> generated libvirt xml for all disks except for lun/scsi block type disks
> (which we don't support yet, so we can add in a deviceType for now and leave
> some comment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030857#comment-15030857
]
ASF GitHub Bot commented on CLOUDSTACK-9083:
Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1121#discussion_r46089189
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -761,6 +766,10 @@ public String toString() {
}
diskBuilder.append("/>\n");
+if (_serial != null && !_serial.isEmpty() && _deviceType !=
DeviceType.LUN) {
--- End diff --
@wido see, we use the device type here to avoid adding the disk/volume
serial if the device type is LUN
> Add disk serial to vm/libvirt xml in case of KVM
>
>
> Key: CLOUDSTACK-9083
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
>
> Certain appliances/software fail on KVM as they require disk serials (inside
> of the VM). The fix would be to add a disk serial (from volume uuid) in the
> generated libvirt xml for all disks except for lun/scsi block type disks
> (which we don't support yet, so we can add in a deviceType for now and leave
> some comment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030856#comment-15030856
]
ASF GitHub Bot commented on CLOUDSTACK-9083:
Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1121#discussion_r46089183
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -419,7 +419,7 @@ public String toString() {
public static class DiskDef {
public enum DeviceType {
-FLOPPY("floppy"), DISK("disk"), CDROM("cdrom");
+FLOPPY("floppy"), DISK("disk"), CDROM("cdrom"), LUN("lun");
--- End diff --
SCSI block devices, LUN are not supported; the type was added to avoid
possible bug in case we decide to support this storage/device type in future.
See https://libvirt.org/formatdomain.html#elementsDisks for details.
> Add disk serial to vm/libvirt xml in case of KVM
>
>
> Key: CLOUDSTACK-9083
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
>
> Certain appliances/software fail on KVM as they require disk serials (inside
> of the VM). The fix would be to add a disk serial (from volume uuid) in the
> generated libvirt xml for all disks except for lun/scsi block type disks
> (which we don't support yet, so we can add in a deviceType for now and leave
> some comment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030858#comment-15030858
]
ASF GitHub Bot commented on CLOUDSTACK-9083:
Github user wido commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1121#discussion_r46089207
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -761,6 +766,10 @@ public String toString() {
}
diskBuilder.append("/>\n");
+if (_serial != null && !_serial.isEmpty() && _deviceType !=
DeviceType.LUN) {
--- End diff --
I see, but it is suddenly a new type of disk I haven't seen before in KVM.
Hence my question.
> Add disk serial to vm/libvirt xml in case of KVM
>
>
> Key: CLOUDSTACK-9083
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
>
> Certain appliances/software fail on KVM as they require disk serials (inside
> of the VM). The fix would be to add a disk serial (from volume uuid) in the
> generated libvirt xml for all disks except for lun/scsi block type disks
> (which we don't support yet, so we can add in a deviceType for now and leave
> some comment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030865#comment-15030865
]
ASF GitHub Bot commented on CLOUDSTACK-4787:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1132#issuecomment-160392997
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 16746.083s
OK
```
And:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,requir
[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=15030944#comment-15030944
]
ASF GitHub Bot commented on CLOUDSTACK-6276:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1134#discussion_r46092314
--- Diff: api/src/org/apache/cloudstack/affinity/AffinityGroupService.java
---
@@ -18,47 +18,36 @@
import java.util.List;
+import
org.apache.cloudstack.api.command.user.affinitygroup.CreateAffinityGroupCmd;
+
import com.cloud.uservm.UserVm;
-import com.cloud.utils.Pair;
public interface AffinityGroupService {
/**
* Creates an affinity/anti-affinity group for the given
account/domain.
*
- * @param account
+ * @param accountName
+ * @param projectId
* @param domainId
- * @param name
- * @param type
+ * @param affinityGroupName
+ * @param affinityGroupType
* @param description
* @return AffinityGroup
*/
+AffinityGroup createAffinityGroup(String accountName, Long projectId,
Long domainId, String affinityGroupName, String affinityGroupType, String
description);
-AffinityGroup createAffinityGroup(String account, Long domainId,
String affinityGroupName, String affinityGroupType, String description);
+AffinityGroup createAffinityGroup(CreateAffinityGroupCmd
createAffinityGroupCmd);
/**
* Creates an affinity/anti-affinity group.
*
* @param affinityGroupId
- * @param account
- * @param domainId
- * @param affinityGroupName
- */
-boolean deleteAffinityGroup(Long affinityGroupId, String account, Long
domainId, String affinityGroupName);
-
-/** Lists Affinity Groups in your account
- * @param account
+ * @param accountName
* @param domainId
- * @param affinityGroupId
* @param affinityGroupName
- * @param affinityGroupType
- * @param vmId
- * @param startIndex
- * @param pageSize
- * @return
*/
-Pair, Integer> listAffinityGroups(Long
affinityGroupId, String affinityGroupName, String affinityGroupType, Long vmId,
Long startIndex,
--- End diff --
@pdube does it not make sense to list affinity groups?
> 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=15030947#comment-15030947 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1134#discussion_r46092351 --- Diff: api/src/org/apache/cloudstack/query/QueryService.java --- @@ -131,9 +132,7 @@ ListResponse listIsos(ListIsosCmd cmd); -ListResponse listAffinityGroups(Long affinityGroupId, String affinityGroupName, -String affinityGroupType, Long vmId, String accountName, Long domainId, boolean isRecursive, -boolean listAll, Long startIndex, Long pageSize, String keyword); +ListResponse searchForAffinityGroups(ListAffinityGroupsCmd cmd); --- End diff -- I makes more sense to put this in the AffinityGroupService. (a list function) > 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=15030952#comment-15030952 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1134#discussion_r46092380 --- Diff: server/src/com/cloud/user/AccountManagerImpl.java --- @@ -2406,98 +2406,10 @@ public void buildACLSearchCriteria(SearchCriteria sc } } -//@Override --- End diff -- :+1: > 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=15030956#comment-15030956 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160417989 Did a quick review and it looks great. One general remark; Let's keep interface as orthogonal as possible, i.e. use 'list' as the prefix for search functions and have a service implement it's own list method. @pdube you probably found some guide somewhere that made you do this differently. can you tell me where? The reason I want this is to be able to contain resource editing in a single widget using as little services as possible. > 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=15031107#comment-15031107 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user pdube commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160441642 @DaanHoogland I did not find a guide to do it. I looked at the patterns I found in other modules, and imitated those. I found it confusing because there were a few different ways to do it. I really don't mind moving it back into the service. As a side question, why not move it into the AffinityGroupDao? (if not, what is the Dao for?) Is there a definitive guide for writing APIs? If there is not a definitive guide, then maybe we should write one to help with the evolution of the APIs > 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-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031110#comment-15031110
]
ASF GitHub Bot commented on CLOUDSTACK-9064:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1116#issuecomment-160442050
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 15802.447s
OK
```
And:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,requir
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1503#comment-1503 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit d09898553e8a7722f82866367923bc8cedc62829 in cloudstack's branch refs/heads/4.6 from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d098985 ] CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031112#comment-15031112 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031116#comment-15031116 ] ASF GitHub Bot commented on CLOUDSTACK-9064: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1116 > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031114#comment-15031114 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031113#comment-15031113 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031115#comment-15031115 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/4.6 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031122#comment-15031122 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1132#issuecomment-160443626 @bhaisaab Let's find someone else who can review this.. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- 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=15031124#comment-15031124 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160444699 @pdube, no, there is a page on cleaning up the API but as the semantic version scheme commands we should only do that cleaning up per version 5.0. see https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes My preference is keeping related calls in one service and not have a Query service, or use it as a backend for the API command > 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=15031129#comment-15031129 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user pdube commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160447903 @DaanHoogland I was talking about the implementation of APIs. Example, let's say you create a new module, call it Exampe. So we can list, create and delete Example. What are the classes that we expect someone to create? ExampleService, ExampleDoa, ExampleVO, etc.? That is what I was refering to. That way, if we decide that the best way to write modules is to have a service that is self contained, then we can phase out the use of the QueryService > 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-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=15031157#comment-15031157 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-160467601 @remibergsma rebased with latest master. There is a conflict with 4.6 because of commit 1a64c247adbeb326f7ddbe6e4feaf3159e9e740d > 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] [Resolved] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-8958. -- Resolution: Fixed > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8958) add dedicated ips to domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou closed CLOUDSTACK-8958. > add dedicated ips to domain > --- > > Key: CLOUDSTACK-8958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > add dedicated ips to domain > ips are dedicated to Account for now, so other customers and projects in the > same domain will use the system ip. this is not what we need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (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:all-tabpanel
]
Wei Zhou closed CLOUDSTACK-9055.
Resolution: Fixed
> 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]
> (RedundantRouterStatusMonitor-5:ctx-db2e782d) Seq 22-1391893759834266982:
> 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:33:18,674 DEBUG [c.c.a.m.AgentAttache]
> (RedundantRouterStatusMonitor-10:ctx-7afb35e1) Seq 22-1391893759834266980:
> Waiting some more time because this is the current command
> 2015-11-11 08:33:18,695 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-8466fef5) Found 4 routers to update status.
> 2015-11-11 08:33:18,697 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-8466fef5) Found 1 VPC networks to update Redundant
> State.
> /RedundantRouterStatusMonitor-10
> 2015-11-11 08:33:18,698 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:ctx-8466fef5) Found 0 networks to update RvR status.
> 2015-11-11 08:33:18,705 DEBUG [c.c.a.t.Request]
> (RedundantRouterStatusMonitor-6:ctx-b997744e) Seq 22-1391893759834266983:
> 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:33:18,706 DEBUG [c.c.a.m.AgentAttache]
> (RedundantRouterStatusMonitor-7:ctx-195132c6) Seq 22-1391893759834266981:
> Waiting some more time because this is the current command
> 2015-11-11 08:33:28,451 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-H
[jira] [Commented] (CLOUDSTACK-9076) Directory /var/lib/cloudstack isn't owned by cloud.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031173#comment-15031173 ] ASF subversion and git services commented on CLOUDSTACK-9076: - Commit 7e64c12067ff067e47cfb92ccd5ab9553f3c5528 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e64c12 ] Merge release branch 4.6 to master * 4.6: CLOUDSTACK-9020: UI enhancements from metrics view CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Cannot list vlanipranges by keyword > Directory /var/lib/cloudstack isn't owned by cloud. > --- > > Key: CLOUDSTACK-9076 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9076 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0, 4.7.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Because the directory /var/lib/cloudstack isn't owned by cloud, the Java > program can't create folders inside for mounting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031162#comment-15031162 ] ASF subversion and git services commented on CLOUDSTACK-9020: - Commit 2733c3835460f063ca3f5e28edfd206fbe836e6a in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2733c38 ] Merge pull request #1106 from shapeblue/4.6-uifixesmetrics [4.6] CLOUDSTACK-9020: UI enhancements from metrics view- Sortable columns - Logos with cloudmonkey - Wider UI - CSS fixes and new status icons - Configurable UI list api requests page size - IP address column on instances page - Listview widget enhancements cc @remibergsma @karuturi * pr/1106: CLOUDSTACK-9020: UI enhancements from metrics view Signed-off-by: Daan Hoogland > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.7.0 > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing metrics > information for these resources in a table which would allow hierarchical > navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances > -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of > quick view), show cells that need attention (such as coloring a tabular cell > where threshold/disable limits have been crossed), allow data to be sorted > and refreshed. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031169#comment-15031169 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031164#comment-15031164 ] ASF subversion and git services commented on CLOUDSTACK-9078: - Commit a44e0b7309e6b65a8d50c016337ced1da5e8990b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a44e0b7 ] Merge pull request #1105 from borisroman/packagingIssues Debian/Ubuntu packaging issuesSee individual issues. I've installed the management server with and without the fix. See difference bellow. Before: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 root root 4096 Nov 23 00:20 . drwxr-xr-x 46 root root 4096 Nov 23 00:21 .. drwxrwx--- 2 root cloud 4096 Nov 17 01:15 management drwxr-xr-x 2 root root 4096 Nov 17 01:15 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:20 . drwxr-xr-x 4 root root 4096 Nov 23 00:20 .. -rw-r--r-- 1 root root 10092 Nov 17 01:15 cloud-install-sys-tmplt -rw-r--r-- 1 root root 10591 Nov 17 01:15 cloud-install-sys-tmplt.py -rw-r--r-- 1 root root 11254 Nov 23 00:20 cloud-install-sys-tmplt.pyc -rw-r--r-- 1 root root 2362 Nov 17 01:15 create_privatetemplate_from_snapshot_xen.sh -rw-r--r-- 1 root root 5446 Nov 17 01:15 createtmplt.sh -rw-r--r-- 1 root root 5388 Nov 17 01:15 createvolume.sh -rw-r--r-- 1 root root 2532 Nov 17 01:15 installIso.sh -rw-r--r-- 1 root root 1622 Nov 17 01:15 listvmtmplt.sh -rw-r--r-- 1 root root 1621 Nov 17 01:15 listvolume.sh -rw-r--r-- 1 root root 75712 Nov 17 01:15 swift ``` After: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 cloud cloud 4096 Nov 23 00:51 . drwxr-xr-x 46 root root 4096 Nov 23 00:53 .. drwxrwx--- 2 cloud cloud 4096 Nov 23 00:33 management drwxr-xr-x 2 cloud cloud 4096 Nov 23 00:33 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:53 . drwxr-xr-x 4 root root 4096 Nov 23 00:53 .. -rwxr-xr-x 1 root root 10092 Nov 23 00:33 cloud-install-sys-tmplt -rwxr-xr-x 1 root root 10591 Nov 23 00:33 cloud-install-sys-tmplt.py -rwxr-xr-x 1 root root 11254 Nov 23 00:53 cloud-install-sys-tmplt.pyc -rwxr-xr-x 1 root root 2362 Nov 23 00:33 create_privatetemplate_from_snapshot_xen.sh -rwxr-xr-x 1 root root 5446 Nov 23 00:33 createtmplt.sh -rwxr-xr-x 1 root root 5388 Nov 23 00:33 createvolume.sh -rwxr-xr-x 1 root root 2532 Nov 23 00:33 installIso.sh -rwxr-xr-x 1 root root 1622 Nov 23 00:33 listvmtmplt.sh -rwxr-xr-x 1 root root 1621 Nov 23 00:33 listvolume.sh -rwxr-xr-x 1 root root 75712 Nov 23 00:33 swift ``` * pr/1105: CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Signed-off-by: Remi Bergsma > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031163#comment-15031163 ] ASF subversion and git services commented on CLOUDSTACK-9020: - Commit 2733c3835460f063ca3f5e28edfd206fbe836e6a in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2733c38 ] Merge pull request #1106 from shapeblue/4.6-uifixesmetrics [4.6] CLOUDSTACK-9020: UI enhancements from metrics view- Sortable columns - Logos with cloudmonkey - Wider UI - CSS fixes and new status icons - Configurable UI list api requests page size - IP address column on instances page - Listview widget enhancements cc @remibergsma @karuturi * pr/1106: CLOUDSTACK-9020: UI enhancements from metrics view Signed-off-by: Daan Hoogland > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.7.0 > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing metrics > information for these resources in a table which would allow hierarchical > navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances > -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of > quick view), show cells that need attention (such as coloring a tabular cell > where threshold/disable limits have been crossed), allow data to be sorted > and refreshed. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031166#comment-15031166 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031170#comment-15031170 ] ASF subversion and git services commented on CLOUDSTACK-9020: - Commit 7e64c12067ff067e47cfb92ccd5ab9553f3c5528 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e64c12 ] Merge release branch 4.6 to master * 4.6: CLOUDSTACK-9020: UI enhancements from metrics view CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Cannot list vlanipranges by keyword > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.7.0 > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing metrics > information for these resources in a table which would allow hierarchical > navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances > -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of > quick view), show cells that need attention (such as coloring a tabular cell > where threshold/disable limits have been crossed), allow data to be sorted > and refreshed. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031171#comment-15031171 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit 7e64c12067ff067e47cfb92ccd5ab9553f3c5528 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e64c12 ] Merge release branch 4.6 to master * 4.6: CLOUDSTACK-9020: UI enhancements from metrics view CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Cannot list vlanipranges by keyword > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031167#comment-15031167 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031172#comment-15031172 ] ASF subversion and git services commented on CLOUDSTACK-9078: - Commit 7e64c12067ff067e47cfb92ccd5ab9553f3c5528 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e64c12 ] Merge release branch 4.6 to master * 4.6: CLOUDSTACK-9020: UI enhancements from metrics view CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Cannot list vlanipranges by keyword > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031168#comment-15031168 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit fe0dc3fac71d4e0a7b0a6c7f42f1b0b25cb47133 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe0dc3f ] Merge pull request #1116 from shapeblue/4.6-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shhttps://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1116: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Remi Bergsma > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9076) Directory /var/lib/cloudstack isn't owned by cloud.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031165#comment-15031165 ] ASF subversion and git services commented on CLOUDSTACK-9076: - Commit a44e0b7309e6b65a8d50c016337ced1da5e8990b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a44e0b7 ] Merge pull request #1105 from borisroman/packagingIssues Debian/Ubuntu packaging issuesSee individual issues. I've installed the management server with and without the fix. See difference bellow. Before: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 root root 4096 Nov 23 00:20 . drwxr-xr-x 46 root root 4096 Nov 23 00:21 .. drwxrwx--- 2 root cloud 4096 Nov 17 01:15 management drwxr-xr-x 2 root root 4096 Nov 17 01:15 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:20 . drwxr-xr-x 4 root root 4096 Nov 23 00:20 .. -rw-r--r-- 1 root root 10092 Nov 17 01:15 cloud-install-sys-tmplt -rw-r--r-- 1 root root 10591 Nov 17 01:15 cloud-install-sys-tmplt.py -rw-r--r-- 1 root root 11254 Nov 23 00:20 cloud-install-sys-tmplt.pyc -rw-r--r-- 1 root root 2362 Nov 17 01:15 create_privatetemplate_from_snapshot_xen.sh -rw-r--r-- 1 root root 5446 Nov 17 01:15 createtmplt.sh -rw-r--r-- 1 root root 5388 Nov 17 01:15 createvolume.sh -rw-r--r-- 1 root root 2532 Nov 17 01:15 installIso.sh -rw-r--r-- 1 root root 1622 Nov 17 01:15 listvmtmplt.sh -rw-r--r-- 1 root root 1621 Nov 17 01:15 listvolume.sh -rw-r--r-- 1 root root 75712 Nov 17 01:15 swift ``` After: ``` root@acs46:~# ls -la /var/lib/cloudstack total 16 drwxr-xr-x 4 cloud cloud 4096 Nov 23 00:51 . drwxr-xr-x 46 root root 4096 Nov 23 00:53 .. drwxrwx--- 2 cloud cloud 4096 Nov 23 00:33 management drwxr-xr-x 2 cloud cloud 4096 Nov 23 00:33 mnt ``` ``` root@acs46:~# ls -la /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/storage/secondary/ total 152 drwxr-xr-x 2 root root 4096 Nov 23 00:53 . drwxr-xr-x 4 root root 4096 Nov 23 00:53 .. -rwxr-xr-x 1 root root 10092 Nov 23 00:33 cloud-install-sys-tmplt -rwxr-xr-x 1 root root 10591 Nov 23 00:33 cloud-install-sys-tmplt.py -rwxr-xr-x 1 root root 11254 Nov 23 00:53 cloud-install-sys-tmplt.pyc -rwxr-xr-x 1 root root 2362 Nov 23 00:33 create_privatetemplate_from_snapshot_xen.sh -rwxr-xr-x 1 root root 5446 Nov 23 00:33 createtmplt.sh -rwxr-xr-x 1 root root 5388 Nov 23 00:33 createvolume.sh -rwxr-xr-x 1 root root 2532 Nov 23 00:33 installIso.sh -rwxr-xr-x 1 root root 1622 Nov 23 00:33 listvmtmplt.sh -rwxr-xr-x 1 root root 1621 Nov 23 00:33 listvolume.sh -rwxr-xr-x 1 root root 75712 Nov 23 00:33 swift ``` * pr/1105: CLOUDSTACK-9078: Gave scripts executable permissions. CLOUDSTACK-9076: Changed ownership of directory /var/lib/cloudstack to cloud. Signed-off-by: Remi Bergsma > Directory /var/lib/cloudstack isn't owned by cloud. > --- > > Key: CLOUDSTACK-9076 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9076 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0, 4.7.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Because the directory /var/lib/cloudstack isn't owned by cloud, the Java > program can't create folders inside for mounting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9081) Unable to convert to json in Storage XenMotion
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-9081.
-
Resolution: Fixed
Fix Version/s: 4.6.1
> Unable to convert to json in Storage XenMotion
> --
>
> Key: CLOUDSTACK-9081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rajani Karuturi
> Fix For: 4.6.1
>
>
> Storage motion of vm across clusters/xenserver-pools fails
> in a clustered management server setup. In xen storage motion we have to send
> a migrate_receive command to the destination host, followed by migrate_send
> command to the source host. The sr and network detials of the destination
> host have to be passed in migrate_send command on the source. While migrating
> across clusters the source and destination resources are seperate objects. To
> pass this information across resources we have to send seperate migrate with
> storage receive and send commands to the resource. In a clustered ms setup
> these commands may have to be forwarded to another ms as the resource may be
> owned by it. The serilization of the command and answer objects fails in such
> case as it doesn't understand the xapi sr and network objects.
> The following JSON conversion error was recorded in management-server2.log.
> {noformat}
> 2015-06-19 10:36:48,507 ERROR [c.c.a.t.Request] (AgentManager-Handler-7:null)
> (logid:) Unable to convert to json:
> [{"com.cloud.agent.api.MigrateWithStorageReceiveAnswer":{"volumeToSr":[{"t":{"id":51828,"name":"Data4","path":"abce3250-8c25-4634-89e3-cef7af6e16b8","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":4},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51729,"name":"ROOT-61290","path":"19a7495d-fb3b-45ef-92e6-e86c017ed1f2","size":53687091200,"type":"ROOT","storagePoolType":"IscsiLUN","storagePoolUuid":"cb398aad-77cc-3916-9e3f-3debec31ff71","deviceId":0},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51826,"name":"Data2","path":"13982b0d-e427-45df-9c7f-b258406bdcd7","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":2},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51825,"name":"Data1","path":"064685fc-1abf-4086-8f81-98dfea2090ce","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":1},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51829,"name":"Data5","path":"85d8ab52-7c79-4338-9433-11a50cb0bbc1","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":5},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}},{"t":{"id":51827,"name":"Data3","path":"7fc80df1-5065-4286-a1c8-87574e798251","size":5368709120,"type":"DATADISK","storagePoolType":"IscsiLUN","storagePoolUuid":"3ae7d68f-8981-34ac-95f0-c67ef3354748","deviceId":12},"u":{"ref":"OpaqueRef:63e4185a-835a-c7e2-4dc3-fbcb95e97872"}}],"nicToNetwork":[{"t":{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"pxeDisable":false,"nicUuid":"45cd68fb-fe60-454c-9a08-f73fd902cef0","uuid":"38a40e2d-0f12-4015-9753-8c08d76d52dc","ip":"172.27.0.113","netmask":"255.255.0.0","gateway":"172.27.0.1","mac":"02:00:59:6b:00:08","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://1109","isolationUri":"vlan://1109","isSecurityGroupEnabled":false,"name":"cloud-public"},"u":{"ref":"OpaqueRef:c9087c77-81f9-03eb-9cf8-df7868354563"}},{"t":{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"pxeDisable":false,"nicUuid":"1504aed4-4871-48d5-abed-581889cea7c7","uuid":"28f3a4f4-dd3d-42d2-b4a4-5243a50232c8","ip":"10.10.10.2","netmask":"255.255.255.0","gateway":"10.10.10.1","mac":"06:a8:b8:00:10:83","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://3339","isolationUri":"vlan://3339","isSecurityGroupEnabled":false,"name":"cloud-public"},"u":{"ref":"OpaqueRef:0110ebab-607d-f02f-134a-383e77324677"}}],"token":{"session_id":"OpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a","host":"OpaqueRef:0d842514-468d-4dd9-5dfe-015ce3898a66","SM":"http://10.32.1.4/services/SM?session_id\u003dOpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a","master":"http://10.13.4.1/","xenops":"http://10.32.1.4/services/xenops?session_id\u003dOpaqueRef:c5929d08-fc30-939b-fd01-0921799fb98a"},"result":true,"contextMap":{},"wait":0}}]
> 2015-06-19 10:36:48,507 WARN [c.c.u.n.Task] (AgentManager-H
[jira] [Created] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
Rajani Karuturi created CLOUDSTACK-9092: --- Summary: G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page Key: CLOUDSTACK-9092 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rajani Karuturi Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, go to Web Console. 3. Choose "Global Settings" on left panel, select "LDAP Configuration", configure LDAP. 4. Choose "Account" on left panel, click "Add LDAP Account" button. 5. Input some characters in LDAP Group input box, check the UI. Expected Result: All strings should be localized on the "Add LDAP Account" page. Actual Result: Some strings are not localized on the "Add LDAP Account" page. Language Info SC -> Fail JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reassigned CLOUDSTACK-9092: --- Assignee: Rajani Karuturi > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9092: Affects Version/s: 4.6.0 > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9092: Attachment: SC.jpg > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9092: Fix Version/s: 4.6.1 > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.6.1 > > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031306#comment-15031306 ] ASF GitHub Bot commented on CLOUDSTACK-8866: Github user maneesha-p commented on the pull request: https://github.com/apache/cloudstack/pull/834#issuecomment-160512875 @remibergsma 2 LGTM s . Can this be merged? > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031310#comment-15031310 ] ASF GitHub Bot commented on CLOUDSTACK-9064: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1117#issuecomment-160513890 Merging on 4.5, since the fix has been tested and merged on 4.6 > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031309#comment-15031309 ] ASF GitHub Bot commented on CLOUDSTACK-9064: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1115#issuecomment-160513845 @remibergsma cool, @abhinandanprateek can you close this; as the other PR has been merged on 4.6 and will be fwd-merged on master to get the fix on master. > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031315#comment-15031315 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit abb7e3fba3080fb19bd2b5699aca09d0fc58b8af in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=abb7e3f ] Merge pull request #1117 from shapeblue/4.5-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Sh https://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1117: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Rohit Yadav > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031314#comment-15031314 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit abb7e3fba3080fb19bd2b5699aca09d0fc58b8af in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=abb7e3f ] Merge pull request #1117 from shapeblue/4.5-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Sh https://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1117: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Rohit Yadav > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031313#comment-15031313 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit abb7e3fba3080fb19bd2b5699aca09d0fc58b8af in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=abb7e3f ] Merge pull request #1117 from shapeblue/4.5-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Sh https://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1117: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Rohit Yadav > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031312#comment-15031312 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit abb7e3fba3080fb19bd2b5699aca09d0fc58b8af in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=abb7e3f ] Merge pull request #1117 from shapeblue/4.5-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Sh https://issues.apache.org/jira/browse/CLOUDSTACK-9064 CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. * pr/1117: CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. Signed-off-by: Rohit Yadav > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031311#comment-15031311 ] ASF subversion and git services commented on CLOUDSTACK-9064: - Commit 2e6c7ce4c8bc98c51d153a595d757bbcc886a2a6 in cloudstack's branch refs/heads/4.5 from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2e6c7ce ] CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031316#comment-15031316 ] ASF GitHub Bot commented on CLOUDSTACK-9064: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1117 > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031317#comment-15031317 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1132#issuecomment-160514080 Thanks @remibergsma Ping @sateesh-chodapuneedi can you review this, and later if you want sent additional PRs with further changes etc. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031318#comment-15031318 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1121#issuecomment-160514198 Verifying this is simple, just check the in the VM's virt xml (virsh edit domain, note the serial in the xml for the disk/volume) and ssh into the VM and check the hdd/vda serial (on debian based systemvm it was available at /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial) > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Kumar Maharana resolved CLOUDSTACK-9068. -- Resolution: Fixed > Listing Port Forwarding Rules take too much time to load > > > Key: CLOUDSTACK-9068 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > ISSUE > == > The performance of listPortForwardingRules slows down dramatically as the > number of rules for an IP increases. If there are 100 rules for an IP and it > takes over a minute to respond. > REPRODUCE STEPS > == > 1) Create many port forwarding rules (75-100) for a particular IP. > 2) View the port forwarding rules for the IP in the UI or directly with the > listPortForwardingRules API command. > 3) Notice the slowness. > EXPECTED BEHAVIOR > == > listPortForwardingRules should always respond in a reasonable time. > ACTUAL BEHAVIOR > == > listPortForwardingRules responds very slowly even with less than 100 rules > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9093) Listing Networks under Project view is throwing error message due to accountid is included in API call
Nitin Kumar Maharana created CLOUDSTACK-9093: Summary: Listing Networks under Project view is throwing error message due to accountid is included in API call Key: CLOUDSTACK-9093 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9093 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Nitin Kumar Maharana Fix For: 4.6.0 Under Projects view when we click on Networks tab, it throws an error that says "“Account and projectId can't be specified together” This is because as part of listing Networks we are also firing listRemoteAccessVpns API for which we are supplying both accountId and projectId parameters. This is not correct since project resources are shared across all accounts. We can’t list individually for an account belonging to a project. Steps to Reproduce 1. Create a project and add an account 2. Go to Project View and choose the Project created 3. Click on Networks tab -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031324#comment-15031324 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user sateesh-chodapuneedi commented on the pull request: https://github.com/apache/cloudstack/pull/1131#issuecomment-160517089 @bhaisaab why are we merging the feature breanch into a 4.5.* maintenance/minor release branch. Shouldn't it be merged into a major release branch/master? BTW, this week I am working towards a PR against ACS master, for this feature branch along with tests. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031325#comment-15031325 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user sateesh-chodapuneedi commented on the pull request: https://github.com/apache/cloudstack/pull/1132#issuecomment-160517214 @bhaisaab why are we merging the feature branch into a 4.6.* maintenance/minor release branch. Shouldn't it be merged into a major release branch/master? BTW, this week I am working towards a PR against ACS master, for this feature branch along with tests. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031354#comment-15031354 ] ASF GitHub Bot commented on CLOUDSTACK-9092: GitHub user karuturi opened a pull request: https://github.com/apache/cloudstack/pull/1139 CLOUDSTACK-9092: L10n fix in "Add LDAP Account page" fixed two strings on the "Add LDAP Account page" After the change: (with a test string in messages_ja_JP.properties file)  You can merge this pull request into a Git repository by running: $ git pull https://github.com/karuturi/cloudstack CLOUDSTACK-9092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1139.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 #1139 commit d6af6adbad707ab378098decca47d8f5e4012872 Author: Rajani Karuturi Date: 2015-11-30T05:51:17Z CLOUDSTACK-9092: L10n fix in "Add LDAP Account page" fixed two strings on the "Add LDAP Account page" > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.6.1 > > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9092: Fix Version/s: (was: 4.6.1) 4.7.0 > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.7.0 > > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031382#comment-15031382 ] ASF GitHub Bot commented on CLOUDSTACK-9092: Github user harikrishna-patnala commented on the pull request: https://github.com/apache/cloudstack/pull/1139#issuecomment-160531359 Looks good to me > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.7.0 > > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR
Harikrishna Patnala created CLOUDSTACK-9094:
---
Summary: Multiple threads are being used to collect the stats from
the same VR
Key: CLOUDSTACK-9094
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, Virtual Router
Affects Versions: 4.6.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
Fix For: 4.7.0
>From the logs we can see that the management server is sending the
>networkusagecommand to a VR twice within a very short interval. This doesn't
>have any impact on the network usage being reported, however it seems to
>consume direct agent threads unnecessarily.
See the below snippet from the logs where networkusage command was sent to the
same VR at the same time
2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-113:null) Seq 10-1242718973: Executing request
2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-113:null) Seq 10-1242718973: Response Received:
2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] (DirectAgent-113:null)
Seq 10-1242718973: Processing: { Ans: , MgmtId: 144027776315500, via: 10, Ver:
v1, Flags: 10,
[{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
}
2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] (RouterMonitor-1:null)
Seq 10-1242718973: Received: { Ans: , MgmtId: 144027776315500, via: 10, Ver:
v1, Flags: 10, { NetworkUsageAnswer } }
2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl]
(RouterMonitor-1:null) Details from executing class
com.cloud.agent.api.NetworkUsageCommand:
2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Seq 10-1242718974: Executing request
2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Seq 10-1242718974: Response Received:
2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] (DirectAgent-244:null)
Seq 10-1242718974: Processing: { Ans: , MgmtId: 144027776315500, via: 10, Ver:
v1, Flags: 10,
[{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
}
2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] (RouterMonitor-1:null)
Seq 10-1242718974: Received: { Ans: , MgmtId: 144027776315500, via: 10, Ver:
v1, Flags: 10, { NetworkUsageAnswer } }
2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl]
(RouterMonitor-1:null) Details from executing class
com.cloud.agent.api.NetworkUsageCommand:
2014-03-04 00:02:07,513 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
Router stats changed from the time NetworkUsageCommand was sent. Ignoring
current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction]
(RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =
-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
called by
-Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701
--
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=15031391#comment-15031391 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160532869 Yes, I understand and it makes sense to have that documented. It doesn't have to mean we phase out QueryService. This makes sense to be there for people with read-only access and it can be used by other services. It also makes sense to consider if Example is a final type of resource or a generic (or implementation of a generic type of resource). A service would be for the whole family, would it? btw @pdube none of my remarks should be interpreted as a -1 to your PR! I like big very much this ;) > 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-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031394#comment-15031394 ] ASF GitHub Bot commented on CLOUDSTACK-8866: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/834#issuecomment-160537225 @maneesha-p Probably not cleanly anymore. I'll give it a shot. > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031396#comment-15031396 ] ASF subversion and git services commented on CLOUDSTACK-8866: - Commit 07ee5e9bf0e167299faef81f41a8514200696b65 in cloudstack's branch refs/heads/master from [~ManeeshaP] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=07ee5e9 ] CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenance > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031398#comment-15031398 ] ASF subversion and git services commented on CLOUDSTACK-8866: - Commit 20dcc25884316b1b1a0c8ff146a84cf02743d88b in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20dcc25 ] Merge pull request #834 from maneesha-p/CLOUDSTACK-8866 CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenanceThe frequency at which Cloudstack tries to migrate the VMs is currently controlled by the global parameter "restart.retry.interval" which has a default value of 600 seconds or 10 minutes.This has to be changed to use "migrate.retry.interval" which by default is 120 seconds or 2 minutes . Cloudstack uses restart.retry.interval for all operations-migrate,restart,stop,destroy. * pr/834: CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenance Signed-off-by: Daan Hoogland > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031399#comment-15031399 ] ASF subversion and git services commented on CLOUDSTACK-8866: - Commit 20dcc25884316b1b1a0c8ff146a84cf02743d88b in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20dcc25 ] Merge pull request #834 from maneesha-p/CLOUDSTACK-8866 CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenanceThe frequency at which Cloudstack tries to migrate the VMs is currently controlled by the global parameter "restart.retry.interval" which has a default value of 600 seconds or 10 minutes.This has to be changed to use "migrate.retry.interval" which by default is 120 seconds or 2 minutes . Cloudstack uses restart.retry.interval for all operations-migrate,restart,stop,destroy. * pr/834: CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenance Signed-off-by: Daan Hoogland > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031400#comment-15031400 ] ASF GitHub Bot commented on CLOUDSTACK-8866: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/834 > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8866) restart.retry.interval is being used instead of migrate.retry.interval during host maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031397#comment-15031397 ] ASF subversion and git services commented on CLOUDSTACK-8866: - Commit 20dcc25884316b1b1a0c8ff146a84cf02743d88b in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20dcc25 ] Merge pull request #834 from maneesha-p/CLOUDSTACK-8866 CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenanceThe frequency at which Cloudstack tries to migrate the VMs is currently controlled by the global parameter "restart.retry.interval" which has a default value of 600 seconds or 10 minutes.This has to be changed to use "migrate.retry.interval" which by default is 120 seconds or 2 minutes . Cloudstack uses restart.retry.interval for all operations-migrate,restart,stop,destroy. * pr/834: CLOUDSTACK-8866 : restart.retry.interval is being used instead of migrate.retry.interval during host maintenance Signed-off-by: Daan Hoogland > restart.retry.interval is being used instead of migrate.retry.interval during > host maintenance > -- > > Key: CLOUDSTACK-8866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Maneesha >Assignee: Maneesha > > The frequency at which Cloudstack tries to migrate the VMs is currently > controlled by the global parameter "restart.retry.interval" which has a > default value of 600 seconds or 10 minutes.This has to be changed to use > "migrate.retry.interval" which by default is 120 seconds or 2 minutes . > Cloudstack uses restart.retry.interval for all > operations-migrate,restart,stop,destroy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031406#comment-15031406
]
ASF GitHub Bot commented on CLOUDSTACK-9094:
GitHub user harikrishna-patnala opened a pull request:
https://github.com/apache/cloudstack/pull/1140
CLOUDSTACK-9094: Multiple threads are being used to collect the stats…
CLOUDSTACK-9094: Multiple threads are being used to collect the stats from
the same VR
Same thread is being intialised by two managers,
VirtualNetworkApplianceManager and VpcVirtualNetworkApplianceManager
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/harikrishna-patnala/cloudstack CLOUDSTACK-9094
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1140.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 #1140
commit c9cc2ccd6dd69bc267ded6e654ec7167a330b6df
Author: Harikrishna Patnala
Date: 2015-11-30T06:44:15Z
CLOUDSTACK-9094: Multiple threads are being used to collect the stats from
the same VR
Same thread is being intialised by two managers,
VirtualNetworkApplianceManager and VpcVirtualNetworkApplianceManager
> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the
> networkusagecommand to a VR twice within a very short interval. This doesn't
> have any impact on the network usage being reported, however it seems to
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (DirectAgent-113:null) Seq 10-1242718973: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718973: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (DirectAgent-244:null) Seq 10-1242718974: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718974: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction]
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-Sched
[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=15031414#comment-15031414
]
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_r46113707
--- Diff: api/src/com/cloud/network/Networks.java ---
@@ -251,6 +252,10 @@ public static URI fromString(String candidate) {
if
(com.cloud.dc.Vlan.UNTAGGED.equalsIgnoreCase(candidate)) {
return Native.toUri(candidate);
}
+if (UuidUtils.validateUUID(candidate)){
+//Supporting lswitch uuid as vlan id: set
broadcast_uri = null and add row on nicira_nvp_router_map with
logicalrouter_uuid = candidate
+return null;
--- End diff --
I've read the comment in the line above a few times, and still cannot
understand the purpose of returning null on an invalid UUID (i.e. you
previously caught a number format exception).
> 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
[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=15031415#comment-15031415
]
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_r46113758
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
---
@@ -671,8 +672,19 @@ public void
doInTransactionWithoutResult(TransactionStatus status) {
vpcId, offering.getRedundantRouter());
vo.setDisplayNetwork(isDisplayNetworkEnabled ==
null ? true : isDisplayNetworkEnabled);
vo.setStrechedL2Network(offering.getSupportsStrechedL2());
-networks.add(_networksDao.persist(vo,
vo.getGuestType() == Network.GuestType.Isolated,
-
finalizeServicesAndProvidersForNetwork(offering, plan.getPhysicalNetworkId(;
+NetworkVO networkPersisted =
_networksDao.persist(vo, vo.getGuestType() == Network.GuestType.Isolated,
+
finalizeServicesAndProvidersForNetwork(offering, plan.getPhysicalNetworkId()));
+networks.add(networkPersisted);
+
+if (predefined instanceof NetworkVO){
+try{
+NetworkGuruAdditionalFunctions functions =
(NetworkGuruAdditionalFunctions) guru;
--- End diff --
This would best be protected with a `instanceof` check.
> 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
[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=15031420#comment-15031420
]
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_r46113829
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
---
@@ -671,8 +672,19 @@ public void
doInTransactionWithoutResult(TransactionStatus status) {
vpcId, offering.getRedundantRouter());
vo.setDisplayNetwork(isDisplayNetworkEnabled ==
null ? true : isDisplayNetworkEnabled);
vo.setStrechedL2Network(offering.getSupportsStrechedL2());
-networks.add(_networksDao.persist(vo,
vo.getGuestType() == Network.GuestType.Isolated,
-
finalizeServicesAndProvidersForNetwork(offering, plan.getPhysicalNetworkId(;
+NetworkVO networkPersisted =
_networksDao.persist(vo, vo.getGuestType() == Network.GuestType.Isolated,
+
finalizeServicesAndProvidersForNetwork(offering, plan.getPhysicalNetworkId()));
+networks.add(networkPersisted);
+
+if (predefined instanceof NetworkVO){
+try{
+NetworkGuruAdditionalFunctions functions =
(NetworkGuruAdditionalFunctions) guru;
+
functions.finalizeNetworkDesign(networkPersisted.getId(),
((NetworkVO)predefined).getVlanIdAsUUID());
+}
+catch (Exception e){
+//Couldn't cast to
NetworkGuruAdditionalFunctions, continue
--- End diff --
The code should not catch exception because it is simply too broad.
Caught exceptions cannot be silently ignored (i.e. having an empty `catch`
block).
> 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
[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=15031424#comment-15031424
]
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_r46114035
--- Diff:
api/src/com/cloud/network/guru/NetworkGuruAdditionalFunctions.java ---
@@ -0,0 +1,12 @@
+package com.cloud.network.guru;
+
+import java.util.Map;
+
+public interface NetworkGuruAdditionalFunctions {
--- End diff --
Several problems with this interface. An interface called functions seems
like it is meant o `patch up` another interface that is lacking functionality.
Secondly, it looks very much NSX specific while the name and package seem quite
generic.
> 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
[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=15031426#comment-15031426
]
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_r46114122
--- Diff: api/src/org/apache/cloudstack/api/response/NicResponse.java ---
@@ -102,6 +102,14 @@
@Param(description = "Id of the vm to which the nic belongs")
private String vmId;
+@SerializedName("nsxlogicalswitch")
+@Param(description = "Id of the NSX Logical Switch (if NSX based),
null otherwise", since="4.6.0")
+private String nsxlogicalswitch;
+
+@SerializedName("nsxlogicalswitchport")
+@Param(description = "Id of the NSX Logical Switch Port (if NSX
based), null otherwise", since="4.6.0")
+private String nsxlogicalswitchport;
--- End diff --
variable naming convention not being followed here.
> 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
[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=15031425#comment-15031425
]
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_r46114108
--- Diff: api/src/org/apache/cloudstack/api/response/NicResponse.java ---
@@ -102,6 +102,14 @@
@Param(description = "Id of the vm to which the nic belongs")
private String vmId;
+@SerializedName("nsxlogicalswitch")
+@Param(description = "Id of the NSX Logical Switch (if NSX based),
null otherwise", since="4.6.0")
+private String nsxlogicalswitch;
--- End diff --
variable naming convention not being followed here. It should be
`nsxLogicalSwitch`
> 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 hy
[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=15031429#comment-15031429
]
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_r46114230
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
---
@@ -671,8 +672,19 @@ public void
doInTransactionWithoutResult(TransactionStatus status) {
vpcId, offering.getRedundantRouter());
vo.setDisplayNetwork(isDisplayNetworkEnabled ==
null ? true : isDisplayNetworkEnabled);
vo.setStrechedL2Network(offering.getSupportsStrechedL2());
-networks.add(_networksDao.persist(vo,
vo.getGuestType() == Network.GuestType.Isolated,
-
finalizeServicesAndProvidersForNetwork(offering, plan.getPhysicalNetworkId(;
+NetworkVO networkPersisted =
_networksDao.persist(vo, vo.getGuestType() == Network.GuestType.Isolated,
--- End diff --
This block adds more code to an already oversized method. This would best
be extracted as a new method or even a new object. This way it would be easier
to read and unit-test.
> 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
> #
[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=15031435#comment-15031435
]
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_r46114312
--- 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 --
This block (and the next) add to an already large method. It would be best
to refactor it to new methods (or a new object altogether).
> 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
[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=15031437#comment-15031437
]
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_r46114646
--- Diff:
plugins/network-elements/nicira-nvp/src/main/java/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
---
@@ -102,11 +112,11 @@ public NiciraNvpGuestNetworkGuru() {
@Override
protected boolean canHandle(final NetworkOffering offering, final
NetworkType networkType, final PhysicalNetwork physicalNetwork) {
// This guru handles only Guest Isolated network that supports
Source nat service
-if (networkType == NetworkType.Advanced &&
isMyTrafficType(offering.getTrafficType()) && offering.getGuestType() ==
Network.GuestType.Isolated
+if (networkType == NetworkType.Advanced &&
isMyTrafficType(offering.getTrafficType())
+&& (offering.getGuestType() == Network.GuestType.Isolated
|| offering.getGuestType() == Network.GuestType.Shared)
--- End diff --
Is this check really needed? I mean `Isolated` and `Shared` are the [only
two types of guest
networks](https://github.com/apache/cloudstack/blob/95ae7963d5652595d62d6ace39de2eec9670413c/api/src/com/cloud/network/Network.java#L41).
If you would like to keep the check for sake of being future proof (that
is, new guest types being added), then refactoring it to a method with a
meaningful name (e.g. supportedGuestTypes(...)) would help readability.
> 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 ta
[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=15031440#comment-15031440
]
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_r46114722
--- Diff:
plugins/network-elements/nicira-nvp/src/main/java/com/cloud/network/resource/wrapper/NiciraNvpConfigureSharedNetworkVlanIdCommandWrapper.java
---
@@ -0,0 +1,93 @@
+//
+// 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.ConfigureSharedNetworkVlanIdAnswer;
+import com.cloud.agent.api.ConfigureSharedNetworkVlanIdCommand;
+import com.cloud.network.nicira.L2GatewayAttachment;
+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.resource.NiciraNvpResource;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+
+@ResourceWrapper(handles = ConfigureSharedNetworkVlanIdCommand.class)
+public class NiciraNvpConfigureSharedNetworkVlanIdCommandWrapper extends
CommandWrapper{
+
+private static final Logger s_logger =
Logger.getLogger(NiciraNvpConfigureSharedNetworkVlanIdCommandWrapper.class);
+
+@Override
+public Answer execute(ConfigureSharedNetworkVlanIdCommand command,
NiciraNvpResource niciraNvpResource) {
+final String logicalSwitchUuid = command.getLogicalSwitchUuid();
+final String l2GatewayServiceUuid =
command.getL2GatewayServiceUuid();
+long vlanId = command.getVlanId();
+final List tags = new ArrayList();
+tags.add(new NiciraNvpTag("cs_account", command.getOwnerName()));
+final long networkId = command.getNetworkId();
+
+s_logger.debug("Connecting Logical Switch " + logicalSwitchUuid +
" to L2 Gateway Service " + l2GatewayServiceUuid + ", vlan id " + vlanId + "
network " + networkId);
+final NiciraNvpApi niciraNvpApi =
niciraNvpResource.getNiciraNvpApi();
+
+LogicalSwitchPort lsp = null;
+try {
+// Create the outside port for the router
+lsp = new LogicalSwitchPort();
+lsp.setAdminStatusEnabled(true);
+lsp.setDisplayName(niciraNvpResource.truncate(networkId +
"-l2Gateway-port", NAME_MAX_LEN));
+lsp.setTags(tags);
+lsp = niciraNvpApi.createLogicalSwitchPort(logicalSwitchUuid,
lsp);
+
+try {
+// Attach the outside port to the gateway service on the
correct VLAN
+final L2GatewayAttachment attachment = new
L2GatewayAttachment(l2GatewayServiceUuid);
+if (command.getVlanId() != 0) {
+attachment.setVlanId(command.getVlanId());
+}
+
niciraNvpApi.updateLogicalSwitchPortAttachment(logicalSwitchUuid,
lsp.getUuid(), attachment);
+}
+catch (NiciraNvpApiException e){
+try {
+
niciraNvpApi.deleteLogicalSwitchPort(logicalSwitchUuid, lsp.getUuid());
+} catch (NiciraNvpApiException e1) {
--- End diff --
Caught exceptions should at least be logged.
> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudSta
