Re: [PRIMATE][SIG] Meeting Notes
I’m willing and able to contribute. The thing stopping me at the moment is a lack of well defined tasks. The tasks I’m seeing in GitHub are very vague and general, and without further discussion I don’t feel comfortable jumping in on them. Due to the meeting time for the focus group, I’ve been unable to attend that to get more clarity on the outstanding needs. Is there a chance we could have another meeting and flesh out specific tasks that we can add to GitHub? This may serve to get others involved as well, if they felt they knew enough to jump in and assist. -- Greg Goodrich | IP Pathways Senior Developer 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com> On Nov 18, 2019, at 7:01 AM, Rohit Yadav mailto:rohit.ya...@shapeblue.com>> wrote: 18 Nov 2019 High level: * Attendees - Bobby, Gabriel, Paul, Rohit * High-level project updates discussed: no major changes or significant work in last two weeks * Few bugs fixes and PRs merged in last two weeks * Technical preview project/progress board: http://sea.ippathways.com:32224/?dmVyPTEuMDAxJiZjZTA0ZmRiMjc1MzVlNzk3Zj01REQyOTYyNF8xMzgzOF8xNzc1M18xJiZmOTEwOWJiNjgxNWM2OGU9MTIzMyYmdXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViJTJFY29tJTJGYXBhY2hlJTJGY2xvdWRzdGFjay1wcmltYXRlJTJGcHJvamVjdHMlMkYx * Discussed usage of Github packages for docker, maven etc. Actions and agreements: * Gabriel/PCExtreme: exploring a Docker image/setup, Wido has agreed to donate VM/resources for the CI/CD setup for PR (a live env on each PR) - to explore Docker image, CI/env setup and bot-integration on Primate PRs and support for IPv6 in the UI * Bobby/ShapeBlue - manual QA (may commence effort towards end of Dec) * Rohit/ShapeBlue - work stalled on zone deployment, likely to be resumed this week * Paul/ShapeBlue, rest - discuss if having guided tutorials (both videos and articles/docs) may help in driving the interest and traction to development output Discussion for the community - there has not been any significant development output lately, at least in the last 2-4 weeks: * How can we encourage the community to participate and contribute development towards the Primate project? * If we work on video and docs/article tutorials that illustrate and guide on how to work with the UI and implement a real-world component/requirement, would that help? Regards, Rohit Yadav Software Architect, ShapeBlue http://sea.ippathways.com:32224/?dmVyPTEuMDAxJiZjNDVlZWFhZDZiMjBhOWM4ZT01REQyOTYyNF8xMzgzOF8xNzc1M18xJiY5ODUxNmYwMzQxZWNiOTE9MTIzMyYmdXJsPWh0dHBzJTNBJTJGJTJGd3d3JTJFc2hhcGVibHVlJTJFY29t rohit.ya...@shapeblue.com http://sea.ippathways.com:32224/?dmVyPTEuMDAxJiZkYjVkZTlmMzZiNzJlNzk3Zj01REQyOTYyNF8xMzgzOF8xNzc1M18xJiZiOTAwZGFiMjI1OGM5OGU9MTIzMyYmdXJsPXd3dyUyRXNoYXBlYmx1ZSUyRWNvbQ== Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
Re: [PROPOSE] RM for 4.14
A minor note that those 4.14 dates should all be 2020, not 2019 -- Greg Goodrich | IP Pathways Senior Developer 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com> On Dec 19, 2019, at 12:30 PM, Paul Angus mailto:paul.an...@shapeblue.com>> wrote: I can answer that one... The 'plan' was always 2 new LTS branches a year - effectively summer and winter. Remember at the time, some members of the community were going for a release every month. So the idea was - whatever the branch was the current branch at the time that an LTS was due, that branch would get some 'extra treatment' and be supported for a few years rather than a few months. Very importantly, the post x.x.0 LTS releases were to have no new features - just bugfixes. So larger organisations with stricter change control, their own documentation and their own integrations, could stay on a 'supported' branch but still get bug fixes in releases, without having to worry about, test or document new features constantly. (I'll hand-wave over the fact that one person's feature is another person's improvement, is another person's bugfix) Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1 with all critical/blocker/major bugfixes in it (probably as soon as enough people have recovered from a 4.14 release cycle) but it can't have any new features in it. So looking forward, if someone wants a 4.15 release in (say) April, then the 'summer' LTS branch (July/August time) will be 4.16, if not, then the summer LTS release would be 4.15 I hope that helps 😊 Kind regards Paul. paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com> www.shapeblue.com<http://www.shapeblue.com> Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Gabriel Beims Bräscher Sent: 19 December 2019 16:59 To: dev Subject: Re: [PROPOSE] RM for 4.14 Hello Andrija, That is always good news to have contributors stepping up and getting new releases done. We definitely need a release (either a major or a 4.13.1.0) to keep the project traction. However, I would like to understand why 4.14.0.0 is being considered an LTS release. As far as I know, the next major release was supposed to be a regular (non-LTS) release in the midle of the current LTS and next one LTS. Our current LTS 4.13.0.0 is young and with still has some room for bugfixes. For reference, here follows the Release Calendar, more details at [1]. 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018 4.9.3.0, LTS, released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS, released at 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4 April 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+ [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS Regards, Gabriel. Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel escreveu: Hi Andrija, How can I help and engage in this process? Cheers Sven __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. Am 19.12.2019 um 17:05 schrieb Andrija Panic : Hi All, I’d like to put myself forward as release manager for 4.14. The 4.14 releases will be the next major version LTS release and will be supported for 20 months per the LTS manifesto [2]. I'll have support from Rohit/Daan/Paul during the process and anyone else interested is most welcome to join the effort. The proposed timeline (possibly a bit too ambitious) is as follows: ## 24.Jan 2019 --&g
Re: Set Number of queues for Virtio NIC driver to vCPU count?
AC-102 -- Greg Goodrich | IP Pathways Development Manager 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com> On Mar 23, 2021, at 6:08 PM, Sean Lair mailto:sl...@ippathways.com>> wrote: We are looking to improve the network performance of our KVM/QEMU VMs running in CloudStack. One thing we noticed is that the Virtio NICs are not configured to use multiple queues. A couple of years ago someone created a PR to increase the Virtio SCSI queue count to match the number of vCPUs: https://github.com/apache/cloudstack/pull/3101
Apidocs build failure on 4.14 with java 11 and centos 7
I’m working on setting up an automated build for CloudStack for 4.14 using java 11 in a Centos 7 Docker container and was wondering if anyone has experienced this, and how you solved it. I’m trying to leverage stock CentOs RPMs, and realized that the Maven install seems to be hard-wired to Java 8, thus installing it. I’ve also installed Java 11. However, the Java 8 binaries are installed in the ‘default’ location of /usr/bin/. I’m setting JAVA_HOME env var so that Maven uses Java 11 when building. However, the Apidocs build-apidoc.sh script just invokes java within it, without respect to JAVA_HOME. This causes the build to fail with the following error: Exception in thread "main" java.lang.UnsupportedClassVersionError: com/cloud/api/doc/ApiXmlDocWriter has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 I can manually fix this in a number of ways, but was wondering if the community has guidance on the best way to go about this. Some thoughts are: * Don’t use the RPM for Maven, and instead pull a binary bistro down and install manually via tar, thus alleviating the pinning to Java 8. Then I could uninstall Java 8 (I use a different container for older CloudStack builds) and just have Java 11 in the container. * Manually move the Java 11 binaries into /usr/bin/, overwriting the Java 8 binaries. This seems complex, as there are bound to be other dependencies that could get missed in this manual step, such as libraries, etc. * Fix build-apidocs.sh to respect JAVA_HOME so that invokes the correct java binaries. * Some other option that I’ve not yet thought of. Thanks. -- Greg Goodrich | IP Pathways Senior Developer 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com>
Re: Apidocs build failure on 4.14 with java 11 and centos 7
I believe that will work, thank you!!! -- Greg Goodrich | IP Pathways Senior Developer 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com> On Dec 1, 2020, at 1:43 PM, Wei ZHOU mailto:ustcweiz...@gmail.com>> wrote: Hi Greg, Can you try "update-alternatives --config java" ? -Wei On Tue, 1 Dec 2020 at 19:35, Greg Goodrich mailto:ggoodr...@ippathways.com>> wrote: I’m working on setting up an automated build for CloudStack for 4.14 using java 11 in a Centos 7 Docker container and was wondering if anyone has experienced this, and how you solved it. I’m trying to leverage stock CentOs RPMs, and realized that the Maven install seems to be hard-wired to Java 8, thus installing it. I’ve also installed Java 11. However, the Java 8 binaries are installed in the ‘default’ location of /usr/bin/. I’m setting JAVA_HOME env var so that Maven uses Java 11 when building. However, the Apidocs build-apidoc.sh script just invokes java within it, without respect to JAVA_HOME. This causes the build to fail with the following error: Exception in thread "main" java.lang.UnsupportedClassVersionError: com/cloud/api/doc/ApiXmlDocWriter has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 I can manually fix this in a number of ways, but was wondering if the community has guidance on the best way to go about this. Some thoughts are: * Don’t use the RPM for Maven, and instead pull a binary bistro down and install manually via tar, thus alleviating the pinning to Java 8. Then I could uninstall Java 8 (I use a different container for older CloudStack builds) and just have Java 11 in the container. * Manually move the Java 11 binaries into /usr/bin/, overwriting the Java 8 binaries. This seems complex, as there are bound to be other dependencies that could get missed in this manual step, such as libraries, etc. * Fix build-apidocs.sh to respect JAVA_HOME so that invokes the correct java binaries. * Some other option that I’ve not yet thought of. Thanks. -- Greg Goodrich | IP Pathways Senior Developer 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:ggoodr...@ippathways.com><mailto:j...@ippathways.com>
Secure Live Migration for KVM
We have just discovered in our Lab environment that the certificates for libvirtd did not auto renew. Thus when we did an update, and restart of the agent, it failed to start, due to Libvirtd failing to start from an expired certificate. We then checked our production hosts, and their certificates are due to expire in 4 days, even though our setting is to auto renew at 15 days. Has anyone else encountered a problem with this? It appears to be related to this feature - https://github.com/apache/cloudstack/pull/2505. We are running 4.11.3 in both environments. -- Greg Goodrich | IP Pathways Development Manager 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com>
Re: Secure Live Migration for KVM
Further investigation finds this PR which may be related - https://github.com/apache/cloudstack/pull/4156. We are investigating if this could be the cause. -- Greg Goodrich | IP Pathways Development Manager 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:j...@ippathways.com> On Mar 11, 2021, at 4:09 PM, Greg Goodrich mailto:ggoodr...@ippathways.com>> wrote: We have just discovered in our Lab environment that the certificates for libvirtd did not auto renew. Thus when we did an update, and restart of the agent, it failed to start, due to Libvirtd failing to start from an expired certificate. We then checked our production hosts, and their certificates are due to expire in 4 days, even though our setting is to auto renew at 15 days. Has anyone else encountered a problem with this? It appears to be related to this feature - https://github.com/apache/cloudstack/pull/2505. We are running 4.11.3 in both environments. -- Greg Goodrich | IP Pathways Development Manager 3600 109th Street | Urbandale, IA 50322 p. 515.422.9346 | e. ggoodr...@ippathways.com<mailto:ggoodr...@ippathways.com><mailto:j...@ippathways.com>
