Re: Cloudstack 4.11 - Ubuntu 16.04 Agent UFW firewall issues
Hi Glen, Are you using basic or advanced zone? How is your networking configured on your KVM host? My guess is you run guest traffic and management traffic on the same NICs? Regards, Dag Sonstebo Cloud Architect ShapeBlue On 12/06/2018, 04:40, "Glen Baars" wrote: Hello Devs, When we deployed cloudstack 4.11.0 into production, we found that the UFW rules for the KVM host overrides the firewall rules set by the user in cloudstack. This prevented network access to the VMs on most ports. We followed the guide on this page for the advanced zone – ubuntu. http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.11/hypervisor/kvm.html Disabling UFW on the KVM host fixed the issue but obviously not a great solution ☹ Is there any logging that would help? I have a spare server in the production cluster that I can test the issue on. Kind regards, Glen Baars This e-mail is intended solely for the benefit of the addressee(s) and any other named recipient. It is confidential and may contain legally privileged or confidential information. If you are not the recipient, any use, distribution, disclosure or copying of this e-mail is prohibited. The confidentiality and legal privilege attached to this communication is not waived or lost by reason of the mistaken transmission or delivery to you. If you have received this e-mail in error, please notify us immediately. dag.sonst...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
Why does a VLAN and Network have IP information?
Hi, Looking at our design and tables in the database I'm wondering why both a VLAN and a Network has IP information. A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information and we also seem to store redundant information in there. Below is some information I have in a test database and I'm just trying to understand why both have IP information. Imho this information should not be stored in the VLAN table as it's redundant anyway. But still, why is it there? And why do we actually use the VLAN table? Because even the VLAN tag is stored in the *networks* table. Wido mysql> select * from vlan limit 1 \G *** 1. row *** id: 1 uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d vlan_id: 0 vlan_gateway: 192.168.200.1 vlan_netmask: 255.255.255.0 description: 192.168.200.100-192.168.200.200 vlan_type: DirectAttached data_center_id: 1 network_id: 203 physical_network_id: 200 ip6_gateway: 2001:db8:100::1 ip6_cidr: 2001:db8:100::/64 ip6_range: NULL removed: NULL created: 2018-06-09 18:53:26 1 row in set (0.00 sec) mysql> mysql> select * from networks where id = 203 \G *** 1. row *** id: 203 name: GuestNetwork1 uuid: f1f7281d-bedd-422c-bd44-eae9be172157 display_text: GuestNetwork1 traffic_type: Guest broadcast_domain_type: Vlan broadcast_uri: vlan://untagged gateway: 192.168.200.1 cidr: 192.168.200.0/24 mode: Dhcp network_offering_id: 6 physical_network_id: 200 data_center_id: 1 guru_name: DirectNetworkGuru state: Setup related: 203 domain_id: 1 account_id: 1 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Domain network_domain: cs1cloud.internal reservation_id: NULL guest_type: Shared restart_required: 0 created: 2018-06-09 18:53:26 removed: NULL specify_ip_ranges: 1 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 redundant: 0 external_id: NULL 1 row in set (0.01 sec) mysql>
Re: Why does a VLAN and Network have IP information?
Wido, I think we can remove ip data from the vlan table, though it is going to require some hacking. Removing the vlan table seems not prudent to me, especially since we now have l2 networks (without ip provisioned). On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander wrote: > Hi, > > Looking at our design and tables in the database I'm wondering why both > a VLAN and a Network has IP information. > > A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information > and we also seem to store redundant information in there. > > Below is some information I have in a test database and I'm just trying > to understand why both have IP information. > > Imho this information should not be stored in the VLAN table as it's > redundant anyway. But still, why is it there? And why do we actually use > the VLAN table? Because even the VLAN tag is stored in the *networks* > table. > > Wido > > mysql> select * from vlan limit 1 \G > *** 1. row *** > id: 1 >uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d > vlan_id: 0 >vlan_gateway: 192.168.200.1 >vlan_netmask: 255.255.255.0 > description: 192.168.200.100-192.168.200.200 > vlan_type: DirectAttached > data_center_id: 1 > network_id: 203 > physical_network_id: 200 > ip6_gateway: 2001:db8:100::1 >ip6_cidr: 2001:db8:100::/64 > ip6_range: NULL > removed: NULL > created: 2018-06-09 18:53:26 > 1 row in set (0.00 sec) > > mysql> > > mysql> select * from networks where id = 203 \G > *** 1. row *** >id: 203 > name: GuestNetwork1 > uuid: f1f7281d-bedd-422c-bd44-eae9be172157 > display_text: GuestNetwork1 > traffic_type: Guest > broadcast_domain_type: Vlan > broadcast_uri: vlan://untagged > gateway: 192.168.200.1 > cidr: 192.168.200.0/24 > mode: Dhcp > network_offering_id: 6 > physical_network_id: 200 >data_center_id: 1 > guru_name: DirectNetworkGuru > state: Setup > related: 203 > domain_id: 1 >account_id: 1 > dns1: NULL > dns2: NULL > guru_data: NULL >set_fields: 0 > acl_type: Domain >network_domain: cs1cloud.internal >reservation_id: NULL >guest_type: Shared > restart_required: 0 > created: 2018-06-09 18:53:26 > removed: NULL > specify_ip_ranges: 1 >vpc_id: NULL > ip6_gateway: NULL > ip6_cidr: NULL > network_cidr: NULL > display_network: 1 >network_acl_id: NULL > streched_l2: 0 > redundant: 0 > external_id: NULL > 1 row in set (0.01 sec) > > mysql> > -- Daan
Re: Why does a VLAN and Network have IP information?
In theory, the object (either in Java or a DB table) that represents a VLAN should not have IP information. However, it seems that someone “reused” the object. We would need to check if the IP data stored there is not really used before removing it. On Tue, Jun 12, 2018 at 11:32 AM, Daan Hoogland wrote: > Wido, I think we can remove ip data from the vlan table, though it is going > to require some hacking. Removing the vlan table seems not prudent to me, > especially since we now have l2 networks (without ip provisioned). > > On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander > wrote: > > > Hi, > > > > Looking at our design and tables in the database I'm wondering why both > > a VLAN and a Network has IP information. > > > > A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information > > and we also seem to store redundant information in there. > > > > Below is some information I have in a test database and I'm just trying > > to understand why both have IP information. > > > > Imho this information should not be stored in the VLAN table as it's > > redundant anyway. But still, why is it there? And why do we actually use > > the VLAN table? Because even the VLAN tag is stored in the *networks* > > table. > > > > Wido > > > > mysql> select * from vlan limit 1 \G > > *** 1. row *** > > id: 1 > >uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d > > vlan_id: 0 > >vlan_gateway: 192.168.200.1 > >vlan_netmask: 255.255.255.0 > > description: 192.168.200.100-192.168.200.200 > > vlan_type: DirectAttached > > data_center_id: 1 > > network_id: 203 > > physical_network_id: 200 > > ip6_gateway: 2001:db8:100::1 > >ip6_cidr: 2001:db8:100::/64 > > ip6_range: NULL > > removed: NULL > > created: 2018-06-09 18:53:26 > > 1 row in set (0.00 sec) > > > > mysql> > > > > mysql> select * from networks where id = 203 \G > > *** 1. row *** > >id: 203 > > name: GuestNetwork1 > > uuid: f1f7281d-bedd-422c-bd44-eae9be172157 > > display_text: GuestNetwork1 > > traffic_type: Guest > > broadcast_domain_type: Vlan > > broadcast_uri: vlan://untagged > > gateway: 192.168.200.1 > > cidr: 192.168.200.0/24 > > mode: Dhcp > > network_offering_id: 6 > > physical_network_id: 200 > >data_center_id: 1 > > guru_name: DirectNetworkGuru > > state: Setup > > related: 203 > > domain_id: 1 > >account_id: 1 > > dns1: NULL > > dns2: NULL > > guru_data: NULL > >set_fields: 0 > > acl_type: Domain > >network_domain: cs1cloud.internal > >reservation_id: NULL > >guest_type: Shared > > restart_required: 0 > > created: 2018-06-09 18:53:26 > > removed: NULL > > specify_ip_ranges: 1 > >vpc_id: NULL > > ip6_gateway: NULL > > ip6_cidr: NULL > > network_cidr: NULL > > display_network: 1 > >network_acl_id: NULL > > streched_l2: 0 > > redundant: 0 > > external_id: NULL > > 1 row in set (0.01 sec) > > > > mysql> > > > > > > -- > Daan > -- Rafael Weingärtner
Re: Why does a VLAN and Network have IP information?
Hi, Devs, ipv6 in vlan table is used. Without the information in that table, ipv6 wouldn't work with basic zone. вт, 12 июн. 2018 г., 13:11 Rafael Weingärtner : > In theory, the object (either in Java or a DB table) that represents a VLAN > should not have IP information. However, it seems that someone “reused” the > object. We would need to check if the IP data stored there is not really > used before removing it. > > > On Tue, Jun 12, 2018 at 11:32 AM, Daan Hoogland > wrote: > > > Wido, I think we can remove ip data from the vlan table, though it is > going > > to require some hacking. Removing the vlan table seems not prudent to me, > > especially since we now have l2 networks (without ip provisioned). > > > > On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander > > wrote: > > > > > Hi, > > > > > > Looking at our design and tables in the database I'm wondering why both > > > a VLAN and a Network has IP information. > > > > > > A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information > > > and we also seem to store redundant information in there. > > > > > > Below is some information I have in a test database and I'm just trying > > > to understand why both have IP information. > > > > > > Imho this information should not be stored in the VLAN table as it's > > > redundant anyway. But still, why is it there? And why do we actually > use > > > the VLAN table? Because even the VLAN tag is stored in the *networks* > > > table. > > > > > > Wido > > > > > > mysql> select * from vlan limit 1 \G > > > *** 1. row *** > > > id: 1 > > >uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d > > > vlan_id: 0 > > >vlan_gateway: 192.168.200.1 > > >vlan_netmask: 255.255.255.0 > > > description: 192.168.200.100-192.168.200.200 > > > vlan_type: DirectAttached > > > data_center_id: 1 > > > network_id: 203 > > > physical_network_id: 200 > > > ip6_gateway: 2001:db8:100::1 > > >ip6_cidr: 2001:db8:100::/64 > > > ip6_range: NULL > > > removed: NULL > > > created: 2018-06-09 18:53:26 > > > 1 row in set (0.00 sec) > > > > > > mysql> > > > > > > mysql> select * from networks where id = 203 \G > > > *** 1. row *** > > >id: 203 > > > name: GuestNetwork1 > > > uuid: f1f7281d-bedd-422c-bd44-eae9be172157 > > > display_text: GuestNetwork1 > > > traffic_type: Guest > > > broadcast_domain_type: Vlan > > > broadcast_uri: vlan://untagged > > > gateway: 192.168.200.1 > > > cidr: 192.168.200.0/24 > > > mode: Dhcp > > > network_offering_id: 6 > > > physical_network_id: 200 > > >data_center_id: 1 > > > guru_name: DirectNetworkGuru > > > state: Setup > > > related: 203 > > > domain_id: 1 > > >account_id: 1 > > > dns1: NULL > > > dns2: NULL > > > guru_data: NULL > > >set_fields: 0 > > > acl_type: Domain > > >network_domain: cs1cloud.internal > > >reservation_id: NULL > > >guest_type: Shared > > > restart_required: 0 > > > created: 2018-06-09 18:53:26 > > > removed: NULL > > > specify_ip_ranges: 1 > > >vpc_id: NULL > > > ip6_gateway: NULL > > > ip6_cidr: NULL > > > network_cidr: NULL > > > display_network: 1 > > >network_acl_id: NULL > > > streched_l2: 0 > > > redundant: 0 > > > external_id: NULL > > > 1 row in set (0.01 sec) > > > > > > mysql> > > > > > > > > > > > -- > > Daan > > > > > > -- > Rafael Weingärtner >
Re: Why does a VLAN and Network have IP information?
Hi! I just checked our own vlan table and noticed the (obviously dhcp?) range of the L3 subnet is only present in the `vlan`.`description` field. It looks like it's getting used if the corresponding `network`,`specify_ip_range` is 1. cheers, - Stephan Am Dienstag, den 12.06.2018, 12:11 +0200 schrieb Rafael Weingärtner: > In theory, the object (either in Java or a DB table) that represents a VLAN > should not have IP information. However, it seems that someone “reused” the > object. We would need to check if the IP data stored there is not really > used before removing it. > > > On Tue, Jun 12, 2018 at 11:32 AM, Daan Hoogland > wrote: > > > > > Wido, I think we can remove ip data from the vlan table, though it is going > > to require some hacking. Removing the vlan table seems not prudent to me, > > especially since we now have l2 networks (without ip provisioned). > > > > On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander > > wrote: > > > > > > > > Hi, > > > > > > Looking at our design and tables in the database I'm wondering why both > > > a VLAN and a Network has IP information. > > > > > > A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information > > > and we also seem to store redundant information in there. > > > > > > Below is some information I have in a test database and I'm just trying > > > to understand why both have IP information. > > > > > > Imho this information should not be stored in the VLAN table as it's > > > redundant anyway. But still, why is it there? And why do we actually use > > > the VLAN table? Because even the VLAN tag is stored in the *networks* > > > table. > > > > > > Wido > > > > > > mysql> select * from vlan limit 1 \G > > > *** 1. row *** > > > id: 1 > > > uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d > > > vlan_id: 0 > > > vlan_gateway: 192.168.200.1 > > > vlan_netmask: 255.255.255.0 > > > description: 192.168.200.100-192.168.200.200 > > > vlan_type: DirectAttached > > > data_center_id: 1 > > > network_id: 203 > > > physical_network_id: 200 > > > ip6_gateway: 2001:db8:100::1 > > > ip6_cidr: 2001:db8:100::/64 > > > ip6_range: NULL > > > removed: NULL > > > created: 2018-06-09 18:53:26 > > > 1 row in set (0.00 sec) > > > > > > mysql> > > > > > > mysql> select * from networks where id = 203 \G > > > *** 1. row *** > > > id: 203 > > > name: GuestNetwork1 > > > uuid: f1f7281d-bedd-422c-bd44-eae9be172157 > > > display_text: GuestNetwork1 > > > traffic_type: Guest > > > broadcast_domain_type: Vlan > > > broadcast_uri: vlan://untagged > > > gateway: 192.168.200.1 > > > cidr: 192.168.200.0/24 > > > mode: Dhcp > > > network_offering_id: 6 > > > physical_network_id: 200 > > > data_center_id: 1 > > > guru_name: DirectNetworkGuru > > > state: Setup > > > related: 203 > > > domain_id: 1 > > > account_id: 1 > > > dns1: NULL > > > dns2: NULL > > > guru_data: NULL > > > set_fields: 0 > > > acl_type: Domain > > > network_domain: cs1cloud.internal > > > reservation_id: NULL > > > guest_type: Shared > > > restart_required: 0 > > > created: 2018-06-09 18:53:26 > > > removed: NULL > > > specify_ip_ranges: 1 > > > vpc_id: NULL > > > ip6_gateway: NULL > > > ip6_cidr: NULL > > > network_cidr: NULL > > > display_network: 1 > > > network_acl_id: NULL > > > streched_l2: 0 > > > redundant: 0 > > > external_id: NULL > > > 1 row in set (0.01 sec) > > > > > > mysql> > > > > > > > > > -- > > Daan > > > > Mit freundlichen Grüßen, Stephan Seitz -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-44 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin signature.asc Description: This is a digitally signed message part
Re: Why does a VLAN and Network have IP information?
On 06/12/2018 12:23 PM, Ivan Kudryavtsev wrote: > Hi, Devs, ipv6 in vlan table is used. Without the information in that > table, ipv6 wouldn't work with basic zone. > Yes, I'm aware of that. Would be a rather simple fix. Just a few lines of code. I know where to find it. Wido > вт, 12 июн. 2018 г., 13:11 Rafael Weingärtner : > >> In theory, the object (either in Java or a DB table) that represents a VLAN >> should not have IP information. However, it seems that someone “reused” the >> object. We would need to check if the IP data stored there is not really >> used before removing it. >> >> >> On Tue, Jun 12, 2018 at 11:32 AM, Daan Hoogland >> wrote: >> >>> Wido, I think we can remove ip data from the vlan table, though it is >> going >>> to require some hacking. Removing the vlan table seems not prudent to me, >>> especially since we now have l2 networks (without ip provisioned). >>> >>> On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander >>> wrote: >>> Hi, Looking at our design and tables in the database I'm wondering why both a VLAN and a Network has IP information. A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information and we also seem to store redundant information in there. Below is some information I have in a test database and I'm just trying to understand why both have IP information. Imho this information should not be stored in the VLAN table as it's redundant anyway. But still, why is it there? And why do we actually >> use the VLAN table? Because even the VLAN tag is stored in the *networks* table. Wido mysql> select * from vlan limit 1 \G *** 1. row *** id: 1 uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d vlan_id: 0 vlan_gateway: 192.168.200.1 vlan_netmask: 255.255.255.0 description: 192.168.200.100-192.168.200.200 vlan_type: DirectAttached data_center_id: 1 network_id: 203 physical_network_id: 200 ip6_gateway: 2001:db8:100::1 ip6_cidr: 2001:db8:100::/64 ip6_range: NULL removed: NULL created: 2018-06-09 18:53:26 1 row in set (0.00 sec) mysql> mysql> select * from networks where id = 203 \G *** 1. row *** id: 203 name: GuestNetwork1 uuid: f1f7281d-bedd-422c-bd44-eae9be172157 display_text: GuestNetwork1 traffic_type: Guest broadcast_domain_type: Vlan broadcast_uri: vlan://untagged gateway: 192.168.200.1 cidr: 192.168.200.0/24 mode: Dhcp network_offering_id: 6 physical_network_id: 200 data_center_id: 1 guru_name: DirectNetworkGuru state: Setup related: 203 domain_id: 1 account_id: 1 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Domain network_domain: cs1cloud.internal reservation_id: NULL guest_type: Shared restart_required: 0 created: 2018-06-09 18:53:26 removed: NULL specify_ip_ranges: 1 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 redundant: 0 external_id: NULL 1 row in set (0.01 sec) mysql> >>> >>> >>> >>> -- >>> Daan >>> >> >> >> >> -- >> Rafael Weingärtner >> >
Re: Why does a VLAN and Network have IP information?
On 06/12/2018 12:11 PM, Rafael Weingärtner wrote: > In theory, the object (either in Java or a DB table) that represents a VLAN > should not have IP information. However, it seems that someone “reused” the > object. We would need to check if the IP data stored there is not really > used before removing it. > Indeed. It seems redundant to me. We actually have a lot of redundant database entries, but this one is rather obvious to me. Wido > > On Tue, Jun 12, 2018 at 11:32 AM, Daan Hoogland > wrote: > >> Wido, I think we can remove ip data from the vlan table, though it is going >> to require some hacking. Removing the vlan table seems not prudent to me, >> especially since we now have l2 networks (without ip provisioned). >> >> On Tue, Jun 12, 2018 at 11:12 AM, Wido den Hollander >> wrote: >> >>> Hi, >>> >>> Looking at our design and tables in the database I'm wondering why both >>> a VLAN and a Network has IP information. >>> >>> A VLAN is a Layer 2 domain and shouldn't have any IP(4/6) information >>> and we also seem to store redundant information in there. >>> >>> Below is some information I have in a test database and I'm just trying >>> to understand why both have IP information. >>> >>> Imho this information should not be stored in the VLAN table as it's >>> redundant anyway. But still, why is it there? And why do we actually use >>> the VLAN table? Because even the VLAN tag is stored in the *networks* >>> table. >>> >>> Wido >>> >>> mysql> select * from vlan limit 1 \G >>> *** 1. row *** >>> id: 1 >>>uuid: d14f30ab-072e-41b7-bfcf-0aadd156e01d >>> vlan_id: 0 >>>vlan_gateway: 192.168.200.1 >>>vlan_netmask: 255.255.255.0 >>> description: 192.168.200.100-192.168.200.200 >>> vlan_type: DirectAttached >>> data_center_id: 1 >>> network_id: 203 >>> physical_network_id: 200 >>> ip6_gateway: 2001:db8:100::1 >>>ip6_cidr: 2001:db8:100::/64 >>> ip6_range: NULL >>> removed: NULL >>> created: 2018-06-09 18:53:26 >>> 1 row in set (0.00 sec) >>> >>> mysql> >>> >>> mysql> select * from networks where id = 203 \G >>> *** 1. row *** >>>id: 203 >>> name: GuestNetwork1 >>> uuid: f1f7281d-bedd-422c-bd44-eae9be172157 >>> display_text: GuestNetwork1 >>> traffic_type: Guest >>> broadcast_domain_type: Vlan >>> broadcast_uri: vlan://untagged >>> gateway: 192.168.200.1 >>> cidr: 192.168.200.0/24 >>> mode: Dhcp >>> network_offering_id: 6 >>> physical_network_id: 200 >>>data_center_id: 1 >>> guru_name: DirectNetworkGuru >>> state: Setup >>> related: 203 >>> domain_id: 1 >>>account_id: 1 >>> dns1: NULL >>> dns2: NULL >>> guru_data: NULL >>>set_fields: 0 >>> acl_type: Domain >>>network_domain: cs1cloud.internal >>>reservation_id: NULL >>>guest_type: Shared >>> restart_required: 0 >>> created: 2018-06-09 18:53:26 >>> removed: NULL >>> specify_ip_ranges: 1 >>>vpc_id: NULL >>> ip6_gateway: NULL >>> ip6_cidr: NULL >>> network_cidr: NULL >>> display_network: 1 >>>network_acl_id: NULL >>> streched_l2: 0 >>> redundant: 0 >>> external_id: NULL >>> 1 row in set (0.01 sec) >>> >>> mysql> >>> >> >> >> >> -- >> Daan >> > > >
Re: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]
- release checksums all check out. - I installed an all-KVM 4.9.3.1 with a redundant VPC and two nets with VMs. I upgraded to 4.11.1. The only glitch was that the documentation says to register new system VMs as 'systemvm-kvm-4.11'. This should be 'systemvm-kvm-4.11.1'. The nets kept running and upgrading the vpc worked without problem or noticable network glitch. knowing that you will all test intensively as well ;) (as will I still...) +1 (binding) On Mon, Jun 11, 2018 at 5:49 PM, Paul Angus wrote: > Hi All, > > > > I've created a 4.11.1.0 release (RC2), with the following artefacts up for > testing and a vote: > > > > Git Branch and Commit SH: > > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=short > log;h=refs/heads/4.11.1.0-RC20180611T1504 > > Commit: bcf602c7cd4ab662a7c4f208dee32fb8513e26c8 > > > > Source release (checksums and signatures are available at the same > > location): > > https://dist.apache.org/repos/dist/dev/cloudstack/4.11.1.0/ > > > > PGP release keys (signed using 8B309F7251EE0BC8): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > The vote will be open until the end of the week, 15nd June 2018. > > > > For sanity in tallying the vote, can PMC members please be sure to > indicate "(binding)" with their vote? > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > Additional information: > > > > For users' convenience, I've built packages from > bcf602c7cd4ab662a7c4f208dee32fb8513e26c8 and published RC2 repository > here: > > http://packages.shapeblue.com/testing/4111rc2/ > > > > The release notes are still work-in-progress, but the systemvm template > upgrade section has been updated. You may refer the following for systemvm > template upgrade testing: > > http://docs.cloudstack.apache.org/projects/cloudstack-releas > e-notes/en/latest/index.html > > > > 4.11.1 systemvm templates are available from here: > http://packages.shapeblue.com/systemvmtemplate/4.11.1-rc1/ > > > > > Kind regards, > > Paul Angus > > > paul.an...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > -- Daan
Re: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]
+1 (binding) This is what I did for RC1: I created a new cloud using commit 5f48487dc62fd1decaabc4ab2a10f549d6c82400 (RC1). I ran the automated regression tests for managed storage. All tests passed. This is what I did for RC2: I looked at the Git changelog and didn’t see anything that seemed like it would impact the prior success of my testing for RC1. On 6/11/18, 9:49 AM, "Paul Angus" wrote: Hi All, I've created a 4.11.1.0 release (RC2), with the following artefacts up for testing and a vote: Git Branch and Commit SH: https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.11.1.0-RC20180611T1504 Commit: bcf602c7cd4ab662a7c4f208dee32fb8513e26c8 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.11.1.0/ PGP release keys (signed using 8B309F7251EE0BC8): https://dist.apache.org/repos/dist/release/cloudstack/KEYS The vote will be open until the end of the week, 15nd June 2018. For sanity in tallying the vote, can PMC members please be sure to indicate "(binding)" with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Additional information: For users' convenience, I've built packages from bcf602c7cd4ab662a7c4f208dee32fb8513e26c8 and published RC2 repository here: http://packages.shapeblue.com/testing/4111rc2/ The release notes are still work-in-progress, but the systemvm template upgrade section has been updated. You may refer the following for systemvm template upgrade testing: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/index.html 4.11.1 systemvm templates are available from here: http://packages.shapeblue.com/systemvmtemplate/4.11.1-rc1/ Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
