Re: GSoC 2021 Completes
Congratulations to the GSoC students for successfully completing their projects, and mentors for helping them out. Hope the students have learnt something new, outside of their academic programme. Regards, Suresh On 03/09/21, 4:45 PM, "Abhishek Kumar" wrote: Congratulations to both students and mentors, and the community in general! Some great work started with these projects. Looking forward to seeing them in action in upcoming releases. Students - hoping ACS community will continue to interest you and will look forward to seeing you around. Regards, Abhishek From: Rohit Yadav Sent: 03 September 2021 16:10 To: dev@cloudstack.apache.org ; us...@cloudstack.apache.org ; Bikram Biswas ; Sangwoo Bae ; Apurv Gupta ; atrocityth...@gmail.com Cc: Apache CloudStack Marketing Subject: GSoC 2021 Completes All, I'm happy to share with the community that our project participation at Google Summer of Code 2021 comes to an end with four successful projects [1][2] by our four students passing with flying colours. Results were available earlier this week on 31st Aug 2021 [3]. Let's use this opportunity to congratulate our students and mentors and ask them to share any feedback on the project - hope we'll participate next year too! Let me start; Congratulate Apurv, Junxuan, Bikram, and Sangwoo for your hard work and successful projects! We look forward to seeing you around in the community! Thank you mentors for your hard work and mentoring the students - Pearl, David, Suresh, Bobby, Hari, and Nicolas! Two of our students have blogged about their experiences, you may read them here: Apurv's blog: https://apurv-gupta.medium.com/google-summer-of-code-apachecloudstack-final-report-bae911b0bd44 Bikram's blog: https://medium.com/@bickrombishsass/gsoc-2021-experience-at-apache-cloudstack-8946fe31ff5b [1] GSoC 2021 at Apache CloudStack Project: https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSoC+2021 [2] Student PR submissions: https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+label%3Agsoc2021 [3] https://summerofcode.withgoogle.com/how-it-works/#timeline Regards.
High increase in bandwidth usage
I installed a cloudstack server on a bare metal server (all in one installation). The bandwidth usage was normal. After a couple days, the bandwidth usage was very high, got several emails as well from the DC. I tried to limit it using wondershaper. Worked for a while, but then I was locked out of the machine. Couldn't ssh into the machine. Had to format the machine. The same thing happened again. I am able to ssh into the system for now, bandwidth usage is high, cloudstack server isn't responding. Attaching ss of cloudstack management server logs. Please address me if I am doing something wrong, or the solution to this problem.
Re: [Discussion] Release Cycle
Hi Gabriel, thanks for opening this discussion. I'm +1 on it. My considerations: - We've to put a lot of efforts to support 3+ LTS simultaneously, which doesn't make sense. Regular versions will give us some breath and will reduce rework. - Although the EOL is well defined, it seems we don't have a solid criteria to define new versions, because they don't have a pattern. Users don't know when they will have a new version. Also, we don't have much planning to do the implementations. - We've been seeing Ubuntu life-cycle working for a long time, and we know it works well. It's a good reference to follow, we will not need to reinvent the wheel. Best regards, Daniel. On 31/08/2021 14:44, Gabriel Bräscher wrote: Hello, I would like to open a discussion regarding the project release cycle. More specifically on the following topics: 1. LTS and Regular releases 2. Releases period 3. Enhance roadmap and Release cycle for users 1 LTS and Regular releases It has been a while since the last regular release. Nowadays there are only LTS releases; maybe we should get back to having regular versions in between LTS. With a “Regular” release users would be able to trade stability for new features. Additionally, developers and users would have a “pilot” of the next LTS which could anticipate issues and result in a stable long-term release. Please, let me know what you think of this. Should we get back to releasing Regular releases in between LTS releases? For reference, here follow the past releases: +-+-+--+-+ | Release | Type| Release date | EOL | +-+-+--+-+ | 4.15| LTS | 19 Jan 2021 | 1 July 2022 | +-+-+--+-+ | 4.14| LTS | 26 May 2020 | 1 Jan 2022 | +-+-+--+-+ | 4.13| LTS | 24 Sep. 2019 | 1 May 2021 | +-+-+--+-+ | 4.12| Regular | 4 April 2019 | N/A | +-+-+--+-+ | 4.11| LTS | 12 Feb. 2018 | 1 July 2019 | +-+-+--+-+ | 4.10| Regular | 6 July 2017 | N/A | +-+-+--+-+ | 4.9 | LTS | 25 July 2016 | 1 July 2018 | +-+-+--+-+ 2 Releases period We had in the past a new LTS per year. Then, we got into two new LTS per year. This led from having 2 LTS maintained at the same time to 3. With that said, I think this is neither documented nor has it been discussed in the ML. We have the LTS minimum and maximum support dates well defined, but so far there is no definition/guidelines towards the release period. I would like to open this discussion so we can update the CloudStack wiki page [https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS] and have a clear definition of when the community should expect each release. 3 Enhance roadmap and Release cycle for users This topic is an extension of Topic 2. Once we have “Topic 2” well defined we will be able to present a draft of future releases. The main idea of this email is to look for project stability and predictability with a release cycle/roadmap similar to what is done by Ubuntu [https://ubuntu.com/about/release-cycle]. We would then be able to give users and developers a roadmap to look after. I would also suggest such a release cycle to be presented on the website, in addition to the “cwiki” page [ https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS]. Please let me know what you think. Best regards, Gabriel.
[VOTE] Apache CloudStack 4.15.2.0 (RC1)
All, I've created a 4.15.2.0 release, with the following artifacts up for a vote: Git Branch and Commit SHA: https://github.com/apache/cloudstack/tree/4.15.2.0-RC20210907T1815 Commit: 5ba2867598ecf7ce16807e78d5033c342a2a52d7 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.15.2.0/ PGP release keys (signed using 5ED1E1122DC5E8A4A45112C2484248210EE3D884): https://dist.apache.org/repos/dist/release/cloudstack/KEYS The vote will be open for a week until 13 September 2021. 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) For users convenience, the packages from this release candidate (RC1) will be available here shortly: https://download.cloudstack.org/testing/4.15.2.0-RC1/ There is no new systemvmtemplate for 4.15.2, the 4.15.1 systemvmtemplate can be used from here: https://download.cloudstack.org/systemvm/4.15/ Docs are not published yet but upgrade notes are similar to the one below without the requirement of registering a new systemvmtemplate: https://github.com/apache/cloudstack-documentation/tree/4.15/source/upgrading/upgrade Regards.
Re: IPV6 in Isolated/VPC networks
All, After another iteration with Alex, I've updated the design doc. Kindly review: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+Isolated+Network+and+VPC+with+Static+Routing ... and advise on some outstanding questions: * How should the IPv6 block/allocation work in VPCs? Option1: Should this be simply /64 allocation on any new tier, the cons of this option is one static route/rule per VPC tier. (many upstream routers may have limit on no. of static routes?) Option2: Let user ask/specify tier size, say /60 (for 16 tiers) or /62 (4 tiers) for the VPC, this can be filtered based on the vpc.max.networks global setting (3 is default). The pros of this option are less no. of static route/rule and easy programming, but potential wastage of multiple /64 prefix blocks for unused/uncreated tiers. * How do we manage IPv6 usage? Can anyone advise how we do IPv6 usage for shared network (design, implementation and use-cases?) Option1: We don't do it, all user VMs nics have ipv4 address which whose usage we don't track. For public VR/nics/networks, we can simply add the IPv6 details for a related IPv4 address. Option2: Implement a separate, first-class IPv6 address or /64 prefix tracking/management and usage for all VMs and systemvms nic (this means account/domain level limits and new billing/records) * Enable IPv6 on systemvms (specifically SSVM and CPVM) by default if zone has a IPv6 address block allocated/assigned for use for systemvms (this was mainly thought for VRs, but why no ssvm and cpvms too - any cons of this?) * Regards. From: Rohit Yadav Sent: Thursday, August 19, 2021 15:45 To: dev@cloudstack.apache.org Subject: 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 >
