[jira] [Created] (CLOUDSTACK-9760) add support for native container orchestration service
Murali Reddy created CLOUDSTACK-9760: Summary: add support for native container orchestration service Key: CLOUDSTACK-9760 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9760 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.11.0.0 Container technologies are gaining quite a momentum and changing the way how application are traditionally deployed in the public and private clouds. Gaining interest in micro services based architecture also fostering adaption of container technologies. Like how cloud orchestration platforms enabled provisioning of VM's and adjunct services, container orchestration platforms like Kubernetes, docker swarm, mesos are emerging to enable orchestration of containers. Container orchestration platforms typically can be run any where and can be used to provision containers. A popular choice of running containers has been running them on the IAAS provisioned VM's. AWS and GCE provides native functionality to launch containers abstracting underlying consumption of VM's. A container orchestration platform can be provisioned on top of CloudStack using develop tools, but they are not out of the box solution. Given the momentum of container technologies, miro-services etc it make sense to provide a native functionality in CloudStack which is available out-of-the-box for users. FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+container+service+functional+specification+and+design+document -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Comment: was deleted (was: Really need help on this.. will send paypal donation.) > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, cloudstack.tar, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840737#comment-15840737 ] rashmidixit commented on CLOUDSTACK-9359: - Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1700 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840736#comment-15840736 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1700 > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840730#comment-15840730 ] ASF subversion and git services commented on CLOUDSTACK-676: Commit 84e496b4f9d06915fb07e3da330ca270e1e56ec2 in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=84e496b ] CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM This commit implements basic Security Grouping for KVM in Basic Networking. It does not implement full Security Grouping yet, but it does: - Prevent IP-Address source spoofing - Allow DHCPv6 clients, but disallow DHCPv6 servers - Disallow Instances to send out Router Advertisements The Security Grouping allows ICMPv6 packets as described by RFC4890 as they are essential for IPv6 connectivity. Following RFC4890 it allows: - Router Solicitations - Router Advertisements (incoming only) - Neighbor Advertisements - Neighbor Solicitations - Packet Too Big - Time Exceeded - Destination Unreachable - Parameter Problem - Echo Request ICMPv6 is a essential part of IPv6, without it connectivity will break or be very unreliable. For now it allows any UDP and TCP packet to be send in to the Instance which effectively opens up the firewall completely. Future commits will implement Security Grouping further which allows controlling UDP and TCP ports for IPv6 like can be done with IPv4. Regardless of the egress filtering (which can't be done yet) it will always allow outbound DNS to port 53 over UDP or TCP. Signed-off-by: Wido den Hollander > Firewall / ACL support for ipv6 > --- > > Key: CLOUDSTACK-676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chiradeep Vittal >Assignee: Wido den Hollander > Fix For: Future > > > An ability to specify a firewall / ACL rule set for a subnet which has > instances with ipv6 addresses. The implementation can be at the VR level, at > the hypervisor level or in an external firewall -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840732#comment-15840732 ] ASF subversion and git services commented on CLOUDSTACK-9359: - Commit f10c8bfe0c99a762c2606459413a47219614e775 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f10c8bf ] Merge pull request #1700 from wido/ipv6-basic-networking CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very basic IPv6 to Basic Networking. The main goal of this PR is that the API returns a valid IPv6 address over which the Instance is reachable. The GUI will show the IPv6 address after deployment of the Instance. ![screenshot from 2016-10-03 16 34 56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png) If the table VLAN has a proper IPv6 CIDR configured the DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862 In this case the _vlan_ table contained: mysql> select * from vlan \G *** 1. row *** id: 1 uuid: 90e0716c-5261-4992-bb9d-0afd3006f476 vlan_id: vlan://untagged vlan_gateway: 172.16.0.1 vlan_netmask: 255.255.255.0 description: 172.16.0.10-172.16.0.250 vlan_type: DirectAttached data_center_id: 1 network_id: 204 physical_network_id: 200 ip6_gateway: 2001:980:7936:112::1 ip6_cidr: 2001:980:7936:112::/64 ip6_range: NULL removed: NULL created: 2016-07-19 20:39:41 1 row in set (0.00 sec) mysql> It will then log: 2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1 2016-10-04 11:42:45,009 INFO [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e The template has to be configured accordingly: - No IPv6 Privacy Extensions - Use SLAAC - Follow RFC4862 This is also described in: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking The next steps after this will be: - Security Grouping to prevent IPv6 Address Spoofing - Security Grouping to filter ICMP, UDP and TCP traffic * pr/1700: CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM CLOUDSTACK-9359: IPv6 for Basic Networking with KVM Signed-off-by: Rajani Karuturi > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840729#comment-15840729 ] ASF subversion and git services commented on CLOUDSTACK-9359: - Commit c0e7766713b2631a167c2ceea7d42b574a5cd1b9 in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0e7766 ] CLOUDSTACK-9359: IPv6 for Basic Networking with KVM This commit adds the initial functionality for IPv6 in Basic Networking. When a valid IPv6 CIDR is configured for the POD/VLAN the DirectPodBasedNetworkGuru will use the EUI-64 calculation to calculate the IPv6 Address the Instance will obtain. For this it is required that the physical routers in the Layer 2 network (POD/VLAN) send out Router Advertisements with the same subnet as configured in CloudStack. A example subnet could be 2001:db8::/64 Using radvd a Linux Router could send out Router Advertisements using this configuration: interface eth0 { MinRtrAdvInterval 5; MaxRtrAdvInterval 60; AdvSendAdvert on; AdvOtherConfigFlag off; IgnoreIfMissing off; prefix 2001:db8::/64 { }; RDNSS 2001:db8:::53 { }; }; A Instance with MAC Address 06:7a:88:00:00:8b will obtain IPv6 address 2001:db8:100::47a:88ff:fe00:8b Both Windows, Linux and FreeBSD use the same calculation for their IPv6 Addresses, this is specified in RFC4862 (IPv6 Stateless Address Autoconfiguration). Under Linux it is mandatory that IPv6 Privacy Extensions are disabled: $ sysctl -w net.ipv6.conf.all.use_tempaddr=0 Windows should be configured to use the MAC Address as the identifier for the EUI-64/SLAAC calculation. $ netsh interface ipv6 set privacy state=disabled store=persistent $ netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent The IPv6 address is stored in the 'nics' table and is then returned by the API and will be shown in the UI. Searching for a conflicting IPv6 Address it NOT required as each IPv6 address is based on the MAC Address of the Instance and therefor unique. Security Grouping has not been implemented yet and will follow in a upcoming commit. Signed-off-by: Wido den Hollander > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840734#comment-15840734 ] ASF subversion and git services commented on CLOUDSTACK-676: Commit f10c8bfe0c99a762c2606459413a47219614e775 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f10c8bf ] Merge pull request #1700 from wido/ipv6-basic-networking CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very basic IPv6 to Basic Networking. The main goal of this PR is that the API returns a valid IPv6 address over which the Instance is reachable. The GUI will show the IPv6 address after deployment of the Instance. ![screenshot from 2016-10-03 16 34 56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png) If the table VLAN has a proper IPv6 CIDR configured the DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862 In this case the _vlan_ table contained: mysql> select * from vlan \G *** 1. row *** id: 1 uuid: 90e0716c-5261-4992-bb9d-0afd3006f476 vlan_id: vlan://untagged vlan_gateway: 172.16.0.1 vlan_netmask: 255.255.255.0 description: 172.16.0.10-172.16.0.250 vlan_type: DirectAttached data_center_id: 1 network_id: 204 physical_network_id: 200 ip6_gateway: 2001:980:7936:112::1 ip6_cidr: 2001:980:7936:112::/64 ip6_range: NULL removed: NULL created: 2016-07-19 20:39:41 1 row in set (0.00 sec) mysql> It will then log: 2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1 2016-10-04 11:42:45,009 INFO [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e The template has to be configured accordingly: - No IPv6 Privacy Extensions - Use SLAAC - Follow RFC4862 This is also described in: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking The next steps after this will be: - Security Grouping to prevent IPv6 Address Spoofing - Security Grouping to filter ICMP, UDP and TCP traffic * pr/1700: CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM CLOUDSTACK-9359: IPv6 for Basic Networking with KVM Signed-off-by: Rajani Karuturi > Firewall / ACL support for ipv6 > --- > > Key: CLOUDSTACK-676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chiradeep Vittal >Assignee: Wido den Hollander > Fix For: Future > > > An ability to specify a firewall / ACL rule set for a subnet which has > instances with ipv6 addresses. The implementation can be at the VR level, at > the hypervisor level or in an external firewall -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840731#comment-15840731 ] ASF subversion and git services commented on CLOUDSTACK-676: Commit 115d6d5dc774715b0d17238dc8e8d9f02017c690 in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=115d6d5 ] CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking This commit implements Ingress and Egress filtering for IPv6 in Basic Networking. It allows for opening and closing ports just as can be done with IPv4. Rules have to be specified twice, once for IPv4 and once for IPv6, for example: - 22 until 22: 0.0.0.0/0 - 22 until 22: ::/0 Egress filtering works the same as with IPv4. When no rule is applied all traffic is allowed. Otherwise only the specified traffic (with DNS being the exception) is allowed. Signed-off-by: Wido den Hollander > Firewall / ACL support for ipv6 > --- > > Key: CLOUDSTACK-676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chiradeep Vittal >Assignee: Wido den Hollander > Fix For: Future > > > An ability to specify a firewall / ACL rule set for a subnet which has > instances with ipv6 addresses. The implementation can be at the VR level, at > the hypervisor level or in an external firewall -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840733#comment-15840733 ] ASF subversion and git services commented on CLOUDSTACK-676: Commit f10c8bfe0c99a762c2606459413a47219614e775 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f10c8bf ] Merge pull request #1700 from wido/ipv6-basic-networking CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very basic IPv6 to Basic Networking. The main goal of this PR is that the API returns a valid IPv6 address over which the Instance is reachable. The GUI will show the IPv6 address after deployment of the Instance. ![screenshot from 2016-10-03 16 34 56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png) If the table VLAN has a proper IPv6 CIDR configured the DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862 In this case the _vlan_ table contained: mysql> select * from vlan \G *** 1. row *** id: 1 uuid: 90e0716c-5261-4992-bb9d-0afd3006f476 vlan_id: vlan://untagged vlan_gateway: 172.16.0.1 vlan_netmask: 255.255.255.0 description: 172.16.0.10-172.16.0.250 vlan_type: DirectAttached data_center_id: 1 network_id: 204 physical_network_id: 200 ip6_gateway: 2001:980:7936:112::1 ip6_cidr: 2001:980:7936:112::/64 ip6_range: NULL removed: NULL created: 2016-07-19 20:39:41 1 row in set (0.00 sec) mysql> It will then log: 2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1 2016-10-04 11:42:45,009 INFO [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e The template has to be configured accordingly: - No IPv6 Privacy Extensions - Use SLAAC - Follow RFC4862 This is also described in: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking The next steps after this will be: - Security Grouping to prevent IPv6 Address Spoofing - Security Grouping to filter ICMP, UDP and TCP traffic * pr/1700: CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM CLOUDSTACK-9359: IPv6 for Basic Networking with KVM Signed-off-by: Rajani Karuturi > Firewall / ACL support for ipv6 > --- > > Key: CLOUDSTACK-676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chiradeep Vittal >Assignee: Wido den Hollander > Fix For: Future > > > An ability to specify a firewall / ACL rule set for a subnet which has > instances with ipv6 addresses. The implementation can be at the VR level, at > the hypervisor level or in an external firewall -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840735#comment-15840735 ] ASF subversion and git services commented on CLOUDSTACK-9359: - Commit f10c8bfe0c99a762c2606459413a47219614e775 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f10c8bf ] Merge pull request #1700 from wido/ipv6-basic-networking CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very basic IPv6 to Basic Networking. The main goal of this PR is that the API returns a valid IPv6 address over which the Instance is reachable. The GUI will show the IPv6 address after deployment of the Instance. ![screenshot from 2016-10-03 16 34 56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png) If the table VLAN has a proper IPv6 CIDR configured the DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862 In this case the _vlan_ table contained: mysql> select * from vlan \G *** 1. row *** id: 1 uuid: 90e0716c-5261-4992-bb9d-0afd3006f476 vlan_id: vlan://untagged vlan_gateway: 172.16.0.1 vlan_netmask: 255.255.255.0 description: 172.16.0.10-172.16.0.250 vlan_type: DirectAttached data_center_id: 1 network_id: 204 physical_network_id: 200 ip6_gateway: 2001:980:7936:112::1 ip6_cidr: 2001:980:7936:112::/64 ip6_range: NULL removed: NULL created: 2016-07-19 20:39:41 1 row in set (0.00 sec) mysql> It will then log: 2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1 2016-10-04 11:42:45,009 INFO [c.c.n.g.DirectPodBasedNetworkGuru] (Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) (logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e The template has to be configured accordingly: - No IPv6 Privacy Extensions - Use SLAAC - Follow RFC4862 This is also described in: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking The next steps after this will be: - Security Grouping to prevent IPv6 Address Spoofing - Security Grouping to filter ICMP, UDP and TCP traffic * pr/1700: CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM CLOUDSTACK-9359: IPv6 for Basic Networking with KVM Signed-off-by: Rajani Karuturi > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840727#comment-15840727 ] rashmidixit commented on CLOUDSTACK-9359: - Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1700 LGTM. Test results are good. I am merging this now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840726#comment-15840726 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1700 LGTM. Test results are good. I am merging this now. > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840724#comment-15840724 ] rashmidixit commented on CLOUDSTACK-9619: - Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1749 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840723#comment-15840723 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1749 > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840720#comment-15840720 ] ASF subversion and git services commented on CLOUDSTACK-9619: - Commit 4721c53ea005b5b9ff570d5666da93a96d3a1640 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4721c53 ] Merge pull request #1749 from mike-tutkowski/archived_snapshots CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few issues in #1600 (which was recently merged to master for 4.10). In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. In one such scenario, the source snapshot in question is coming from secondary storage (when we are creating a new volume on managed storage from a snapshot of ours thats on secondary storage). This usually worked in the regression tests due to a bit of "luck": We retrieve the ID of the snapshot (which is on secondary storage) and then try to pull out its StorageVO object (which is for primary storage). If you happen to have a primary storage that matches the ID (which is the ID of a secondary storage), then getSnapshotDetails populates its Map with inapplicable data (that is later ignored) and you dont easily see a problem. However, if you dont have a primary storage that matches that ID (which I didnt today because I had removed that primary storage), then a NullPointerException is thrown. I have fixed that issue by skipping getSnapshotDetails if the source is coming from secondary storage. While fixing that, I noticed a couple more problems: 1) We can invoke grantAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). 2) We can invoke revokeAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). I have corrected those issues, as well. I then came across one more problem: When using a SAN snapshot and copying it to secondary storage or creating a new managed-storage volume from a snapshot of ours on secondary storage, we attach to the SR in the XenServer code, but detach from it in the StorageSystemDataMotionStrategy code (by sending a message to the XenServer code to perform an SR detach). Since we know to detach from the SR after the copy is done, we should detach from the SR in the XenServer code (without that code having to be explicitly called from outside of the XenServer logic). I went ahead and changed that, as well. JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 * pr/1749: CLOUDSTACK-9619: Updates for SAN-assisted snapshots Signed-off-by: Rajani Karuturi > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those is
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840718#comment-15840718 ] ASF subversion and git services commented on CLOUDSTACK-9619: - Commit 06806a6523d4c5b46a0345ad62171ed26e843bb8 in cloudstack's branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06806a6 ] CLOUDSTACK-9619: Updates for SAN-assisted snapshots > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840721#comment-15840721 ] ASF subversion and git services commented on CLOUDSTACK-9619: - Commit 4721c53ea005b5b9ff570d5666da93a96d3a1640 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4721c53 ] Merge pull request #1749 from mike-tutkowski/archived_snapshots CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few issues in #1600 (which was recently merged to master for 4.10). In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. In one such scenario, the source snapshot in question is coming from secondary storage (when we are creating a new volume on managed storage from a snapshot of ours thats on secondary storage). This usually worked in the regression tests due to a bit of "luck": We retrieve the ID of the snapshot (which is on secondary storage) and then try to pull out its StorageVO object (which is for primary storage). If you happen to have a primary storage that matches the ID (which is the ID of a secondary storage), then getSnapshotDetails populates its Map with inapplicable data (that is later ignored) and you dont easily see a problem. However, if you dont have a primary storage that matches that ID (which I didnt today because I had removed that primary storage), then a NullPointerException is thrown. I have fixed that issue by skipping getSnapshotDetails if the source is coming from secondary storage. While fixing that, I noticed a couple more problems: 1) We can invoke grantAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). 2) We can invoke revokeAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). I have corrected those issues, as well. I then came across one more problem: When using a SAN snapshot and copying it to secondary storage or creating a new managed-storage volume from a snapshot of ours on secondary storage, we attach to the SR in the XenServer code, but detach from it in the StorageSystemDataMotionStrategy code (by sending a message to the XenServer code to perform an SR detach). Since we know to detach from the SR after the copy is done, we should detach from the SR in the XenServer code (without that code having to be explicitly called from outside of the XenServer logic). I went ahead and changed that, as well. JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 * pr/1749: CLOUDSTACK-9619: Updates for SAN-assisted snapshots Signed-off-by: Rajani Karuturi > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those is
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840719#comment-15840719 ] ASF subversion and git services commented on CLOUDSTACK-9619: - Commit 4721c53ea005b5b9ff570d5666da93a96d3a1640 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4721c53 ] Merge pull request #1749 from mike-tutkowski/archived_snapshots CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few issues in #1600 (which was recently merged to master for 4.10). In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. In one such scenario, the source snapshot in question is coming from secondary storage (when we are creating a new volume on managed storage from a snapshot of ours thats on secondary storage). This usually worked in the regression tests due to a bit of "luck": We retrieve the ID of the snapshot (which is on secondary storage) and then try to pull out its StorageVO object (which is for primary storage). If you happen to have a primary storage that matches the ID (which is the ID of a secondary storage), then getSnapshotDetails populates its Map with inapplicable data (that is later ignored) and you dont easily see a problem. However, if you dont have a primary storage that matches that ID (which I didnt today because I had removed that primary storage), then a NullPointerException is thrown. I have fixed that issue by skipping getSnapshotDetails if the source is coming from secondary storage. While fixing that, I noticed a couple more problems: 1) We can invoke grantAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). 2) We can invoke revokeAccess on a snapshot thats actually on secondary storage (this doesnt amount to much because the VolumeServiceImpl ignores the call when its not for a primary-storage driver). I have corrected those issues, as well. I then came across one more problem: When using a SAN snapshot and copying it to secondary storage or creating a new managed-storage volume from a snapshot of ours on secondary storage, we attach to the SR in the XenServer code, but detach from it in the StorageSystemDataMotionStrategy code (by sending a message to the XenServer code to perform an SR detach). Since we know to detach from the SR after the copy is done, we should detach from the SR in the XenServer code (without that code having to be explicitly called from outside of the XenServer logic). I went ahead and changed that, as well. JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 * pr/1749: CLOUDSTACK-9619: Updates for SAN-assisted snapshots Signed-off-by: Rajani Karuturi > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those is
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840715#comment-15840715 ] rashmidixit commented on CLOUDSTACK-9619: - Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1749 LGTM. From the discussion, looks like the test failures are unrelated to this PR. merging this now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840714#comment-15840714 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1749 LGTM. From the discussion, looks like the test failures are unrelated to this PR. merging this now. > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840694#comment-15840694 ] ASF GitHub Bot commented on CLOUDSTACK-9729: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1904 > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840695#comment-15840695 ] rashmidixit commented on CLOUDSTACK-9729: - Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1904 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840693#comment-15840693 ] ASF subversion and git services commented on CLOUDSTACK-9729: - Commit a4061026b6827515aa54367662d86b2174c62899 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a406102 ] Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729 CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use Amazon WS 11.1.16 caused our client to fail, as it was depending on classes, which are not not present anymore. Latest client version uses Gson instead. BUG-ID: CLOUDSTACK-9729 Bugfix-for: master * pr/1904: Use latest Nuage client. Signed-off-by: Rajani Karuturi > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840690#comment-15840690 ] ASF subversion and git services commented on CLOUDSTACK-9729: - Commit f246de5e9385f3ac6cc1fdb88c3a6ca5f26cc4a8 in cloudstack's branch refs/heads/master from [~fmaximus] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f246de5 ] Use latest Nuage client. * CloudStack root pom change to use Amazon WS 11.1.16 caused our client to fail, as it was depending on classes, which are not not present anymore. Latest client version uses Gson instead. * increase robustness of nuagevsp tests `- test_nuage_internal_dns - move vm2 creation upwards `- test_nuage_static_nat - delete vm in test step to avoid sut restriction BUG-ID: CLOUDSTACK-9729i Co-Authored-By: Raf Smeets Bugfix-for: master > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840691#comment-15840691 ] ASF subversion and git services commented on CLOUDSTACK-9729: - Commit a4061026b6827515aa54367662d86b2174c62899 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a406102 ] Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729 CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use Amazon WS 11.1.16 caused our client to fail, as it was depending on classes, which are not not present anymore. Latest client version uses Gson instead. BUG-ID: CLOUDSTACK-9729 Bugfix-for: master * pr/1904: Use latest Nuage client. Signed-off-by: Rajani Karuturi > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840692#comment-15840692 ] ASF subversion and git services commented on CLOUDSTACK-9729: - Commit a4061026b6827515aa54367662d86b2174c62899 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a406102 ] Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729 CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use Amazon WS 11.1.16 caused our client to fail, as it was depending on classes, which are not not present anymore. Latest client version uses Gson instead. BUG-ID: CLOUDSTACK-9729 Bugfix-for: master * pr/1904: Use latest Nuage client. Signed-off-by: Rajani Karuturi > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840681#comment-15840681 ] Michael edited comment on CLOUDSTACK-9759 at 1/26/17 11:44 PM: --- Really need help on this.. will send paypal donation. was (Author: mabarkdoll): Really need help on this.. well send paypal donation. > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, cloudstack.tar, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840681#comment-15840681 ] Michael commented on CLOUDSTACK-9759: - Really need help on this.. well send paypal donation. > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, cloudstack.tar, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840679#comment-15840679 ] rashmidixit commented on CLOUDSTACK-9729: - Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1904 LGTM merging now --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840678#comment-15840678 ] ASF GitHub Bot commented on CLOUDSTACK-9729: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1904 LGTM merging now > Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to > com.amazonaws.util.json.JSONException > --- > > Key: CLOUDSTACK-9729 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Kris Sterckx >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.10.0.0 > > > https://github.com/apache/cloudstack/pull/1638 has moved from > {noformat} > 1.10.64 > {noformat} > to > {noformat} > 1.11.61 > {noformat} > which breaks the use of com.amazonaws.util.json.JSONException > This breaks Nuage VSP network plugin as of its dependency to > {noformat} > net.nuagenetworks.vsp > nuage-vsp-acs-client > 1.0.0 > {noformat} > > We need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840274#comment-15840274 ] rashmidixit commented on CLOUDSTACK-8672: - Github user nitin-maharana commented on the issue: https://github.com/apache/cloudstack/pull/1859 Sure @rajesh-battala, will look at that. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840273#comment-15840273 ] ASF GitHub Bot commented on CLOUDSTACK-8672: Github user nitin-maharana commented on the issue: https://github.com/apache/cloudstack/pull/1859 Sure @rajesh-battala, will look at that. > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Attachment: cloudstack.tar cloudstack.tar added contains all of /etc/cloudstack from VPC VR > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, cloudstack.tar, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Attachment: messages VPC VR /var/log/messages > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840184#comment-15840184 ] Michael edited comment on CLOUDSTACK-9759 at 1/26/17 6:34 PM: -- VPC VR /var/log/messages added was (Author: mabarkdoll): VPC VR /var/log/messages > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log, messages > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Remaining Estimate: (was: 24h) Original Estimate: (was: 24h) > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log > > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Summary: VPC VR ips.json ethNone instead of eth1 (was: VPC VR not obtaining ip address) > VPC VR ips.json ethNone instead of eth1 > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log > > Original Estimate: 24h > Remaining Estimate: 24h > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR not obtaining ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Priority: Critical (was: Major) > VPC VR not obtaining ip address > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael >Priority: Critical > Attachments: cloud.log > > Original Estimate: 24h > Remaining Estimate: 24h > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9759) VPC VR not obtaining ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840173#comment-15840173 ] Michael commented on CLOUDSTACK-9759: - Please let me know, if you need more logs. ip addr on the VR only shows the link-local without modifying (/etc/cloudstack/ips.json) and restarting the VR. My understanding is the management server sends the json to the host and the host delivers the ips.json to the VR. Can I check something to see why ethNone is being passed instead of eth1 at some point? > VPC VR not obtaining ip address > --- > > Key: CLOUDSTACK-9759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.2.0 > Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans > for guest and public >Reporter: Michael > Attachments: cloud.log > > Original Estimate: 24h > Remaining Estimate: 24h > > Cloudstack deployment with advanced networking. > My VPC VR is incorrectly be assigned ethNone inside > (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit > /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and > restart the VPC then the network works for isolated guest networks attached > to the VPC VR and the VR itself. (note: this issue only occurs with the VPC > VR not with guest network or guest shared networks). > Here is the contents of /etc/cloudstack/ips.json > root@r31-VM# cat /etc/cloudstack/ips.json > { > "eth0": [ > { > "add": true, > "broadcast": "169.254.255.255", > "cidr": "169.254.1.203/16", > "device": "eth0", > "gateway": "None", > "netmask": "255.255.0.0", > "network": "169.254.0.0/16", > "nic_dev_id": "0", > "nw_type": "control", > "one_to_one_nat": false, > "public_ip": "169.254.1.203", > "size": "16", > "source_nat": false > } > ], > "eth2": [ > { > "add": true, > "broadcast": "10.1.1.255", > "cidr": "10.1.1.1/24", > "device": "eth2", > "gateway": "10.1.1.1", > "netmask": "255.255.255.0", > "network": "10.1.1.0/24", > "nic_dev_id": "2", > "nw_type": "guest", > "one_to_one_nat": false, > "public_ip": "10.1.1.1", > "size": "24", > "source_nat": false > } > ], > "ethNone": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "ethNone", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > "id": "ips" > } > After modifying the file ethNone to eth1 then the VPC VR has internet via > Public network vlan 165 trunked that bridges to cloudbr1. > "eth1": [ > { > "add": true, > "broadcast": "10.100.71.255", > "cidr": "10.100.66.3/21", > "device": "eth1", > "first_i_p": false, > "gateway": "10.100.71.254", > "netmask": "255.255.248.0", > "network": "10.100.64.0/21", > "new_nic": false, > "nw_type": "public", > "one_to_one_nat": false, > "public_ip": "10.100.66.3", > "size": "21", > "source_nat": true, > "vif_mac_address": "06:56:74:00:06:2c" > } > ], > Public network details: > gateway 10.100.71.254 > ip range: 10.100.66.1 - 10.100.67.254 > Netmask: 255.255.248.0 /21 > eth1 on VPC VR is the Public network interface > Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host > computer. > I'm also attaching the /var/log/cloud.log from the VPC VR > Note: I restarted the VR several times attempting other > /etc/network/interfaces changes before I read on how the VPC VR runs scripts > to configure the nics, but the final restart had the reflected changes that > causes things to work. > Cloudstack is using KVM hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9759) VPC VR not obtaining ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael updated CLOUDSTACK-9759: Description: Cloudstack deployment with advanced networking. My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and restart the VPC then the network works for isolated guest networks attached to the VPC VR and the VR itself. (note: this issue only occurs with the VPC VR not with guest network or guest shared networks). Here is the contents of /etc/cloudstack/ips.json root@r31-VM# cat /etc/cloudstack/ips.json { "eth0": [ { "add": true, "broadcast": "169.254.255.255", "cidr": "169.254.1.203/16", "device": "eth0", "gateway": "None", "netmask": "255.255.0.0", "network": "169.254.0.0/16", "nic_dev_id": "0", "nw_type": "control", "one_to_one_nat": false, "public_ip": "169.254.1.203", "size": "16", "source_nat": false } ], "eth2": [ { "add": true, "broadcast": "10.1.1.255", "cidr": "10.1.1.1/24", "device": "eth2", "gateway": "10.1.1.1", "netmask": "255.255.255.0", "network": "10.1.1.0/24", "nic_dev_id": "2", "nw_type": "guest", "one_to_one_nat": false, "public_ip": "10.1.1.1", "size": "24", "source_nat": false } ], "ethNone": [ { "add": true, "broadcast": "10.100.71.255", "cidr": "10.100.66.3/21", "device": "ethNone", "first_i_p": false, "gateway": "10.100.71.254", "netmask": "255.255.248.0", "network": "10.100.64.0/21", "new_nic": false, "nw_type": "public", "one_to_one_nat": false, "public_ip": "10.100.66.3", "size": "21", "source_nat": true, "vif_mac_address": "06:56:74:00:06:2c" } ], "id": "ips" } After modifying the file ethNone to eth1 then the VPC VR has internet via Public network vlan 165 trunked that bridges to cloudbr1. "eth1": [ { "add": true, "broadcast": "10.100.71.255", "cidr": "10.100.66.3/21", "device": "eth1", "first_i_p": false, "gateway": "10.100.71.254", "netmask": "255.255.248.0", "network": "10.100.64.0/21", "new_nic": false, "nw_type": "public", "one_to_one_nat": false, "public_ip": "10.100.66.3", "size": "21", "source_nat": true, "vif_mac_address": "06:56:74:00:06:2c" } ], Public network details: gateway 10.100.71.254 ip range: 10.100.66.1 - 10.100.67.254 Netmask: 255.255.248.0 /21 eth1 on VPC VR is the Public network interface Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host computer. I'm also attaching the /var/log/cloud.log from the VPC VR Note: I restarted the VR several times attempting other /etc/network/interfaces changes before I read on how the VPC VR runs scripts to configure the nics, but the final restart had the reflected changes that causes things to work. Cloudstack is using KVM hypervisor. was: Cloudstack deployment with advanced networking. My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and restart the VPC then the network works for isolated guest networks attached to the VPC VR and the VR itself. (note: this issue only occurs with the VPC VR not with guest network or guest shared networks). Here is the contents of /etc/cloudstack/ips.json root@r31-VM# cat /etc/cloudstack/ips.json { "eth0": [ { "add": true, "broadcast": "169.254.255.255", "cidr": "169.254.1.203/16", "device": "eth0", "gateway": "None", "netmask": "255.255.0.0", "network": "169.254.0.0/16", "nic_dev_id": "0", "nw_type": "control", "one_to_one_nat": false, "public_ip": "169.254.1.203", "size": "16", "source_nat": false } ], "eth2": [ { "add": true, "broadcast": "10.1.1.255", "cidr": "10.1.1.1/24", "device": "eth2", "gateway": "10.1.1.1", "netmask": "255.255.255.0", "network": "10.1.1.0/24", "nic_dev_id": "2",
[jira] [Created] (CLOUDSTACK-9759) VPC VR not obtaining ip address
Michael created CLOUDSTACK-9759: --- Summary: VPC VR not obtaining ip address Key: CLOUDSTACK-9759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.9.2.0 Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans for guest and public Reporter: Michael Attachments: cloud.log Cloudstack deployment with advanced networking. My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) for my eth1 public network interface. If I edit /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and restart the VPC then the network works for isolated guest networks attached to the VPC VR and the VR itself. (note: this issue only occurs with the VPC VR not with guest network or guest shared networks). Here is the contents of /etc/cloudstack/ips.json root@r31-VM# cat /etc/cloudstack/ips.json { "eth0": [ { "add": true, "broadcast": "169.254.255.255", "cidr": "169.254.1.203/16", "device": "eth0", "gateway": "None", "netmask": "255.255.0.0", "network": "169.254.0.0/16", "nic_dev_id": "0", "nw_type": "control", "one_to_one_nat": false, "public_ip": "169.254.1.203", "size": "16", "source_nat": false } ], "eth2": [ { "add": true, "broadcast": "10.1.1.255", "cidr": "10.1.1.1/24", "device": "eth2", "gateway": "10.1.1.1", "netmask": "255.255.255.0", "network": "10.1.1.0/24", "nic_dev_id": "2", "nw_type": "guest", "one_to_one_nat": false, "public_ip": "10.1.1.1", "size": "24", "source_nat": false } ], "ethNone": [ { "add": true, "broadcast": "10.100.71.255", "cidr": "10.100.66.3/21", "device": "ethNone", "first_i_p": false, "gateway": "10.100.71.254", "netmask": "255.255.248.0", "network": "10.100.64.0/21", "new_nic": false, "nw_type": "public", "one_to_one_nat": false, "public_ip": "10.100.66.3", "size": "21", "source_nat": true, "vif_mac_address": "06:56:74:00:06:2c" } ], "id": "ips" } After modifying the file ethNone to eth1 then the VPC VR has internet via Public network vlan 165 trunked that bridges to cloudbr1. "eth1": [ { "add": true, "broadcast": "10.100.71.255", "cidr": "10.100.66.3/21", "device": "eth1", "first_i_p": false, "gateway": "10.100.71.254", "netmask": "255.255.248.0", "network": "10.100.64.0/21", "new_nic": false, "nw_type": "public", "one_to_one_nat": false, "public_ip": "10.100.66.3", "size": "21", "source_nat": true, "vif_mac_address": "06:56:74:00:06:2c" } ], Public network details: gateway 10.100.71.254 ip range: 10.100.66.1 - 10.100.67.254 Netmask: 255.255.248.0 /21 eth1 on VPC VR is the Public network interface Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host computer. I'm also attaching the /var/log/cloud.log from the VPC VR Note: I restarted the VR several times attempting other /etc/network/interfaces changes before I read on how the VPC VR runs scripts to configure the nics, but the final restart had the reflected changes that causes things to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839931#comment-15839931 ] ASF GitHub Bot commented on CLOUDSTACK-8672: Github user rajesh-battala commented on the issue: https://github.com/apache/cloudstack/pull/1859 @nitin-maharana @sowmyakrishn Can you please check why CI tests are failing? > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839932#comment-15839932 ] rashmidixit commented on CLOUDSTACK-8672: - Github user rajesh-battala commented on the issue: https://github.com/apache/cloudstack/pull/1859 @nitin-maharana @sowmyakrishn Can you please check why CI tests are failing? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839809#comment-15839809 ] rashmidixit commented on CLOUDSTACK-9359: - Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1700 I rebased the code against master and it is compiling with Java 8 and passing all tests. ```[INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 8:59.691s (Wall Clock) [INFO] Finished at: Thu Jan 26 15:45:36 CET 2017 [INFO] Final Memory: 105M/1555M [INFO] ``` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839813#comment-15839813 ] rashmidixit commented on CLOUDSTACK-9462: - Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1916 Good point to remove Ubuntu 12.04 in 4.10. I didn't notice this is for 4.9. Not really paid attention to it. I personally dislike the moving of the control file while building the deps though. Don't see another way however. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839810#comment-15839810 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1916 Good point to remove Ubuntu 12.04 in 4.10. I didn't notice this is for 4.9. Not really paid attention to it. I personally dislike the moving of the control file while building the deps though. Don't see another way however. > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839805#comment-15839805 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1700 I rebased the code against master and it is compiling with Java 8 and passing all tests. ```[INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 8:59.691s (Wall Clock) [INFO] Finished at: Thu Jan 26 15:45:36 CET 2017 [INFO] Final Memory: 105M/1555M [INFO] ``` > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)