Re: IPV6 in Isolated/VPC networks
Hi all, I've taken feedback from this thread and wrote this design doc: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+Isolated+Network+and+VPC+with+Static+Routing Kindly review and advise if I missed anything or anything that needs to be changed/updated. You may comment on the wiki directly too. Kindly suggest your views on the following (also in the design doc above): Outstanding Questions: * Should admin or user be able to specify how VPC super CIDRs are created/needed; for example a user can ask for VPC with /60 super CIDR? Or should CloudStack automatically find/allocate a /64 for a new VPC tier from the root-admin configured /64-/48 block? * Should we explore FRR and iBGP or other strategies to do dynamic routing which may not require advance/complex configuration in the VR or for the users/admin? * With SLAAC and no dhcpv6, is there a way to support secondary IPv6 addresses (or floating IPv6 addresses for VR/public traffic) for guest VM's nics? * Any thoughts on UI/UX for firewall/routing management? * Any other feature/support for isolated network or VPC feature that must be explored or supported such as PF, VPN, LB, vpc static routes, vpc gateway etc. * For usage - should we have any consideration, or should we assume that IPv4 and IPv6 address will go together for every nic; so IPv6 usage for a nic is in tandem with Ipv4 address for a nic, i.e. no explicit/new biling/usage needed? * For smoketests, local dev-test should we explore ULA? Unique Local Address - in the range fc00::/7. Typically only within the ‘local’ half fd00::/8. ULA for IPv6 is analogous to IPv4 private network addressing. This prefix can be randomly generated at first install by CloudStack in a zone using zoneid etc? * Should we expand support for VR diagnostic feature to include support for ipv6, traceroute6? * Discuss - expand support/ability to allocate a /60, or /56 etc prefix to an individual VM in shared network (Wido's suggestion) Regards. From: Wei ZHOU Sent: Tuesday, August 17, 2021 21:16 To: dev@cloudstack.apache.org Subject: Re: IPV6 in Isolated/VPC networks Thanks Kristaps, Wido, Rohit and Alex for your replies. I am fine with not having stateful dhcpv6 and privacy extension/temporary address in phase 1. If community decides not to do eventually , it is also ok to me. We could explore how to better use secondary ipv6 addresses as Wido advised. It would be great if anyone share some user experience. -Wei On Tuesday, 17 August 2021, Kristaps Cudars wrote: > Hi Wei, > > Published this month’s RFC 9099 and explains in different > words/perspective what has been written by Alex, Rohit and Wido. > https://www.rfc-editor.org/rfc/rfc9099.html > > > On 2021/08/17 09:20:21, Wei ZHOU wrote: > > Hi Wido, > > > > (cc to Rohit and Alex) > > > > It is a good suggestion to use FRR for ipv6. The configuration is quite > > simple and the VMs can get SLAAC, routes, etc. > > > > Privacy extension looks not the same as what you mentioned. see > > https://datatracker.ietf.org/doc/html/rfc4941 > > > > You are right. To use static routing, the admins need to configure the > > routes in the upstream router, and add some ipv6 ranges (eg /56 for VPCs > > and /64 for isolated networks) and their next-hop (which will be > > configured in VRs) in CloudStack. CloudStack will pick up an IPv6 range > and > > assign it to an isolated network or vpc. @Rohit, correct me if I'm wrong. > > > > I have a question, it looks stateless dhcpv6 (SLAAC from router/VR, > > router/dns etc via RA messages) will be the only option for now (related > to > > your pr https://github.com/apache/cloudstack/pull/3077) . Would it be > good > > to provide stateful dhcpv6 (which can be implemented by dnsmasq) as an > > option in cloudstack ? The advantages are > > (1) support other ipv6 cidr sizes than /64. > > (2) we can assign a specified Ipv6 address to a vm. vm Ipv6 addresses can > > be changed > > (4) an Ipv6 addresses can be re-used by multiple vms. > > The problem is, stateful dhcpv6 does not support routers,nameservers, > etc. > > we need to figure it out (probably use radvd/frr and dnsmasq both). > > > > -Wei > > > > > > On Fri, 13 Aug 2021 at 12:19, Wido den Hollander wrote: > > > > > Hi, > > > > > > See my inline responses: > > > > > > Op 11-08-2021 om 14:26 schreef Rohit Yadav: > > > > Hi all, > > > > > > > > Thanks for your feedback and ideas, I've gone ahead with discussing > them > > > with Alex and came up with a PoC/design which can be implemented in the > > > following phases: > > > > > > > >* Phase1: implement ipv6 support in isolated networks and VPC > with > > > static routing > > > >* Phase2: discuss and implement support for dynamic routing > (TBD) > > > > > > > > For Phase1 here's the high-level proposal: > > > > > > > >* IPv6 address management: > > > > * At the zone level root-admin specifi
[DISCUSS] 4.15.2.0
All, I want to kick a thread to discuss and gather interest from the community on doing a 4.15.2.0 release, before Nicolas (our RM) cuts 4.16.0.0 RC1 around the end of Sept '21. We can keep the scope really tight to include only important fixes, I see about 50 closed issues/PRs already on the 4.15.2.0 milestone and some 30 remaining: https://github.com/apache/cloudstack/milestone/20 I'm hoping the 4.15.2.0 release can be a quick stable minor release, I can do it and any other volunteer RM may do it. Whoever does it, here's my proposal is: * Limit the scope to very specific do-able bug-fixes up to end the month - so gives us roughly 2 weeks * Cut RC1 in the first week of Sept * Assuming the RC1 would be stable enough as 4.15 branch is quite stable, worst case we've another RC2 * Conclude release work by mid or end of Sept before 4.16.0.0 RC1 is cut; so 4.15.2.0 release work doesn't cause delay for 4.16.0.0 Thoughts? Thanks and regards.
[GitHub] [cloudstack-go] csquire opened a new issue #4: HostService response types are broken
csquire opened a new issue #4: URL: https://github.com/apache/cloudstack-go/issues/4 When running against Cloudstack 4.15 with the latest code, the cpuloadaverage and hostha fields in the response types within HostService have the wrong types causing the client to fail at parsing responses from the Cloudstack API. The cpuloadaverage field defaults to string but needs to be a float64 (missing handling of double in the `mapType` function of generate.go). The hostha field defaults to string but needs to be a custom HostHAResponse type. The cpuloadaverage is easy to fix, but I don't immediately understand how the custom field type generation works in order to implement a fix for it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-documentation] davidjumani commented on a change in pull request #234: Note on untested plugins and hypervisors, OS-es
davidjumani commented on a change in pull request #234: URL: https://github.com/apache/cloudstack-documentation/pull/234#discussion_r692651946 ## File path: source/releasenotes/compat.rst ## @@ -26,7 +26,7 @@ CloudStack Management Server. - CentOS versions 7, 8 (note: CentOS 8 will EOL in Dec 2021) - RHEL versions 7, 8 (along with binary compatible versions such as Rocky Linux 8) - openSUSE Leap 15 -- SUSE Linux Enterprise Server 15 +- SUSE Linux Enterprise Server 15 (not tested, but expected to work same as with openSUSE 15) Review comment: This was tested on a container, not a VM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] 4.15.2.0
Sounds good, Rohit. I'm +1 on a quick/stable 4.15.2. Em qui., 19 de ago. de 2021 às 07:54, Rohit Yadav escreveu: > All, > > I want to kick a thread to discuss and gather interest from the community > on doing a 4.15.2.0 release, before Nicolas (our RM) cuts 4.16.0.0 RC1 > around the end of Sept '21. > > We can keep the scope really tight to include only important fixes, I see > about 50 closed issues/PRs already on the 4.15.2.0 milestone and some 30 > remaining: > https://github.com/apache/cloudstack/milestone/20 > > I'm hoping the 4.15.2.0 release can be a quick stable minor release, I can > do it and any other volunteer RM may do it. Whoever does it, here's my > proposal is: > > * Limit the scope to very specific do-able bug-fixes up to end the > month - so gives us roughly 2 weeks > * Cut RC1 in the first week of Sept > * Assuming the RC1 would be stable enough as 4.15 branch is quite > stable, worst case we've another RC2 > * Conclude release work by mid or end of Sept before 4.16.0.0 RC1 is > cut; so 4.15.2.0 release work doesn't cause delay for 4.16.0.0 > > Thoughts? > > > Thanks and regards. > > > >
Re: [DISCUSS] 4.15.2.0
+1. -Wei On Thu, 19 Aug 2021 at 12:54, Rohit Yadav wrote: > All, > > I want to kick a thread to discuss and gather interest from the community > on doing a 4.15.2.0 release, before Nicolas (our RM) cuts 4.16.0.0 RC1 > around the end of Sept '21. > > We can keep the scope really tight to include only important fixes, I see > about 50 closed issues/PRs already on the 4.15.2.0 milestone and some 30 > remaining: > https://github.com/apache/cloudstack/milestone/20 > > I'm hoping the 4.15.2.0 release can be a quick stable minor release, I can > do it and any other volunteer RM may do it. Whoever does it, here's my > proposal is: > > * Limit the scope to very specific do-able bug-fixes up to end the > month - so gives us roughly 2 weeks > * Cut RC1 in the first week of Sept > * Assuming the RC1 would be stable enough as 4.15 branch is quite > stable, worst case we've another RC2 > * Conclude release work by mid or end of Sept before 4.16.0.0 RC1 is > cut; so 4.15.2.0 release work doesn't cause delay for 4.16.0.0 > > Thoughts? > > > Thanks and regards. > > > >
