[REVIVE][DISCUSS] Closing issues & PR after a certain time
People, I want to revive this discussion and bring Vishesh' PR under your attention again. The discussion there is mostly about the length of the period before closing. So here I am going to state 1year - first warning, 1.5years second warning, 2 years closing. What do you all think? There are also issues that we might consider interesting but not functionally complete or clear, we can convert those to github discussions, and I would like to encourage all of you to do that as sometimes issues will lead to issues and not to PRs and those are basically discussions to be had. please respond with your comments or put them in https://github.com/apache/cloudstack/pull/8667 regards, On 2024/02/16 09:17:02 Vishesh Jindal wrote: > I have created a PR with the changes > here:https://github.com/apache/cloudstack/pull/8667 > > I propose that we enable it. As Daan suggested, we can always remove the > action if it doesn't work out. And if a PR/issue gets closed, we can always > reopen it. > > > > ____ > From: Daan Hoogland > Sent: Wednesday, February 14, 2024 2:17 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Closing issues & PR after a certain time > > i'm a bit -0 on this. I agree that a lot of stale issues deserve > closing, but others are really long term goals. I do not want to block > this great idea but am just a bit worried about other great ideas > getting lost. So I would propose to tag anything we close or not > remove the stale tag, so these can be easily found. I am not worried > too much about PRs, just issues. > > On the other hand, we can always remove the gha again, so maybe we > should install it and see if it works for us. > > On Wed, Feb 14, 2024 at 4:49 AM Kiran Chavala > wrote: > > > > Good idea Vishesh > > > > +1 for using Githubactions > > > > Regards > > Kiran > > > > From: Vishesh Jindal > > Date: Tuesday, 13 February 2024 at 6:33 PM > > To: dev@cloudstack.apache.org > > Subject: [DISCUSS] Closing issues & PR after a certain time > > Hi everyone, > > > > I was going through the issues and PRs, and I noticed that a lot of them > > are really old and some of them are waiting for the original author to > > reply. > > > > I wanted to discuss if we should add a github action > > (https://github.com/marketplace/actions/close-stale-issues) for auto > > closing the issues and PRs after a certain time. > > > > From the github actions' documentation, this is how it works: > > > > * Add a label "Stale" on issues and pull requests after 60 days of > > inactivity and comment on them > > * Close the stale issues and pull requests after 7 days of inactivity > > * If an update/comment occur on stale issues or pull requests, the > > stale label will be removed and the timer will restart > > > > Instead of using the defaults, I would like to: > > > > * > > mark the issue/PR stale after 90 days > > * > > close the stale issue/PR after 30 days > > > > Let me know if this sounds good. I will create the PR to set this up. > > > > Regards, > > Vishesh > > > > > > > > > > > > > > > > > > > -- > Daan >
Re: [DISCUSS] Define a release schedule for the project
nice to see this discussion being had again and sorry to be late in replying João, I see no replies have come forward yet. Let's add a new https://github.com/apache/cloudstack/discussions/new/choose for this as well. I still feel my proposal is good and should have been applied. but we can gather all kinds of proposals in one place and get to some kind of improvement someday. One point of criticism on your proposal, though not a breaking point, is that it doesn't guarantee backwards compatibility, something we have always maintained so far (through upgrade paths). Not being chained to old to technical debt is good, but it should not leave people behind ;) We do have a hardly ever used procedure to deprecate old plugins for instance. we should think about applying that to API and other namings as well. regards, On Fri, Mar 15, 2024 at 12:10 PM João Jandre Paraquetti wrote: > > Hi all, > > I had posted this message on another thread, but following Rohit's > advice I've decided to create a new one for it. That being said, I have > another proposal for the versioning scheme. Instead of dropping the "X" > on our X.Y.Z.N, we can set a fixed schedule (that can be further > discussed) for the version changes: > > - Every two years, we release a major version (X), which can contain > changes that break backward compatibility, such as (but not limited to): > removing unused/useless APIs, renaming APIs, and changing the default > behavior of features. These changes must be discussed with the devs and > be properly communicated to the community (via API deprecation, for > example) at least one minor version before the major release; > - Every semester, we release a minor version (Y) of the current major > (X) version, these can contain new features/APIs, as long as the > backward compatibility is maintained; also, feature/API deprecation > should happen on these versions; > - Every 2/3 months, we release patch versions (Z), that fix any bugs > that were released with the major and minor versions, these versions > should not contain any new features; > - In extreme cases (such as with security issues) we work on and release > security versions (N); > > The proposed schedule is only a sketch that can be worked on. However I > believe that the project can benefit from: > 1. A fixed release schedule; > 2. A mechanism to introduce disruptive changes, so that the project can > evolve and not be chained to the same features/API/limitation/technical > debts forever. > > Furthermore, having a schedule allows us to have a project roadmap, that > outlines the future deprecations, changes and big features. > > Best Regards, > > João Jandre. > -- Daan
Re: [DISCUSS] New terraform git tag for registry workaround
I think your proposals are ok as an ad-hoc solution to the current situation @Rohit Yadav . I wonder how we should deal with this in the future though. 1. As for the numbering, do we have a procedure to prevent this issue in the future? 2. The provider is part of apache and I think the link https://github.com/apache/terraform-provider-cloudstack should be validated. What exactly is the objection to this? On Mon, Apr 15, 2024 at 12:05 PM Rohit Yadav wrote: > > All, > > The recent Terraform provider release v0.5.0 has a problem with the Terraform > registry website. > https://github.com/apache/cloudstack-terraform-provider/issues/109 > > The registry support isn't able to provide a resolution now, their manual > resync button on the provider isn't fixing the issue. > > While I've documented the steps for manually installing and using the > provider. Most terraform/tofu users are used to consuming a provider from the > registry. > > If there are no objections, I propose that we just tag the current version as > v0.5.1 and push it on the registry for the purpose of publishing on the > registry website. We may need not do a formal vote for this as code wise > nothing has changed and we can make this tag to be a community release tag > solely done for the purpose of having a workaround on the registry website > https://registry.terraform.io/providers/cloudstack/cloudstack/latest which > gets published via > https://github.com/cloudstack/terraform-provider-cloudstack as the registry > also has a strict repo naming policy (due to which it can't use the repo > under Apache org). > > Thoughts? > > Regards. > > > -- Daan
build error on main
Devs, I've been getting these errors on main the last few weeks: ~~~ [ERROR] Failures: [ERROR] ActionEventInterceptorTest.testInterceptComplete:247 [ERROR] ActionEventInterceptorTest.testInterceptException:261 [ERROR] ActionEventInterceptorTest.testInterceptStartAsync:234 expected: but was: ~~~ I've tried different maven versions and checked the java version, but have not found the golden clue yet. Did anybody else see these errors? btw, in intellij there are no errors on these tests and also when run as an isolated test suit they pass : `mvn -P developer,systemvm clean install -Dnoredist -DfailIfNoTests=false -pl server -Dtest=ActionEventInterceptorTest`. Only when building the entire system with `mvn clean install -P developer,systemvm -Dnoredist` do these fail. Any hints/clues or similar experiences? thanks, -- Daan
Re: [VOTE] Apache CloudStack 4.18.2.0 RC2
+1 binding I checked the hashes alright and the log of commit/tag (Note this last check is based on the recent TZ issues to make sure nothing slipped through). Other than that trusting on the testing I was involved in over the last month or so. On Fri, Apr 12, 2024 at 1:37 PM João Jandre wrote: > > Hi All, > > I've created a 4.18.2.0 release (RC2), with the following artifacts up > for a vote: > > Git Branch and Commit SH: > https://github.com/apache/cloudstack/tree/4.18.2.0-RC20240412T0825 > Commit: 154566f914c778d448d4ab07b47b2db874bbf982 > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/4.18.2.0/ > > PGP release keys (signed using 488D90DA107445E3243D162606F3CEC65B335790): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > Vote will be open for 120 hours (due to the weekend). > > 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) > -- Daan
Re: New PMC member: Slavka Peleva
welcome aboard @slav...@apache.org On Wed, Apr 10, 2024 at 1:11 PM Ivet Petrova wrote: > > Hello all, > > The Project Management Committee (PMC) for Apache CloudStack > has invited Slavka Peleva to become a PMC member and we are pleased > to announce that they have accepted. > > Slavka has contributed in the past and has shown effort to make the > project run smoothly > > Please join me in congratulating Slavka! > > > Best regards, > > > > -- Daan
Re: New Committer: Kiran Chavala
Welcome to the group kiran. Now the hard work starts ;) On Tue, Apr 9, 2024 at 7:46 AM Rohit Yadav wrote: > > The Project Management Committee (PMC) for Apache CloudStack > has invited Kiran Chavala (kiranchavala) to become a committer and > we are pleased to announce that they have accepted. > > Kiran has been a long time CloudStack contributor and has created > over a hundred issues on Github. Being a committer enables easier > contribution to the project and enable better productivity. > > Please join me in congratulating Kiran! > > Regards. -- Daan
Re: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0
I was pointed out that I did not formally vote in this mai: +1 (binding) On Fri, Apr 5, 2024 at 1:02 PM Daan wrote: > > Kiran, the release looks good, the format of the hashes is a bit off but on > manual inspection they seem ok. I created a PR to correct thsi for next time > : https://github.com/apache/cloudstack-terraform-provider/pull/108 > I don't think that needs to block this RC > > On 2024/04/04 06:30:22 Kiran Chavala wrote: > > Hi All, > > > > Reminder – terraform 0.5.0 is up for testing and voting. > > > > Regards. > > Kiran > > > > From: Rohit Yadav > > Date: Wednesday, 3 April 2024 at 9:43 AM > > To: dev@cloudstack.apache.org , > > us...@cloudstack.apache.org > > Subject: Re: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0 > > +1 (binding) > > > > Tested vm deployment using 0.5.0-pre. > > > > Regards. > > > > > > > > > > > > > > > > From: Kiran Chavala > > Sent: Tuesday, April 2, 2024 2:55:40 PM > > To: dev@cloudstack.apache.org ; > > us...@cloudstack.apache.org > > Subject: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0 > > > > Hi ALL > > > > I've created a CloudStack Terraform Provider v0.5.0 release, with the > > following artifacts up for a vote: > > > > Git Branch and Commit SH: > > > > https://github.com/cloudstack/terraform-provider-cloudstack > > > > Commit: 7c682bf17bebf40837a30ebcca811fc7b8785a15 > > > > Source release (checksums and signatures are available at the same > > location): > > https://dist.apache.org/repos/dist/dev/cloudstack/terraform-provider-0.5.0/ > > > > PGP release keys (signed using E03379CB066175FAC2BC9E027B3F1C5E93F97FAB): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > Vote will be open for 72 hours. > > > > 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, they can use this 0.5.0-pre build > > https://registry.terraform.io/providers/cloudstack/cloudstack/0.5.0-pre for > > testing purposes. > > The binaries are here: > > https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre > > > > > > Regards > > Kiran Chavala > > > > > >
Re: [VOTE] Apache CloudStack 4.18.2.0 RC1
ok, if it is a regression (introduction of a bug on formerly working functionality) It would mean a blocker and we can easily respin a new RC. What do you think @João Jandre Paraquetti ? On Mon, Apr 8, 2024 at 10:43 AM Rene Peinthor wrote: > > Probably neither a blocker or critical, assuming the same bug (other > driver) is currently in 4.19.0. > But I feel bad knowing, that I would introduce a bug for other storage > drivers. > > On Mon, Apr 8, 2024 at 10:30 AM Daan Hoogland > wrote: > > > Rene, is this a blocker (or critical issue) in your opinion ? > > > > On Mon, Apr 8, 2024 at 8:06 AM Rene Peinthor > > wrote: > > > > > > -1 > > > > > > Because I would still this to be included: > > > https://github.com/apache/cloudstack/pull/8790 > > > > > > On Fri, Apr 5, 2024 at 9:11 PM João Jandre wrote: > > > > > > > Hi All, > > > > > > > > I've created a 4.18.2.0 release (RC1), with the following artifacts up > > > > for a vote: > > > > > > > > Git Branch and Commit SH: > > > > https://github.com/apache/cloudstack/tree/4.18.2.0-RC20240405T1541 > > > > Commit: 0d19ffa61c76f592c77ea04a982e15e8575ceb45 > > > > > > > > Source release (checksums and signatures are available at the same > > > > location): > > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.18.2.0/ > > > > > > > > PGP release keys (signed using > > 488D90DA107445E3243D162606F3CEC65B335790): > > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > > > > > Vote will be open for 120 hours (due to the weekend). > > > > > > > > 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) > > > > > > > > > > > > -- > > Daan > > -- Daan
Re: [VOTE] Apache CloudStack 4.18.2.0 RC1
Rene, is this a blocker (or critical issue) in your opinion ? On Mon, Apr 8, 2024 at 8:06 AM Rene Peinthor wrote: > > -1 > > Because I would still this to be included: > https://github.com/apache/cloudstack/pull/8790 > > On Fri, Apr 5, 2024 at 9:11 PM João Jandre wrote: > > > Hi All, > > > > I've created a 4.18.2.0 release (RC1), with the following artifacts up > > for a vote: > > > > Git Branch and Commit SH: > > https://github.com/apache/cloudstack/tree/4.18.2.0-RC20240405T1541 > > Commit: 0d19ffa61c76f592c77ea04a982e15e8575ceb45 > > > > Source release (checksums and signatures are available at the same > > location): > > https://dist.apache.org/repos/dist/dev/cloudstack/4.18.2.0/ > > > > PGP release keys (signed using 488D90DA107445E3243D162606F3CEC65B335790): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > Vote will be open for 120 hours (due to the weekend). > > > > 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) > > -- Daan
Re: Re-Introduction
nice to see you again Sina ;) On Sun, Mar 17, 2024 at 10:10 PM Sina Kashipazha wrote: > > Dear All, > > My name is Sina Kashipazha, and you may remember me from my time at Leaseweb. > I wanted to take this opportunity to reintroduce myself as I have recently > joined ComplianceWise. > > I work as a software engineer, where I've had the opportunity to engage with > cloud computing technologies and expand my understanding of scalable > solutions. While my programming repertoire includes JavaScript, Python, and > Go, my primary strength lies in Java, which is the cornerstone of my skill > set for tackling various projects. Beyond programming, my expertise extends > into networking and containerization, equipping me with a comprehensive skill > set to design and optimize sophisticated, scalable systems efficiently. > > My first few months at ComplianceWise were very busy as I focused on adapting > to my new role. Now that I am more settled, I am ready to take on new > challenges and actively contribute to our community's projects once more. > > I'm looking forward to re-engaging with you all and contributing to Apache > CloudStack's success in any way I can. Please feel free to reach out if you > have any PRs or issues you think I could help with. > > Warmest regards, > Sina Kashipazha -- Daan
[ANNOUNCE] Rene Peinthor as committer
devs and users, The PMC have asked Rene Peinthor to become a committer to the Apache CloudStack project and they have accepted. Please join me in congratulating Rene. -- Daan
Re: [ANNOUNCE] New PMC Chair & VP Apache CloudStack Project - Daniel Salvador
thanks Rohit, go Daniel On Thu, Mar 21, 2024 at 2:45 PM Rohit Yadav wrote: > > All, > > It gives me great pleasure to announce that the ASF board has accepted > CloudStack PMC resolution of Daniel Augusto Veronezi Salvador as the next PMC > Chair / VP of the Apache CloudStack project. > > I would like to thank everyone for the support I've received over the past > year. > > Please join me in congratulating Daniel, the new CloudStack PMC Chair / VP. > > Best Regards, > Rohit Yadav -- Daan
[PROPOSE] upgrade paths for 4.19 and 20
devs, currently we have an upgrade path for 4.19.0.0 to 4.19.1.0 in the 4.19 branch in the main branch we have a 4.19.0.0 to (4.)20.0.0 upgrade path merging fails because of this and allowing either or both in main will cause main to fail (at least after upgrading) If we are sure that 4.19.1 will be release and will be released before 20 we can move the main upgrade path to be from 4.19.1 to 20 (never mind the 4. or not) If we do not release a 4.19.1 (first) we will have to move the path back to originate from 4.19.0 Is this a sane strategy for now? If no-one objects I'll do the forward merge after the weekend. -- Daan
Re: [VOTE] next version 20 instead of 4.20
version, Z > > is the patch number. The community strives to ensure backward API > > compatibility within each major version (i.e.: code written against the > > CloudStack 4.0.0-incubating API should work with all future 4.y.z > > versions). The community may decide to increment the major version number > > in situations where underlying implementation details require a cloud > > operator to face significant challenges in upgrading from one version to > > the next. This should be rare situation. > > > > In practice, feature releases will normally be an increment of the minor > > version number of the project. Feature releases that break backward > > compatibility will cause the major version number to be incremented. Bug > > fix releases will never increment anything except the patch number. > > -- End quote. > > > > > > Specifically: > > The community may decide to increment the major version number in > > situations where underlying implementation details require a cloud operator > > to face significant challenges in upgrading from one version to the next. > > This should be rare situation. > > > > > > From this I can't see how we have broken the versioning. Have we > > introduced anything that meets the criteria above? Again, the term 'minor > > version' is an unfortunate one because it makes it sound like it wouldn’t > > contain big new features. However, that isn't the case, it can and should. > > > > Also, I'd like to see fully laid out for the next few versions, how > > versioning is proposed to work, and what each part of x.y.z.n is then going > > to denote. > > > > - Paul > > > > -Original Message- > > From: Daan Hoogland > > Sent: Tuesday, February 20, 2024 10:05 AM > > To: us...@cloudstack.apache.org > > Cc: dev@cloudstack.apache.org > > Subject: Re: [VOTE] next version 20 instead of 4.20 > > > > Vivek, we could, but the main idea is that we repair our versioning system > > and make clear how we are actually dealing with our current system, which > > is major - new , possibly breaking features minor - improvements and > > enhancements tiny - urgent (security) fixes > > > > and in addition we would go to 20 to indicate that is the follower of > > 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for > > instance) but this would not have anything to do with our current > > versioning system. > > > > On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar > > wrote: > >> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..! > >> > >> > >>> On 19-Feb-2024, at 10:49 PM, Paul Angus wrote: > >>> > >>> Hi Daan, > >>> > >>> Can you clarify what we are actually voting on please. > >>> > >>> In thread that is linked I've seen: > >>> > >>> "[the vote] will be to adjust to the semantic versioning system." > >>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 > >>> breaks semantic versioning [1]. > >>> > >>> " drop the 4 at version 20 and continue as usual with minor and patch > >>> level updates as we have in the past." > >>> - what's supposed to come next ? in lieu of what would have been 4.21 > >>> will it be 21 ? is it going to be 20.1 then 20.2 ? > >>> > >>> From the thread and how people are referring to 'minor versions', there > >>> is a misunderstanding as to what semantic versioning means. For our > >>> project its explained here [1]. Major versions meaning "probably going > >>> to break a load of people's stuff', with minor versions not breaking > >>> stuff (at least not on purpose). So I get calling them minor versions > >>> really underplays the changes it can hold. > >>> > >>> > >>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think > >>> the vote should be on 'A change to the version numbering scheme' and then > >>> what is proposed properly laid out. > >>> > >>> > >>> > >>> > >>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases > >>> (section on versioning about 2/3 down) > >>> > >>> -Original Message- > >>> From: Daan Hoogland > >>> Sent: Monday, February 19, 2024 12:50 PM > >>> To: dev > >>> Cc: users > &g
new committer: Vishesh Jindal (vishesh)
users and devs, The Project Management Committee (PMC) for Apache CloudStack has invited Vishesh Jindal to become a committer and we are pleased to announce that they have accepted. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Please join me in congratulating Vishesh. -- on behalf of the PMC, Daan
Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes and in addition we would go to 20 to indicate that is the follower of 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for instance) but this would not have anything to do with our current versioning system. On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar wrote: > > Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..! > > > > On 19-Feb-2024, at 10:49 PM, Paul Angus wrote: > > > > Hi Daan, > > > > Can you clarify what we are actually voting on please. > > > > In thread that is linked I've seen: > > > > "[the vote] will be to adjust to the semantic versioning system." > > - you can't go to 20 AND keep semantic versioning. The act of going to 20 > > breaks semantic versioning [1]. > > > > " drop the 4 at version 20 and continue as usual with minor and patch level > > updates as we have in the past." > > - what's supposed to come next ? in lieu of what would have been 4.21 will > > it be 21 ? is it going to be 20.1 then 20.2 ? > > > > From the thread and how people are referring to 'minor versions', there is > > a misunderstanding as to what semantic versioning means. For our project > > its explained here [1]. Major versions meaning "probably going to break a > > load of people's stuff', with minor versions not breaking stuff (at least > > not on purpose). So I get calling them minor versions really underplays the > > changes it can hold. > > > > > > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think > > the vote should be on 'A change to the version numbering scheme' and then > > what is proposed properly laid out. > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases > > (section on versioning about 2/3 down) > > > > -Original Message- > > From: Daan Hoogland > > Sent: Monday, February 19, 2024 12:50 PM > > To: dev > > Cc: users > > Subject: [VOTE] next version 20 instead of 4.20 > > > > LS, > > > > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be > > counted please reply to dev@. > > > > As discussed in [1] we are deciding to drop the 4 from our versioning > > scheme. The result would be that the next major version will be 20 instead > > of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the > > versions are processed numerically there are no technical impediments. > > > > +1 agree (next major version as 20 > > 0 (no opinion) > > -1 disagree (keep 4.20 as the next version, give a reason) > > > > As this is a lazy consensus vote any -1 should be accompanied with a reason. > > > > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 > > > > -- > > Daan > > > -- > This message is intended only for the use of the individual or entity to > which it is addressed and may contain confidential and/or privileged > information. If you are not the intended recipient, please delete the > original message and any copy of it from your computer system. You are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited unless proper authorization has been > obtained for such action. If you have received this communication in error, > please notify the sender immediately. Although IndiQus attempts to sweep > e-mail and attachments for viruses, it does not guarantee that both are > virus-free and accepts no liability for any damage sustained as a result of > viruses. -- Daan
Re: [VOTE] next version 20 instead of 4.20
Paul, On Mon, Feb 19, 2024 at 6:21 PM Paul Angus wrote: > > Hi Daan, > > Can you clarify what we are actually voting on please. > > In thread that is linked I've seen: > > "[the vote] will be to adjust to the semantic versioning system." > - you can't go to 20 AND keep semantic versioning. The act of going to 20 > breaks semantic versioning [1]. We are using a crooked semantic versioning system and that is entirely due to maintaining the 4 in our versioning scheme. We have been changing and adding major features on updating the second number (20 to be). We have been using the third number for bug fixes and minor enhancements. And we have been using the fourth number for emergency security fixes. So we are not maintaining semantic versioning but going to semantic versioning by repairing our system of versioning. You could say this is a minor bugfix. > > " drop the 4 at version 20 and continue as usual with minor and patch level > updates as we have in the past." > - what's supposed to come next ? in lieu of what would have been 4.21 will it > be 21 ? is it going to be 20.1 then 20.2 ? Yes, exactly. Except for dropping the 4, nothing will change. > > From the thread and how people are referring to 'minor versions', there is a > misunderstanding as to what semantic versioning means. For our project its > explained here [1]. Major versions meaning "probably going to break a load > of people's stuff', with minor versions not breaking stuff (at least not on > purpose). So I get calling them minor versions really underplays the changes > it can hold. > > > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the > vote should be on 'A change to the version numbering scheme' and then what is > proposed properly laid out. > > > > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases > (section on versioning about 2/3 down) > > -Original Message- > From: Daan Hoogland > Sent: Monday, February 19, 2024 12:50 PM > To: dev > Cc: users > Subject: [VOTE] next version 20 instead of 4.20 > > LS, > > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted > please reply to dev@. > > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. > The result would be that the next major version will be 20 instead of 4.20, > as it would be in a traditional upgrade. As 20 > 4 and the versions are > processed numerically there are no technical impediments. > > +1 agree (next major version as 20 > 0 (no opinion) > -1 disagree (keep 4.20 as the next version, give a reason) > > As this is a lazy consensus vote any -1 should be accompanied with a reason. > > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 > > -- > Daan -- Daan
[VOTE] next version 20 instead of 4.20
LS, This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@. As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments. +1 agree (next major version as 20 0 (no opinion) -1 disagree (keep 4.20 as the next version, give a reason) As this is a lazy consensus vote any -1 should be accompanied with a reason. [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 -- Daan
Re: [PROPOSAL] version naming : drop the 4.
Well, to all users@these lists, please comment. The ratio is that cloudstack is called cloudstack4 as an evolutionary result from the development at cloud.com and citrix and that all version since 4.0 (the apache podling version) are basically major versions according to semantic versioning. Keeping the 4 as version number has no technical meaning and obfuscates the true state of the software. The idea is that we drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past. Not all of the discussion around this is included in this mail, but you can find it at https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 *Any* feedback is welcome. On Thu, Feb 15, 2024 at 12:01 PM Rohit Yadav wrote: > > (+ users) > > All, > > Generally speaking, any versioning/styling change can be perceived as a big > or concerning change by users (those existing or new ones trying/adopting). > So, we must get our message across properly and correctly. > > I'm not for or against cosmetics change in versioning, but I'm really keen if > we want to discuss if we can use this opportunity to streamline our LTS > release, improve how we upgrade CloudStack (i.e relook at our DB/upgrade > approach), make releases more linear and faster (avoid forking branches for > example), and try to change new defaults and drop some old API/arch things > (such as default API response type to json, but largely be backward > compatible). Some of these suggestions may be too large an undertaking and > make not be worth it. > > > Overall, I've no objections if the consensus is to drop the "4." version > prefix. I also want to hear from our users if they've any feedback for us. > > > Regards. > > > > > > From: Guto Veronezi > Sent: Tuesday, February 13, 2024 18:34 > To: dev@cloudstack.apache.org > Subject: Re: [PROPOSAL] version naming : drop the 4. > > Daan, > > As we still plan to introduce disruptive changes (in a cautious and > structured way) in the major versions, all my concerns are met; I do not > have further technical reasons to keep the "4.". > > Best regards, > Daniel Salvador (gutoveronezi) > > On 2/12/24 11:55, Daan Hoogland wrote: > > bump, > > @Daniel Salvador is there any technical reason to keep the 4? any > > reason why there must be a 5 instead of a 21, 22 or 23? We are > > maintaining 4 number semantic versioning for no reason, as I see it. > > > > On Tue, Jan 30, 2024 at 12:02 PM Daan Hoogland > > wrote: > >> Daniel, "technical" reasons for dropping the 4 are all in the field of > >> social engineering. In practice (as I think Wei also described) we are > >> already treating the "minor" version number as major version. Since > >> 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but > >> never enough reason and or commitment to make it real. We could argue > >> about it a lot. > >> > >> so > >> ¨¨¨ > >> The main point is: *we have to understand the technical reasons for > >> the proposal and what we expect from it before deciding anything. > >> ¨¨¨ > >> The most important point is that we expect that people understand that > >> we treat the number that now seems to be "minor" as major release > >> numbers. > >> > >> > >> On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU wrote: > >>> Hi Daniel, > >>> > >>> If we are discussing 5.0, I would have the same concern as you. > >>> What we are discussing is dropping 4.x. The fact is, we will never release > >>> 5.0 (anyone disagree ?) > >>> In this case, the major version 4.x becomes useless. > >>> If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better. > >>> IMHO due to the similar reason, the Java version has been changed from 1.x > >>> to java 1.7/1.8 (=java 7/8) then to java 11/14/17. > >>> of course there will be some issues if semantic changes, I think it is > >>> under control. > >>> > >>> > >>> > >>> Regarding the compatibility, I think we can change the APIs gradually. > >>> I noticed the following recently when I tested VR upgrade to > >>> debian12/python3 > >>> > >>> root@r-431-VM:~# python > >>> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux > >>> Type "help", "copyright", "credits" or "license" for more information. > >>>>>> import cgi >
Re: [DISCUSS] Closing issues & PR after a certain time
i'm a bit -0 on this. I agree that a lot of stale issues deserve closing, but others are really long term goals. I do not want to block this great idea but am just a bit worried about other great ideas getting lost. So I would propose to tag anything we close or not remove the stale tag, so these can be easily found. I am not worried too much about PRs, just issues. On the other hand, we can always remove the gha again, so maybe we should install it and see if it works for us. On Wed, Feb 14, 2024 at 4:49 AM Kiran Chavala wrote: > > Good idea Vishesh > > +1 for using Githubactions > > Regards > Kiran > > From: Vishesh Jindal > Date: Tuesday, 13 February 2024 at 6:33 PM > To: dev@cloudstack.apache.org > Subject: [DISCUSS] Closing issues & PR after a certain time > Hi everyone, > > I was going through the issues and PRs, and I noticed that a lot of them are > really old and some of them are waiting for the original author to reply. > > I wanted to discuss if we should add a github action > (https://github.com/marketplace/actions/close-stale-issues) for auto closing > the issues and PRs after a certain time. > > From the github actions' documentation, this is how it works: > > * Add a label "Stale" on issues and pull requests after 60 days of > inactivity and comment on them > * Close the stale issues and pull requests after 7 days of inactivity > * If an update/comment occur on stale issues or pull requests, the stale > label will be removed and the timer will restart > > Instead of using the defaults, I would like to: > > * > mark the issue/PR stale after 90 days > * > close the stale issue/PR after 30 days > > Let me know if this sounds good. I will create the PR to set this up. > > Regards, > Vishesh > > > > > > > > -- Daan
Re: [PROPOSAL] version naming : drop the 4.
bump, @Daniel Salvador is there any technical reason to keep the 4? any reason why there must be a 5 instead of a 21, 22 or 23? We are maintaining 4 number semantic versioning for no reason, as I see it. On Tue, Jan 30, 2024 at 12:02 PM Daan Hoogland wrote: > > Daniel, "technical" reasons for dropping the 4 are all in the field of > social engineering. In practice (as I think Wei also described) we are > already treating the "minor" version number as major version. Since > 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but > never enough reason and or commitment to make it real. We could argue > about it a lot. > > so > ¨¨¨ > The main point is: *we have to understand the technical reasons for > the proposal and what we expect from it before deciding anything. > ¨¨¨ > The most important point is that we expect that people understand that > we treat the number that now seems to be "minor" as major release > numbers. > > > On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU wrote: > > > > Hi Daniel, > > > > If we are discussing 5.0, I would have the same concern as you. > > What we are discussing is dropping 4.x. The fact is, we will never release > > 5.0 (anyone disagree ?) > > In this case, the major version 4.x becomes useless. > > If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better. > > IMHO due to the similar reason, the Java version has been changed from 1.x > > to java 1.7/1.8 (=java 7/8) then to java 11/14/17. > > of course there will be some issues if semantic changes, I think it is > > under control. > > > > > > > > Regarding the compatibility, I think we can change the APIs gradually. > > I noticed the following recently when I tested VR upgrade to > > debian12/python3 > > > > root@r-431-VM:~# python > > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import cgi > > :1: DeprecationWarning: 'cgi' is deprecated and slated for removal > > in Python 3.13 > > > > For the API changes you mentioned, we could try the similar > > - in version X, add new APIs, mark the old APIs as deprecated > > - tell users the old APIs will be removed in version Y, please use new APIs > > instead. > > - in version Y, remove the old APIs. > > > > This can be done in each major/minor release. No need to wait for 5.0. > > > > > > -Wei > > > > On Fri, 26 Jan 2024 at 18:51, Guto Veronezi wrote: > > > > > Exactly, so you understand now why we must discuss what we intend. > > > Although, incompatibilities are needed sometimes so we can evolve, > > > leaving old ways and deprecated technologies and techniques in the past. > > > > > > *The main point is: *we have to understand the technical reasons for the > > > proposal and what we expect from it before deciding anything. > > > > > > Best regards, > > > Daniel Salvador (gutoveronezi) > > > > > > > > > > > > > -- > Daan -- Daan
Re: [PROPOSE] RM for 4.19.1.0
no worries as João proposed to release 4.18.2 in march, but let's make sure we have a good period between the two. On Mon, Feb 12, 2024 at 12:50 PM Suresh Anaparti wrote: > > Hi All, > > CloudStack 4.19.0.0 is the latest LTS release. There are already some open > issues [1] and pull requests [2] targeted for 4.19.1.0 [3] release. > > I'd like to propose and put myself forward as the release manager for > 4.19.1.0 if no objections there. Please ping me (@sureshanaparti) on GitHub, > in case you want to include any Issue/PR in 4.19.1.0. > > I propose to have a window of at least 8 weeks (2 months), which allows the > community / users to test, use 4.19.0.0 and report any issues. We can aim to > cut RC1 in Q2 2024 (maybe, sometime in May-2024). I'll propose the timeline > details soon. I hope to have your support. > > Please let me know if you have any thoughts/comments. > > [1] > https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.19.1.0 > [2] > https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.19.1.0+is%3Aopen > [3] https://github.com/apache/cloudstack/milestone/31 > > > Regards, > Suresh > > > -- Daan
Re: Adding Huawei Object Storage: 3 questions
On Fri, Feb 9, 2024 at 9:38 AM Ronald Feicht wrote: > > Hi, > > > >> The Huawei Object Storage Java SDK does not yet support bucket > >> encryption. What should I return in the corresponding methods > >> "setBucketEncryption" and "deleteBucketEncryption" - true, false or > >> throw an exception? > > > This is a design decision that the code should already be clear on (in > > for instance the minio plugin) . Strangely, the DeleteBucketCmd always > > creates a success response, while the CreateBucketCmd handles > > exceptions as expected. I think there is a bug in DeleteBucketCmd in > > that respect. > > > Actually, looking at the MinIO or simulator plugin, the design decision is > not clear at all: > > "setBucketEncryption" and "deleteBucketEncryption" both have a boolean as > return value, but only ever return true or throw an exception, yet, never > return false. So, it boils down to "Everything went well unless an exception > is thrown." Normally in Java this kind of behavior is achieved by a "void" > return value. Therefore I naturally wondered when my methods should return > false. The intention behind the boolean might have been: > > true -- the method set / deleted the bucket encryption, respectively > > exception -- the method should have completed but some unforeseen > out-of-the-ordinary error occurred, e. g. network connection error > > false -- the device was purchased without a license for bucket-level > encryption; unless a valid encryption license is installed into the device, > this method will always continue to return false That sounds reasonable to me. I think you should stick to it. > > I gues your PR is https://github.com/apache/cloudstack/pull/8359. You > > can look at the ./deps/install-non-oss.sh or at > > > https://github.com/shapeblue/cloudstack-nonoss/blob/main/install-non-oss.sh > > to see how these situations are handled. This method would require you > > to hide your sub-project behind the -Dnoredist flag. which is an > > inconvenience but is the only way to deal with those > > non-redistributables. If Huawei allows, we can add the jar in that > > repo. > > > It seems to me like this will not work, because an Object Storage Plugin has > to be added to client/pom.xml and the provider's name into > ui/src/views/infra/AddObjectStorage.vue? Hardcoding my plugin into those > places would result in the client/pom.xml not building and my provider to be > available in the UI's dropdown selection even though the corresponding plugin > is not present on the classpath? I know some other components are also conditionally coded in the UI, like vmware. That should be taken care of. > Or is there some dynamic dependency injection class scanning going on at > runtime which detects all plugin provider beans at runtime and sends their > ObjectStoreProvider instance variable "providerName" property to the UI to > populate the dropdown selection? When a plugin is selected in the UI this > would then trigger the client/pom.xml project to do a dynamic bean lookup to > find the correct ObjectStoreProvider class by "providerName"? If this dynamic > bean discovery is actually being done I would not have to add my project to > client/pom.xml or into the "AddObjectStorage.vue" file? So, I guess dynamic > bean discovery is NOT done? I am not sure of all these question, but the client does [listCapabilities](https://cloudstack.apache.org/api/apidocs-4.19/apis/listCapabilities.html) and [listApis](https://cloudstack.apache.org/api/apidocs-4.19/apis/listApis.html) calls to retrieve whatever information it needs to prepare the proper UI components. (I am not saying no design issues may have been introduced in the object storage plugins) > I have next to no experience with the Spring (Boot) framework, only with Java > SE / Jakarta EE and CDI / Weld, so maybe I just overlooked something very > important in the code base, but from what information I was able to gather it > seems like I should not be contributing my plugin upstream unless I can add > the JAR library in question via Maven coordinates. > > > And judging from the fact that Huawei has still not answered my request to > publish the OBS SDK with Maven coordinates, I assume that this is the > "chinese way" of saying "Nope, not going to happen!". sounds so :( > > > Mit freundlichen Grüßen > R. Feicht > > sc synergy GmbH > Hilgestrasse 14 | 55294 Bodenheim | Deutschland > Fon: +49 6135 71691 - 000 | Fax: +49 6135 71691 - 299 > http://www.scsynergy.com | ronald.fei...@scsynergy.com > Sitz der Gesellschaft
[DISCUSS][PROPOSAL] web site publishing procedure
devs (and PMC), I created a procedure based on a staging->production promotion of PRs. it is described in the readme file [1] I went ahead and created it as we didn't have anything before. That does not mean I get to decide on my own, so please add your unsalted comment or create/add change proposals in the www issues [2] This has been kind of attic work coming out at the last moment, please forgive me someday. I am open to all changes to it. [1] https://github.com/apache/cloudstack-www?tab=readme-ov-file#publishing-procedure [2] https://github.com/apache/cloudstack-www/issues/new/choose -- Daan
new website is life
People, we brought the new website. Please all have a look at https://cloudstack.apache.org thanks for any feedback -- Daan
[RESULT][VOTE] go life with new website(design)
The vote has passed with 6 * +1 0 * 0 0* -1 On Thu, Feb 1, 2024 at 1:32 PM Daan Hoogland wrote: > > LS, > > I am not sure this is still needed after all the discussions > before,but I would like to start a lazy consent vote threat anyway > there are some non-blocking rest points mentioned and we can > administer those in the repo for the site [1] > > so without further ado; > Do we want to go life with the website as staged in > cloudstack.staged.apache.org > > +1 yes > 0 no opinion (no reaction suffices as well) > -1 no (please state reasons > > > [1] https://github.com/apache/cloudstack-www/issues/new/choose
Re: [ANNOUNCEMENT] Apache CloudStack 4.19.0.0 LTS Release
thanks Abhi, for all the hard work. On Tue, Feb 6, 2024 at 12:37 PM Abhishek Kumar wrote: > > The Apache Software Foundation and the Apache CloudStack Project Announces > Apache® CloudStack® v4.19. > > Apache CloudStack 4.19 is the most recent release of the cloud management > platform. It comes as a product of extensive contributions from the > development community and is a LTS release, guaranteeing ongoing > maintenance and support for a period of 18 months > > The 4.19 release contains 314 new features, improvements and bug fixes > since 4.18, 26 of these being major features. > > Some of the highlighted features include: > > - VMware to KVM Migration > > - KVM Import > > - CloudStack Object Storage > > - CloudStack DRS > > - VNF Appliances Support > > - Scheduled Instance Lifecycle Operations > > - OAuth 2 Authentication > > - CloudStack Snapshot Copy > > The full list of new features can be found in the project release notes at: > https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes > > > The CloudStack documentation includes upgrade instructions from previous > versions of Apache CloudStack, and can be found at: > https://docs.cloudstack.apache.org/en/4.19.0.0/upgrading > > The official installation, administration and API documentation for each of > the releases are available on our documentation page: > https://docs.cloudstack.apache.org/en/4.19.0.0/installguide > > Downloads > > The official source code for the 4.19.0.0 release can be downloaded from > our downloads page: https://cloudstack.apache.org/downloads.html > > In addition to the official source code release, individual contributors > have also made convenience binaries available on the Apache CloudStack > download page, and can be found at: > > - https://download.cloudstack.org/el/7/ > > - https://download.cloudstack.org/el/8/ > > - https://download.cloudstack.org/el/9/ > > - https://download.cloudstack.org/ubuntu/dists/ > > - https://www.shapeblue.com/cloudstack-packages/ > > > Regards, > > Abhishek -- Daan
[VOTE] go life with new website(design)
LS, I am not sure this is still needed after all the discussions before,but I would like to start a lazy consent vote threat anyway there are some non-blocking rest points mentioned and we can administer those in the repo for the site [1] so without further ado; Do we want to go life with the website as staged in cloudstack.staged.apache.org +1 yes 0 no opinion (no reaction suffices as well) -1 no (please state reasons [1] https://github.com/apache/cloudstack-www/issues/new/choose
Re: Adding Huawei Object Storage: 3 questions
Ronald, On Wed, Jan 31, 2024 at 10:02 AM Ronald Feicht wrote: > > Hi, > > I have only lately found out, that I cannot use the publicly available > Java SDK for Huawei Object Storage (which has Maven coordinates) as this > SDK only works for the public Huawei Cloud, not for local non-cloud > devices. Instead, all I have is a JAR file under the Apache License 2.0 > sent to me via email. I integrated that JAR file as a local repository > inside plugins/storage/object/huawei-obs/local-huawei-sdk/. This is a > quite ugly and frustrating "solution" as I have no influence on getting > the right Java SDK published to maven central. I have opened a support > ticket with Huawei asking whether I may include the JAR into the > Cloudstack source code or better yet if they would be so kind as to > publish it via maven central - but have not received an answer, yet. > What is the official way for integrating local-only JAR files under the > Apache License 2.0 into Cloudstack? I gues your PR is https://github.com/apache/cloudstack/pull/8359. You can look at the ./deps/install-non-oss.sh or at https://github.com/shapeblue/cloudstack-nonoss/blob/main/install-non-oss.sh to see how these situations are handled. This method would require you to hide your sub-project behind the -Dnoredist flag. which is an inconvenience but is the only way to deal with those non-redistributables. If Huawei allows, we can add the jar in that repo. > The Huawei Object Storage Java SDK does not yet support bucket > encryption. What should I return in the corresponding methods > "setBucketEncryption" and "deleteBucketEncryption" - true, false or > throw an exception? This is a design decision that the code should already be clear on (in for instance the minio plugin) . Strangely, the DeleteBucketCmd always creates a success response, while the CreateBucketCmd handles exceptions as expected. I think there is a bug in DeleteBucketCmd in that respect. > My assumption: The "createUser" method gets called via the UI by an > account wishing to create a simple non-privileged user which may then > use the created buckets of that account, but not create, modify or > delete buckets themselves? Is this assumption correct? Users log into accounts and get their rights based on the account. For all users in an account the rights are the same. sorry, I might not have gotten it but I no better answer on that (see the code ;) > > Best regards, > Ronald > -- > *sc synergy GmbH* > Hilgestrasse 14 | 55294 Bodenheim | Deutschland > Fon: +49 6135 71691 - 000 | Fax: +49 6135 71691 - 299 > http://www.scsynergy.com | ronald.fei...@scsynergy.com > Sitz der Gesellschaft Bodenheim, HRB 8830, Amtsgericht Mainz, > Geschäftsführer: Christian Reichert -- Daan
Re: new website design
I've been improving any points I got as criticism on the site. I will start a vote thread soon, though I don't think it is strictly necessary. please have a final run through if you have time, thanks, On Tue, Jan 23, 2024 at 1:08 PM Rohit Yadav wrote: > > +1 overall, but there are a few things I would consider blockers: > > 1. the blog page doesn't look same as on current blog (prod). > > https://cloudstack.staged.apache.org/blog (staging blog) > > versus > > https://cloudstack.apache.org/blog/ (current blog/prod.) > > If we can fix the blog listing and the that should be okay. > > 2. The colour of the buttons in some places are different shades of blue, for > example on https://cloudstack.staged.apache.org the download/documentation > button and scroll down, we see button with a violet/navy-blue shade. Minor > css issue? I would expect button to match the theme, for example button > colour as in https://cloudstack.apache.org/blog/india-user-group-2024 > > 3. Fact check all pages, for example the staging landing says 4.18.0.0 is > latest release and link/content around events. Before we migrate/transition, > all data must be latest/accurate as possible. > > 4. Minor issue - the logo on the staging site's landing page, uses old > dashboard, that could be replaced with what the latest/most-recent dashboard > looks like. > > > > Regards. > > > From: Sven Vogel > Sent: Monday, January 22, 2024 18:30 > To: dev@cloudstack.apache.org ; > priv...@cloudstack.apache.org > Cc: users > Subject: Re: new website design > > +1 looks nice > > Am Montag, den 01/22/2024 um 11:46 schrieb Nux: > > > > +1 - do it. > > On 2024-01-19 14:50, Daan Hoogland wrote: > > As we get no major issues on it and we already voted to have this > > design applied, is it alright to deploy this in the coming weeks? > > > > On Wed, Jan 17, 2024 at 8:31 PM Daan Hoogland > > wrote: > >> > >> devs and users, > >> > >> back in august we had a small discussion about a new website > design, > >> led by Ivet [1]. In the meanwhile Rohit had investigated using > >> docusaurus as a publishing mechanism for the site. After the last > few > >> weeks I have been working on integrating the two. The result so far > >> can be viewed on the staging site [2] > >> > >> Please all have a look and give me any feedback you may have, so we > >> can move this forward. > >> > >> [1] > https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso > >> [2] https://cloudstack.staged.apache.org/ > >> > >> -- > >> Daan > > > -- Daan
Re: [VOTE] Apache CloudStack 4.19.0.0 RC4
signatures ok, +1 (binding) will also do a monkey test on simulator and retract my +1 if needed ;) On Mon, Jan 29, 2024 at 7:58 AM Abhishek Kumar wrote: > > Hi All, > > I've created a 4.19.0.0 release (RC4), with the following artifacts up for > a vote: > > Git Branch and Commit SH: > https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240129T1021 > Commit: 2746225b999612f156e421199e34ef8de98a3664 > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/ > > PGP release keys (signed using 65518106473A09D7AF26B384A70BD2EAA74E2866): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > For testing purposes, I have uploaded the different distro packages to: > http://download.cloudstack.org/testing/4.19.0.0-RC4/ > > Since 4.16 the system VM template registration is no longer mandatory > before upgrading, however, it can be downloaded from here if needed: > https://download.cloudstack.org/systemvm/4.19/ > > The vote will be open for 72 hours. > > 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) > > Regards, > Abhishek -- Daan
Re: [PROPOSAL] version naming : drop the 4.
Daniel, "technical" reasons for dropping the 4 are all in the field of social engineering. In practice (as I think Wei also described) we are already treating the "minor" version number as major version. Since 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but never enough reason and or commitment to make it real. We could argue about it a lot. so ¨¨¨ The main point is: *we have to understand the technical reasons for the proposal and what we expect from it before deciding anything. ¨¨¨ The most important point is that we expect that people understand that we treat the number that now seems to be "minor" as major release numbers. On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU wrote: > > Hi Daniel, > > If we are discussing 5.0, I would have the same concern as you. > What we are discussing is dropping 4.x. The fact is, we will never release > 5.0 (anyone disagree ?) > In this case, the major version 4.x becomes useless. > If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better. > IMHO due to the similar reason, the Java version has been changed from 1.x > to java 1.7/1.8 (=java 7/8) then to java 11/14/17. > of course there will be some issues if semantic changes, I think it is > under control. > > > > Regarding the compatibility, I think we can change the APIs gradually. > I noticed the following recently when I tested VR upgrade to > debian12/python3 > > root@r-431-VM:~# python > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import cgi > :1: DeprecationWarning: 'cgi' is deprecated and slated for removal > in Python 3.13 > > For the API changes you mentioned, we could try the similar > - in version X, add new APIs, mark the old APIs as deprecated > - tell users the old APIs will be removed in version Y, please use new APIs > instead. > - in version Y, remove the old APIs. > > This can be done in each major/minor release. No need to wait for 5.0. > > > -Wei > > On Fri, 26 Jan 2024 at 18:51, Guto Veronezi wrote: > > > Exactly, so you understand now why we must discuss what we intend. > > Although, incompatibilities are needed sometimes so we can evolve, > > leaving old ways and deprecated technologies and techniques in the past. > > > > *The main point is: *we have to understand the technical reasons for the > > proposal and what we expect from it before deciding anything. > > > > Best regards, > > Daniel Salvador (gutoveronezi) > > > > > > -- Daan
Re: [VOTE] drop first version number and continue with semantic versioning
happy to discuss further (not agreeing at all with the arguments). This vote is closed without conclusion. On Thu, Jan 25, 2024 at 5:28 PM Rohit Yadav wrote: > > Agree with Daniel, I would prefer to discuss this further too. I think we're > moving too fast with the voting. > > > Regards. > > > > > > From: Guto Veronezi > Sent: Thursday, January 25, 2024 20:25 > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] drop first version number and continue with semantic > versioning > > Hello guys, > > I just replied the discussion thread and I would like to discuss it a > little bit further before voting. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 1/25/24 11:47, Daan Hoogland wrote: > > LS, > > > > As previously discussed [1] there is a growing wish to no longer carry > > the version number 4 in future versions. The proposal is to proceed as > > usual but just drop the first number. This means the next version will > > be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 > > > > +1 for agree > > 0 for no strong opinion or objects either way > > -1 for disagree (add your reason to be counted) > > > > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 > > -- Daan
[VOTE] drop first version number and continue with semantic versioning
LS, As previously discussed [1] there is a growing wish to no longer carry the version number 4 in future versions. The proposal is to proceed as usual but just drop the first number. This means the next version will be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 +1 for agree 0 for no strong opinion or objects either way -1 for disagree (add your reason to be counted) [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 -- Daan
Re: [PROPOSAL] version naming : drop the 4.
If I start a vote it will be to adjust to the semantic versioning system. I do not approve of the ubuntu scheme, sorry. I will probably -0 just to get us moving forward but I think it is not the best for us. So I'll wait a few and start a vote if no-one else did before me. On Wed, Jan 24, 2024 at 12:48 PM Wido den Hollander wrote: > > > > Op 24/01/2024 om 00:27 schreef Wei ZHOU: > > Yes, the ubuntu version naming is the best in my opinion. > > Other than the version naming, we need to decide the frequency of major > > releases and minor releases, which version will be LTS, how long the > > LTS/normal version will be supported, etc. > > > > Maybe a vote in the dev/users/pmc mailing list? > > > > I think that's a good decision. > > @ Daan: Do you want to start one? > > I'd prefer the .MM release schedule. We just need a good (blog)post > to explain the new versioning. > > Wido > > > > > > > 在 2024年1月23日星期二，Nicolas Vazquez 写道： > > > >> I like this idea as well, even if its .MM or YY.MM. > >> > >> Would we want to define delivery months for releases similar to Ubuntu .04 > >> and .10? > >> > >> Regards, > >> Nicolas Vazquez > >> > >> From: Nux > >> Sent: Tuesday, January 23, 2024 6:11 PM > >> To: dev@cloudstack.apache.org > >> Cc: Wei ZHOU > >> Subject: Re: [PROPOSAL] version naming : drop the 4. > >> > >> An interesting proposition, I like it. > >> It would also relieve us from having to come up with any over-the-top > >> feature or change for a major version change. > >> > >> On 2024-01-23 14:49, Wido den Hollander wrote: > >>> We could look at Ubuntu, and other projects, and call it 2025.01 if we > >>> release it in Jan 2025. > >>> > >>> A great post on the website, mailinglists and social media could > >>> explain the change in versioning, but that the code doesn't change that > >>> much. > >>> > >>> Project has matured, etc, etc. > >> > >> > >> > >> > > -- Daan
Re: [PROPOSAL] version naming : drop the 4.
personally I don't like the months too much. They tie us down to a release schedule that we have proven not to be able to maintain. a year as number restricts us to just one major release that year, i.e. only one moment for new integrations or major features. S I am for the more liberal 20.x and if we make a second one some year we can freely add a number. On Wed, Jan 24, 2024 at 12:27 AM Wei ZHOU wrote: > > Yes, the ubuntu version naming is the best in my opinion. > Other than the version naming, we need to decide the frequency of major > releases and minor releases, which version will be LTS, how long the > LTS/normal version will be supported, etc. > > Maybe a vote in the dev/users/pmc mailing list? > > > > 在 2024年1月23日星期二，Nicolas Vazquez 写道： > > > I like this idea as well, even if its .MM or YY.MM. > > > > Would we want to define delivery months for releases similar to Ubuntu .04 > > and .10? > > > > Regards, > > Nicolas Vazquez > > > > From: Nux > > Sent: Tuesday, January 23, 2024 6:11 PM > > To: dev@cloudstack.apache.org > > Cc: Wei ZHOU > > Subject: Re: [PROPOSAL] version naming : drop the 4. > > > > An interesting proposition, I like it. > > It would also relieve us from having to come up with any over-the-top > > feature or change for a major version change. > > > > On 2024-01-23 14:49, Wido den Hollander wrote: > > > We could look at Ubuntu, and other projects, and call it 2025.01 if we > > > release it in Jan 2025. > > > > > > A great post on the website, mailinglists and social media could > > > explain the change in versioning, but that the code doesn't change that > > > much. > > > > > > Project has matured, etc, etc. > > > > > > > > -- Daan
Re: [PROPOSAL] version naming : drop the 4.
João, I think we should not consider 5.0, but go to 20,0 that is more in line with what we've actually been doing (semantic versioning from the second digit) On Mon, Jan 22, 2024 at 11:53 AM Nux wrote: > > LGTM! > > On 2024-01-19 19:19, João Jandre Paraquetti wrote: > > Hi all, > > > > I agree that our current versioning schema doesn't make much sense, as > > "minors" introduce pretty big features; even backward incompatibilities > > are introduced in minor versions sometimes. > > > > As the current plan is to have 4.20 by June, I think we should stick to > > it and still have the next "minor", and make it the last minor version > > of the major 4. After so much time in the same major version, we should > > plan something relevant before changing it, and June 2024 is a bit of a > > tight schedule for that. > > > > I think that we should plan to move to version 5.0.0, we could set the > > release date to the end of 2024 or the start (January) of 2025; by > > doing that, we have plenty of time for planning and developing amazing > > features for version 5, while also preparing a cleanup of our current > > APIs. For instance, we are working on the following major developments: > > KVM differential snapshots/backups without needing extra software; > > theme management system (white label portal for ACS); native > > snapshot/backup for VMware (without needing Veeam) to make it similar > > to what ACS does with XenServer and KVM; Operators backup (which are > > different from end-user backups); and many other items. > > > > What do you guys think? > > > > Best regards, > > João Jandre. > > > > On 1/19/24 10:39, Daan Hoogland wrote: > >> devs, PMC, > >> > >> as we are closing in on 4.19 I want to propose that we drop the 4. in > >> our versioning scheme. We've been discussing 5 but no real initiatives > >> have been taken. Nowadays big features go into our "minor" > >> dot-releases. In my opinion this warrants promoting those version to > >> the status of major and dropping the 4.. > >> > >> technically this won't be an issue as 20 > 4 and out upgrade scheme > >> supports a step like that. > >> > >> any thoughts? > >> -- Daan
Re: new website design
As we get no major issues on it and we already voted to have this design applied, is it alright to deploy this in the coming weeks? On Wed, Jan 17, 2024 at 8:31 PM Daan Hoogland wrote: > > devs and users, > > back in august we had a small discussion about a new website design, > led by Ivet [1]. In the meanwhile Rohit had investigated using > docusaurus as a publishing mechanism for the site. After the last few > weeks I have been working on integrating the two. The result so far > can be viewed on the staging site [2] > > Please all have a look and give me any feedback you may have, so we > can move this forward. > > [1] https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso > [2] https://cloudstack.staged.apache.org/ > > -- > Daan -- Daan
Re: Apache CloudStack and Ceph Day - February 22, Amsterdam
I live in his backyard, will there as well. On Tue, Jan 9, 2024 at 3:58 PM Wido den Hollander wrote: > > > > Op 09/01/2024 om 13:45 schreef Ivet Petrova: > > Dear community members, > > > > We managed to finalised the date for our joint event with the Ceph > > community. > > I am happy to share that we are doing it on February 22nd, in Amsterdam, > > Netherlands. > > The event will be hosted by Adyen, the address is: Rokin 49, 1012 KK > > Amsterdam, The Netherlands > > > > Two things at this stage: > > > > 1. We still have a few speaking slots free (actually 2 slots only). If you > > are interested to present at the event, please submit your talk proposal > > now. > > https://forms.gle/TnBfxS2cKWfe28CS6 > > > > 2. We would be happy if we can see more people from the community, so > > register as an attendee here: > > https://www.eventbrite.nl/e/cloudstack-and-ceph-day-netherlands-2024-tickets-700177167757 > > > > Look forward to meeting you in Amsterdam! > > Yes! That's like my backyard. I'll be there! > > Wido > > > > > Best regards, > > > > > > > > > > -- Daan
[PROPOSAL] version naming : drop the 4.
devs, PMC, as we are closing in on 4.19 I want to propose that we drop the 4. in our versioning scheme. We've been discussing 5 but no real initiatives have been taken. Nowadays big features go into our "minor" dot-releases. In my opinion this warrants promoting those version to the status of major and dropping the 4.. technically this won't be an issue as 20 > 4 and out upgrade scheme supports a step like that. any thoughts? -- Daan
Re: [VOTE] Apache CloudStack 4.19.0.0 RC2
agreed, thanks Abhi
On Thu, Jan 18, 2024 at 1:07 PM Abhishek Kumar wrote:
>
> Hi all,
>
> Thanks you for your vote Nicolas and Daan.
> Thank you Wei for the tests. The reported issue will be a blocker for people
> installing and upgrading on Ubuntu hosts.
> We already have a fix and test results on the PR
> https://github.com/apache/cloudstack/pull/8524 look good.
>
> I'll work with contributors and cut a new RC with this fix.
>
> Regards,
> Abhishek
>
> On Wed, 17 Jan 2024 at 20:59, Wei ZHOU wrote:
>>
>> Hi Daan,
>>
>> multipath is not used in our environments at all.
>> The tests for PR https://github.com/apache/cloudstack/pull/8524 look ok
>> until now. Let's wait for the test results.
>>
>> -Wei
>>
>> On Wed, 17 Jan 2024 at 15:16, Daan Hoogland wrote:
>>
>> > Wei, is this with a VM/Volume not using multipath itself? If it is it
>> > is definitely a reason to create a new RC, if it isn't I think we can
>> > manage a known issue for a new feature.
>> >
>> > On Wed, Jan 17, 2024 at 2:50 PM Wei ZHOU wrote:
>> > >
>> > > Thanks Ahbishek, and everyone tested or is testing RC2.
>> > >
>> > > I ran some tests on a ubuntu22 environment , and got the following
>> > > exception when stopping VMs.
>> > >
>> > > 2024-01-17 12:56:26,053 DEBUG [c.c.a.t.Request]
>> > > (AgentManager-Handler-17:null) (logid:) Seq 2-8295911988593164342:
>> > > Processing: { Ans: , MgmtId: 32989056598488, via: 2, Ver: v1, Flags: 10,
>> > >
>> > [{"com.cloud.agent.api.Answer":{"result":"false","details":"java.lang.NullPointerException
>> > > at com.cloud.utils.script.Script.getExitValue(Script.java:74)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.storage.MultipathSCSIAdapterBase.runScript(MultipathSCSIAdapterBase.java:476)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.storage.MultipathSCSIAdapterBase.disconnectPhysicalDiskByPath(MultipathSCSIAdapterBase.java:226)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.disconnectPhysicalDiskByPath(KVMStoragePoolManager.java:205)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.cleanupDisk(LibvirtComputingResource.java:3335)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStopCommandWrapper.execute(LibvirtStopCommandWrapper.java:101)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStopCommandWrapper.execute(LibvirtStopCommandWrapper.java:49)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtRequestWrapper.execute(LibvirtRequestWrapper.java:78)
>> > > at
>> > >
>> > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1903)
>> > >
>> > > The workaround is
>> > > chmod +x /usr/share/cloudstack-common/scripts/storage/multipath/*.sh
>> > > The PR to fix it : https://github.com/apache/cloudstack/pull/8524
>> > >
>> > >
>> > > Please note, this is not a -1 on the RC2. If we think this is not a
>> > > critical issue, we need to update the upgrade instruction for it.
>> > >
>> > >
>> > > -Wei
>> > >
>> > > On Mon, 15 Jan 2024 at 13:04, Abhishek Kumar
>> > wrote:
>> > >
>> > > > Hi All,
>> > > >
>> > > > I've created a 4.19.0.0 release (RC2), with the following artifacts up
>> > for
>> > > > a vote:
>> > > >
>> > > > Git Branch and Commit SH:
>> > > > https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240115T1418
>> > > > Commit: 38bd4fd72bdae354c4b0f615a4861fc84d67b29a
>> > > >
>> > > > Source release (checksums and signatures are available at the same
>> > > > location):
>> > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/
>> > > >
>> > > > PGP release keys (signed using
>> > 65518106473A09D7AF26B384A70BD2EAA74E2866):
>> > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>> > > >
>> > > > For testing purposes, I have uploaded the different distro packages to:
>> > > > http://download.cloudstack.org/testing/4.19.0.0-RC2/
>> > > >
>> > > > Since 4.16 the system VM template registration is no longer mandatory
>> > > > before upgrading, however, it can be downloaded from here if needed:
>> > > > https://download.cloudstack.org/systemvm/4.19/
>> > > >
>> > > > The vote will be open for 72 hours.
>> > > >
>> > > > 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)
>> > > >
>> > > > Regards,
>> > > > Abhishek
>> > > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
--
Daan
new website design
devs and users, back in august we had a small discussion about a new website design, led by Ivet [1]. In the meanwhile Rohit had investigated using docusaurus as a publishing mechanism for the site. After the last few weeks I have been working on integrating the two. The result so far can be viewed on the staging site [2] Please all have a look and give me any feedback you may have, so we can move this forward. [1] https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso [2] https://cloudstack.staged.apache.org/ -- Daan
Re: [VOTE] Apache CloudStack 4.19.0.0 RC2
Wei, is this with a VM/Volume not using multipath itself? If it is it
is definitely a reason to create a new RC, if it isn't I think we can
manage a known issue for a new feature.
On Wed, Jan 17, 2024 at 2:50 PM Wei ZHOU wrote:
>
> Thanks Ahbishek, and everyone tested or is testing RC2.
>
> I ran some tests on a ubuntu22 environment , and got the following
> exception when stopping VMs.
>
> 2024-01-17 12:56:26,053 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-17:null) (logid:) Seq 2-8295911988593164342:
> Processing: { Ans: , MgmtId: 32989056598488, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":"false","details":"java.lang.NullPointerException
> at com.cloud.utils.script.Script.getExitValue(Script.java:74)
> at
> com.cloud.hypervisor.kvm.storage.MultipathSCSIAdapterBase.runScript(MultipathSCSIAdapterBase.java:476)
> at
> com.cloud.hypervisor.kvm.storage.MultipathSCSIAdapterBase.disconnectPhysicalDiskByPath(MultipathSCSIAdapterBase.java:226)
> at
> com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.disconnectPhysicalDiskByPath(KVMStoragePoolManager.java:205)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.cleanupDisk(LibvirtComputingResource.java:3335)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStopCommandWrapper.execute(LibvirtStopCommandWrapper.java:101)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStopCommandWrapper.execute(LibvirtStopCommandWrapper.java:49)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtRequestWrapper.execute(LibvirtRequestWrapper.java:78)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1903)
>
> The workaround is
> chmod +x /usr/share/cloudstack-common/scripts/storage/multipath/*.sh
> The PR to fix it : https://github.com/apache/cloudstack/pull/8524
>
>
> Please note, this is not a -1 on the RC2. If we think this is not a
> critical issue, we need to update the upgrade instruction for it.
>
>
> -Wei
>
> On Mon, 15 Jan 2024 at 13:04, Abhishek Kumar wrote:
>
> > Hi All,
> >
> > I've created a 4.19.0.0 release (RC2), with the following artifacts up for
> > a vote:
> >
> > Git Branch and Commit SH:
> > https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240115T1418
> > Commit: 38bd4fd72bdae354c4b0f615a4861fc84d67b29a
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/
> >
> > PGP release keys (signed using 65518106473A09D7AF26B384A70BD2EAA74E2866):
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> > For testing purposes, I have uploaded the different distro packages to:
> > http://download.cloudstack.org/testing/4.19.0.0-RC2/
> >
> > Since 4.16 the system VM template registration is no longer mandatory
> > before upgrading, however, it can be downloaded from here if needed:
> > https://download.cloudstack.org/systemvm/4.19/
> >
> > The vote will be open for 72 hours.
> >
> > 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)
> >
> > Regards,
> > Abhishek
> >
--
Daan
Re: [VOTE] Apache CloudStack 4.19.0.0 RC2
+1 (binding) both signatures checked, otherwise as I was heavily involved I am trusting in all testing done along the way. On Mon, Jan 15, 2024 at 1:04 PM Abhishek Kumar wrote: > > Hi All, > > I've created a 4.19.0.0 release (RC2), with the following artifacts up for > a vote: > > Git Branch and Commit SH: > https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240115T1418 > Commit: 38bd4fd72bdae354c4b0f615a4861fc84d67b29a > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/ > > PGP release keys (signed using 65518106473A09D7AF26B384A70BD2EAA74E2866): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > For testing purposes, I have uploaded the different distro packages to: > http://download.cloudstack.org/testing/4.19.0.0-RC2/ > > Since 4.16 the system VM template registration is no longer mandatory > before upgrading, however, it can be downloaded from here if needed: > https://download.cloudstack.org/systemvm/4.19/ > > The vote will be open for 72 hours. > > 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) > > Regards, > Abhishek -- Daan
new PMC member Harikrishna Patnala
users and dev, The PMC have invited Harikrishna to join their ranks and he has gracefully accepted. Please join me in congratulating Hari. -- Daan
new committer: João Jandre Paraquetti
community, The PMC have invited João Jandre Paraquetti to join the project as a committer and the invitation was gratefully accepted. Please join me in welcoming João. Congratulations João, -- Daan
new committer Vladimir Petrov
community, The PMC has decided Vladi to become a committer and he has gracefully accepted. Please join me in welcoming Vladi to the project as committer. Congratulations Vladi -- Daan
Re: [PROPOSE] ACS 4.18.2.0
+1 i like your proposal and support you João, Let us know what you need. On Sat, Dec 9, 2023 at 9:23 PM Rohit Yadav wrote: > > +1 > > Given, 4.18 branch is benefitting from maintenance work already, I wouldn't > mind if you want to push it earlier to even say end of Jan, and target > release in Feb 2024. > > > Regards. > > > From: João Jandre Paraquetti > Sent: Friday, December 8, 2023 23:32 > To: dev@cloudstack.apache.org > Subject: [PROPOSE] ACS 4.18.2.0 > > Hi all, > > As suggested on the 4.20.0.0 discussion thread (see > https://lists.apache.org/thread/nyoddmwydz2t59hsfs7gf0vozlf7n434), I'd > like to propose the release of version 4.18.2.0 with myself as the RM, > here's a rough timeline: > > - From now till the second week of February (2 months): accept bug > fixes and minor improvements > - Third week of February: accept only blocker and critical bug fixes, > aiming to stabilize the branch. > - End of February: start cutting RCs, vote and finish release work. > > We currently have 7 open PRs [1] and 51 open issues [2] with 4.18.2.0 as > milestone, I believe the above timeline should give enough time to solve > all concerns. In case anyone wants to include a bug fix or a pull > request in 4.18.2.0 milestone, please mention me (JoaoJandre) on github. > > If anyone has any suggestions, please voice them. > > [1]: > https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.18.2.0+is%3Aopen > [2]: > https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.18.2.0 > > Best regards, > João Jandre > > > > -- Daan
Re: [DISCUSS] log guidelines
Thanks João, On Tue, Dec 5, 2023 at 8:21 PM João Jandre Paraquetti wrote: ... > However, when the error happens because of system degradation, there are > times when having a stacktrace can save hours of debugging, as the error > might be hard to reproduce. Also, if the error is occurring in a > production environment, changing the log level to debug means restarting > ACS's components, possibly leading to downtime and/or more errors. The > second issue will be solved with the log4j2 PR, but the first one can > still be a pain. The second issue is already implemented in the current system (though tuning to a higher level does not work as flawlessly as as going to debug or trace) The problem I have with the second reason is that if it occurs it will occur a lot usually. A compromise could be adding a second error log to be used for those stacktraces. What do you think? Also, How would you word it instead, João? > On 12/4/23 10:51, Daan Hoogland wrote: ... > > Fatal: > > - include a reason why the system can not function anymore, > > - be followed by a System.exit() call, > > - include a stack trace if it is reasonable to expect this would give > > properly helpful information. > > I did a quick search and we have 2 fatal calls in the system. Neither > > is followed by a System.exit() and I think they can be replaced by > > error()/debug() combinations > > > > Error: > > - include a reason why the system can not execute a user request or > > why part of the system is degraded. > > - should *not* include a stack trace > > > > Warn: > > - include a reason why the system might not behave as the user is > > expecting. (configuration or integration missing for example,) > > - should *not* include a stack trace > > > > Info: > > - is for informationals to the operator like resource lifecycle > > messages or deployment planning considderations > > - should *not* include a stack trace > > > > Debug: > > - information to be turned on when trouble shooting or developing. > > This information should not be needed for normal operation > > - if a thrown exception is caught and not rethrown, the stack trace of > > such exception > > > > Trace: > > - whatever you feel helps you during development of a > > feature/enhancement/fix/improvement that is not needed in any kind of > > operational way. -- Daan
4.20 plans
devs, Other than we all have great new plans for integrations and other features for 4.20 and we have about 300 issues to solve, There are some platform issues that need addressing. So far I can think of - the outstanding logging PR - java 11 is out of support and we'll need to support a higher version I think we must address these as soon as we have a release. Are there any other issues to address? -- Daan
[DISCUSS] log guidelines
There have been some discussions on github PRs about the subject of proper logging and I want to use this to start a discussion and come to some guidelines that hopefully everybody can agree to. My idea is the following Fatal: - include a reason why the system can not function anymore, - be followed by a System.exit() call, - include a stack trace if it is reasonable to expect this would give properly helpful information. I did a quick search and we have 2 fatal calls in the system. Neither is followed by a System.exit() and I think they can be replaced by error()/debug() combinations Error: - include a reason why the system can not execute a user request or why part of the system is degraded. - should *not* include a stack trace Warn: - include a reason why the system might not behave as the user is expecting. (configuration or integration missing for example,) - should *not* include a stack trace Info: - is for informationals to the operator like resource lifecycle messages or deployment planning considderations - should *not* include a stack trace Debug: - information to be turned on when trouble shooting or developing. This information should not be needed for normal operation - if a thrown exception is caught and not rethrown, the stack trace of such exception Trace: - whatever you feel helps you during development of a feature/enhancement/fix/improvement that is not needed in any kind of operational way. As I think the two fatal()s we have are not genuine, I think stack traces are only for Debug and Trace level, where Debug can be temporarily turned on in production and Trace is fro developers exclusively, I realise the current state of the system is far from this behaviour, but i like to think we can grow in the direction as I describe and I hope we can refine this to a generic guideline to be used in reviews. -- Daan
new committer Bryan Lima
All, The Project Management Committee (PMC) for Apache CloudStack has invited Bryan Lima to become a PMC member and we are pleased to announce that they have accepted. Bryan has contributed himself and assisted in reviewing and testing the work of others. He has shown to be responsive, constructive and pleasant to work with. please join me in congratulating Bryan -- Daan
Re: [DISCUSS] Adopting Github Discusssions Users Forum
great On Tue, Nov 28, 2023 at 10:30 AM Rohit Yadav wrote: > > All, > > It's been a while since I had last proposed adopting and trying the Github > Discussions feature for our users community. Since then, the ASF infra seems > to have enabled integration and allowing Discussions integrated with mailing > lists: https://github.com/search?q=.asf.yaml+discussions=code > > Following discussions with both technical and non-technical users from the > CCC, I believe we should try this out and use it for users to discuss their > ideas, questions, and problems, all that traditionally has happened on the > users@ ML; while been integrating such discussions on the users@ ML. The > Discussions platform could be used by developers too to get feedback from > users. > > That said, we MUST continue to use our mailing lists for any project > governance related matters such as releases related discussions, releases > voting, and any form of consensus and decision making. > > I've proposed a PR for this here where the discussions feature is tied to > users@ ML: > https://github.com/apache/cloudstack/pull/8274/files > > Thoughts and feedback? > > > Regards. > > > -- Daan
new PMC member: Abhishek Kumar
The Project Management Committee (PMC) for Apache CloudStack has invited Abhishek Kumar to become a PMC member and we are pleased to announce that they have accepted. Abhishek has contributed in the past and has shown effort to make the project run smoothly. He is also the Release Manager for the upcoming 4.19 release. please join me in congratulating Abhishek -- Daan
Re: [PROPOSE] ACS 4.19.0.0 release
After consulting with Abhishek I have started to move PRs and issues out of the 4.19 and 4.18.2 milestones. I think we are not going to make the dates mentioned anyway but want to reduce the delay as much as possible. Please be responsive on your PRs and issues if you want them in, I will not touch the milestones of any item that has had activity in the last week. hope you all forgive me one day, On Thu, Oct 26, 2023 at 12:50 PM Abhishek Kumar < abhishek.ku...@shapeblue.com> wrote: > Hi all, > > Update on the current state of the 4.19.0.0 milestone. Currently, there > are still 179 open items in the 4.19.0.0 milestone [1]. We still have many > exciting new features which need some work in the form code-changes or > review and testing. > Also, there are some issues and PRs in 4.18.2.0 milestone [2] which are > marked major in severity. > Based on this I would like to propose moving the earlier suggested > timeline further and the revised timeline can be, > > - Announce code freeze around mid of the next month, November 2023 > - RC1 can be expected thereafter in the second half of November 2023 > > If you have got an active PR with a new feature or fix that you would like > to see in 4.19.0.0 release please comment with your interest on the Github > item. > > Regards, > Abhishek > > [1] https://github.com/apache/cloudstack/milestone/24 > [2] https://github.com/apache/cloudstack/milestone/29 > > From: Abhishek Kumar > Sent: 11 October 2023 12:49 > To: dev@cloudstack.apache.org ; > us...@cloudstack.apache.org > Subject: Re: [PROPOSE] ACS 4.19.0.0 release > > Hi all, > > Update on the current state of the 4.19.0.0 milestone. Currently, there > are around 189 open items in the 4.19.0.0 milestone with 73 open PRs and > 116 open issues. > Also, there are some issues and PRs in 4.18.2.0 milestone which are marked > major in severity. > Considering these and the fact that there are some interesting new > features in the milestone that still need some changes, review, or testing > we may see some deviation in the earlier suggested timeline. > > * Code freeze can be expected towards the end of the month, October > 2023 > * RC1 can be expected thereafter in the month of November 2023 > > Also, if you have got an active PR with a new feature or fix that you > would like to see in 4.19.0.0 release please comment with your interest on > the Github item. > > Regards, > Abhishek > > > > From: Daan Hoogland > Sent: 29 September 2023 15:22 > To: dev@cloudstack.apache.org > Cc: us...@cloudstack.apache.org > Subject: Re: [PROPOSE] ACS 4.19.0.0 release > > Please note that these figures are not including any issues or PRs marked > for 4.18.2. We have a lot to filter out. > > On Fri, Sep 29, 2023 at 11:33 AM Abhishek Kumar < > abhishek.ku...@shapeblue.com> wrote: > > > Hi all, > > > > Update on the current state of the 4.19.0.0 milestone. Currently, there > > are 203 open items in the 4.19.0.0 milestone with 72 open PRs and 131 > open > > issues. > > Considering the earlier suggested timeline, from next week, we will have > > to triage the open items more diligently to move the inactive items out > of > > the milestone. > > The release timeline remains the same: > > > > * Code freeze, and stabilization to accept only critical/blocker > > issues in the second half of October 2023. We should be in a better > > position to have a specific date in a week or so. > > * Cut 4.19.0.0 RC1 towards the end of October 2023. > > > > Looking forward to your support. > > > > Regards, > > Abhishek > > > > > > From: Abhishek Kumar > > Sent: 17 August 2023 22:47 > > To: dev@cloudstack.apache.org ; > > us...@cloudstack.apache.org > > Subject: [PROPOSE] ACS 4.19.0.0 release > > > > Hi, > > > > Thanks all for your support on my 4.19 RM proposal thread! > > > > I propose the following timeline for the 4.19.0.0 release. Keep in mind > > 4.18.1.0 release work is also currently in progress and is being managed > by > > Wei. > > > > - (8 plus weeks) Ongoing – Mid-October 2023: Accept all bugs, issues, > > improvements allowed in LTS [1] > > - (1 week) Stabilise the main (or 4.19) branch, accept only > > critical/blocker issues (if any) > > - End October 2023 and onwards: Cut 4.19.0.0 RC1 and further RCs if > > necessary, start/conclude vote, and finish release work > > > > I hope to get support from all active contributors during the process of > >
Re: [DISCUSS] New benchmarking tool
thanks Rohit, It is a great idea. I have some questions concerning "measuring is influencing" and "prerequisites", but those should not stop us from creating a repo for this in the project great idea, On Thu, Nov 2, 2023 at 9:58 AM Nux wrote: > Great idea, looking forward to it. > > > On 2023-11-01 16:34, Rohit Yadav wrote: > > All, > > > > I want to kickstart a discussion of developing a new tool - csbench, > > that can help with generating resource load and measuring the > > performance and efficiency of Apache CloudStack APIs. > > > > Much like cmk, this tool can be written in Go and can be useful for > > anybody to benchmark CloudStack API performance. It's still in a > > nascent stage and can benefit from feedback and input from the wider > > community early in the development process. > > > > If there are no objections, I propose to create a cloudstack-csbench > > repo in which this tool can be developed. Thoughts and feedback? > > Thanks. > > > > > > Regards. > -- Daan
4.19 work
Devs, Please keep an eye on the PRs you want merged for 4.19 on a daily basis. As we get closer and more gets merge the integration work get more continuous (pun intended :P ). There are a lot of conflicts to be handled by authors at the moment. regards,
Re: Gentle reminder for getting your PRs/issues in 4.19.0.0
thanks Abhishek, Also devs, please be aware that conflict/rebase cycles will have to intensify a bit in the coming weeks. Please be vigilant. regards, On Thu, Oct 12, 2023 at 12:43 PM Abhishek Kumar < abhishek.ku...@shapeblue.com> wrote: > Hi devs, > > I'm sending this to remind you that we are approaching code freeze as per > our 4.19.0.0 release timeline that is shared in the other email [1] to dev@ > and user@, can you please mark your interest in the PRs and > major/critical/blocker issues that you feel should be considered for the > release. > Though we aspire to get as many fixes and interesting new features from > the milestone [2], all of the current items may not be able to make it into > the release with limited time, review and testing. > Looking forward to your support. > > > Regards, > Abhishek > > [1] https://lists.apache.org/thread/ymqtk7y7623fvnm7bxntk36rdjn1q03k > [2] https://github.com/apache/cloudstack/milestone/24 > > > > -- Daan
Re: [DISCUSS] Block importing VMs without NIC
Henrique, Thanks for bringing this up/ I think both disallowing and creating a default nic on importing are acceptable behaviours. One could argue for either and operators will complain either way (I know I probably would ;). I think we can make disallowing the default and if we want to make this luxurious we can implement a setting that creates a default NIC if one is missing. €0,02 On Mon, Oct 2, 2023 at 8:30 AM Henrique Sato wrote: > Hello guys, > > As mentioned in PR #7859 [1], I'm opening this thread so we can discuss > whether ACS should allow importing VMs without NIC. > > Currently, ACS allows importing VMs without a NIC. However, when creating > new NICs for these VMs, it will not be possible to set them as default. > When using a VM without a default NIC, the gateway is not configured and > without a gateway the VM will not have external connection, which limits > the user to the local network. Although PR #7859 [1] solves this situation, > I do not think ACS should allow this kind of situation. In my opinion, this > behavior should be removed, as ACS does not allow creating VMs without NIC > nor removing the default NIC. > > What do you guys think about this scenario? Do you have other > perspectives/opinions on this matter? > > Best regards, > Henrique Sato (hsato03) > > [1] https://github.com/apache/cloudstack/pull/7859 > -- Daan
Re: [PROPOSE] ACS 4.19.0.0 release
Please note that these figures are not including any issues or PRs marked for 4.18.2. We have a lot to filter out. On Fri, Sep 29, 2023 at 11:33 AM Abhishek Kumar < abhishek.ku...@shapeblue.com> wrote: > Hi all, > > Update on the current state of the 4.19.0.0 milestone. Currently, there > are 203 open items in the 4.19.0.0 milestone with 72 open PRs and 131 open > issues. > Considering the earlier suggested timeline, from next week, we will have > to triage the open items more diligently to move the inactive items out of > the milestone. > The release timeline remains the same: > > * Code freeze, and stabilization to accept only critical/blocker > issues in the second half of October 2023. We should be in a better > position to have a specific date in a week or so. > * Cut 4.19.0.0 RC1 towards the end of October 2023. > > Looking forward to your support. > > Regards, > Abhishek > > > From: Abhishek Kumar > Sent: 17 August 2023 22:47 > To: dev@cloudstack.apache.org ; > us...@cloudstack.apache.org > Subject: [PROPOSE] ACS 4.19.0.0 release > > Hi, > > Thanks all for your support on my 4.19 RM proposal thread! > > I propose the following timeline for the 4.19.0.0 release. Keep in mind > 4.18.1.0 release work is also currently in progress and is being managed by > Wei. > > - (8 plus weeks) Ongoing – Mid-October 2023: Accept all bugs, issues, > improvements allowed in LTS [1] > - (1 week) Stabilise the main (or 4.19) branch, accept only > critical/blocker issues (if any) > - End October 2023 and onwards: Cut 4.19.0.0 RC1 and further RCs if > necessary, start/conclude vote, and finish release work > > I hope to get support from all active contributors during the process of > reviewing/testing/merging the PRs. You can find the open issues and PRs at > the 4.19.0.0 Github milestone [2]. Ping me (@shwstppr) or Daan > (@DaanHoogland) on your issues and PRs, that are to be included in 4.19.0.0. > > Looking forward to your support on bug fixes, reviews, tests, etc. I'm > happy to collaborate with others on the release management. Thanks. > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS > [2] https://github.com/apache/cloudstack/milestone/24 > > > Regards, > Abhishek > > > > > > > > -- Daan
Re: [DISCUSS] Upgrading Mockito & phasing out powermock
great, thanks you for your persistence and effort in general. On Tue, Sep 26, 2023 at 1:51 PM Vishesh Jindal wrote: > Hi all, > > I wanted to update everyone that powermock is completely removed from main > branch now. Thank you everyone for helping out on this. > > Regards, > Vishesh > > > From: Kishan Kavala > Sent: Friday, June 9, 2023 1:30 PM > To: dev@cloudstack.apache.org > Subject: RE: [DISCUSS] Upgrading Mockito & phasing out powermock > > +1 > Agree with the approach, Vishesh. > > > > > > > > -Original Message- > From: Wei ZHOU > Sent: Tuesday, June 6, 2023 8:11 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock > > lgtm. go ahead Vishesh. > > -Wei > > > On Tue, 6 Jun 2023 at 14:17, Vishesh Jindal > wrote: > > > Hi all, > > > > I am working on upgrading Mockito's version & phasing out powermock. > > For new maven modules, I would request all to use Mockito's mockStatic > > instead of Powermock. > > > > Why? > > Powermock's last release was on Nov 2, 2020. The project seems to have > > been abandoned. Powermock has compatibility issues with Mockito's > > latest version as well. > > > > How? > > The only usage for PowerMock I could see in code was for mocking > > static methods. Since Mockito v3.4.0, it has the capability to mock > static methods. > > I plan to migrate tests to Mockito's mockStatic instead of PowerMock. > > This will have to be done module by module and will take some time. > > > > I have prepared a PR here: > > https://github.com/apache/cloudstack/pull/7577 > > > > This PR upgrades mockito from v3.2.4 to v3.12.4 and removes the usage > > of PowerMock from utils module. > > > > > > Let me know if you have any questions/concerns. > > > > Regards, > > Vishesh > > > > > > > > > > > -- Daan
Re: Migrating VMs from a cluster CS 4.17.2
Oliver, you can snapshot the VMs and convert to template (if all else fails). It might be worth trying to find out why it fails though (capacity, cpu level, network/storage configuration?) On Mon, Sep 11, 2023 at 6:06 PM Olivier GUIN wrote: > Hello everyone, > > I have 2 clusters each with XCP-NG 7.6 servers: > > 4 x IBM servers and 3 x DELL servers. > Each a primary storage. > I was able to migrate VMs from IBM to DELL but not the other way around! > > VM: GF-CLUSTER-01-XCP-IBM -> GF-CLUSTER-01-XCP-DELL OK > VM: GF-CLUSTER-01-XCP-DELL -> GF-CLUSTER-01-XCP-IBM NOK > > Would there be a procedure to migrate the VMs? Shut down the VM, migrate > the volume, delete the virtual router etc...? > > Best regards, > -- > > > *Olivier GUIN* > *Direction* > Tel. : 05 94 31 02 44 > Fax : 09 76 41 08 39 > Mail : olivier.g...@ariasnet.com > Site : www.ariasnet.com > -- Daan
Re: [DISCUSS] Fixing npm version for building UI
Hey Rohit, guess this is not a hot topic, but i'm +1 on this. with 4.18 out I think now is a good time. On Thu, Aug 10, 2023 at 10:53 AM Rohit Yadav wrote: > All, > > Our UI building in packages/PRs uses npm v14, while the current LTS > version is v18. However, since we use npm for only development and building > the UI statically there are hopefully no concerns around security and > support. > > I've been using both v14 and v16 to build UI across different branches > that haven't EOL'd. With npm v16 and ACS 4.18, I'm not able to npm install > and npm run serve without the following: > > export NODE_OPTIONS=--openssl-legacy-provider > > > npm also is trying to change the package-lock file with a new format, > considering this should we consider moving to support the latest LTS (v18) > or switch to another UI pkg building tool (such as yarn)? Thoughts? > > > Regards. > > > > -- Daan
new PMC member: Daniel Salvador
The Project Management Committee (PMC) for Apache [PROJECT] has invited Daniel Salvador to become a PMC member and we are pleased to announce that they have accepted. Daniel has contributed in the past and has shown effort to make the project run smoothly please join me in congratulating Daniel
new committer: Sina Kashipazha
The Project Management Committee (PMC) for Apache [PROJECT] has invited Sina Kashipazha to become a committer and we are pleased to announce that they have accepted. Sina has been active as a contributor in several ways; code, testing, talks, documentation Please join me in welcoming Sina
new committer: John Bampton
The Project Management Committee (PMC) for Apache CloudStack has invited Jown Bampton to become a committer and we are pleased to announce that they have accepted. John is mostly active on CI and build specific issues. please join me in welcoming John to the project -- Daan
Re: [DISCUSS] Simplifying constructs and UX
Rohit, I either agree or have no strong opinion on points 2 through 6, but I do not think point 1 is a good idea. Users in some cases rely heavily on projects and/or sharing domains and accounts. The two constructs both have earned their right to existence in production environments. €0,02 On Mon, Aug 14, 2023 at 10:48 AM Kiran Chavala wrote: > Hi Rohit > > Good Ideas !, Please find my feedback inline > > > 1. Does it make sense to simply the Default View as a Project which > cannot be deleted and primary space for the Account. Essentially, the > default view is the logged in account/user's project with no other > collaborators > > Kiran> I prefer to keep the Default view as there should be some > differentiation > > Projects is a feature (like grouping) through which a user can organize > his resources in Cloudstack. > > Other public cloud providers uses the concept of resource groups to > organize a account resources > > May be it could be useful is future as more integrations are added to > Cloudstack > > 2. Migrate all isolated network constructs as VPC with a single tier. > > Kiran> +1 for this > > All other public cloud providers by default deploy a vpc network along > with the vm deployment > > Do you mean by default Cloudstack, should create a vpc network , instead > of isolated network ? > > Currently isolated network is created by default during vm creation > > > 3. Simplify templates/isos that are listed in deploy VM form: as a user, > the template/iso section of the deploy VM form is complicated, would it > make sense to simplify the template/iso shown as groups of guest OS family > (like several other portals) and templates uploaded/registered by the > account separately. > > Kiran> +1 for this > > Also I believe the community and shared filter can be merged into one as > it simplifies > > 4. Remove data disk from VM deploy form, or hide it by default (show a > button - add volume): > Currently, the deploy VM form only supports one data disk, however API can > multiple disks. One can always still use APIs, but deploy VM and later > attach more disks; or deploy vm but not start it, attach as many data disks > as we want and then start it. > > Kiran> I believe the data disk should be present in the vm deploy form, as > the user should have the option to select large disk for his use case > > Also when deploying a vm from ISO, a data disk offering is a mandatory > feild > > > 5. Show user-data and affinity (placement) groups as a first-class step, > not hidden under advanced menu. > > Kiran> +1, as user-data(cloud-init) is widely used in automation as it > helps in bringing up the vm with the required configuration > > +1 also for shifting the affinity groups from advanced menu > > 6. Offering groups or bundles: introduce way to group/bundle compute/data > offerings; for example, I want to see CPU optimised offerings, memory > optimiised offerings, specialised offerings (say GPU) etc. > > Kiran> +1, for this > > Regards > Kiran > > From: Rohit Yadav > Date: Friday, 11 August 2023 at 9:44 PM > To: dev@cloudstack.apache.org > Cc: us...@cloudstack.apache.org > Subject: [DISCUSS] Simplifying constructs and UX > All, > > Request for comments on following ideas, largely in the UI: > > 1. Does it make sense to simply the Default View as a Project which > cannot be deleted and primary space for the Account. Essentially, the > default view is the logged in account/user's project with no other > collaborators > > 2. Migrate all isolated network constructs as VPC with a single tier. > > 3. Simplify templates/isos that are listed in deploy VM form: as a > user, the template/iso section of the deploy VM form is complicated, would > it make sense to simplify the template/iso shown as groups of guest OS > family (like several other portals) and templates uploaded/registered by > the account separately. > > 4. Remove data disk from VM deploy form, or hide it by default (show a > button - add volume): > Currently, the deploy VM form only supports one data disk, however API can > multiple disks. One can always still use APIs, but deploy VM and later > attach more disks; or deploy vm but not start it, attach as many data disks > as we want and then start it. > > 5. Show user-data and affinity (placement) groups as a first-class > step, not hidden under advanced menu. > > 6. Offering groups or bundles: introduce way to group/bundle > compute/data offerings; for example, I want to see CPU optimised offerings, > memory optimiised offerings, specialised offerings (say GPU) etc. > > > Regards. > > > > > > -- Daan
Re: [DISCUS][PROPOSAL] enable Update Branch on github
FYI, I created https://issues.apache.org/jira/browse/INFRA-24823 On Fri, Jul 21, 2023 at 8:48 AM Vishesh Jindal wrote: > +1 > If possible, please include "Update with Rebase" option as well. > > Thanks, > Vishesh > > ____ > From: Daan Hoogland > Sent: Wednesday, July 19, 2023 4:32 PM > To: dev > Subject: [DISCUS][PROPOSAL] enable Update Branch on github > > LS, > > In guthub there is a feature that allows you to update your branch with > the target branch [1] . As for for instance for lint checking and out of > security concerns we don't run github actions by default on the target > branch, it is a convenience to regularly update PRs with the target with > this simple functionality. > > So my proposal is to ask infra to enable this: > [image.png] > [1] > https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/ > > any objections or concerns anyone can think of? > > -- > Daan > > > > -- Daan
[DISCUS][PROPOSAL] enable Update Branch on github
LS, In guthub there is a feature that allows you to update your branch with the target branch [1] . As for for instance for lint checking and out of security concerns we don't run github actions by default on the target branch, it is a convenience to regularly update PRs with the target with this simple functionality. So my proposal is to ask infra to enable this: [image: image.png] [1] https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/ any objections or concerns anyone can think of? -- Daan
Re: Reminder on triaging role to access and use Github better
@Rohit Yadav is this worth mentioning on the website somewhere? On Tue, May 9, 2023 at 8:33 PM Rohit Yadav wrote: > All, > > Reminder - we've ability to add frequent contributors and add them as > collaborators [1] to our Github repos. This allows them to use project > Github with ability to report issue with tags, and be assigned to issues > and PRs. This is done via project repo specific .asf.yaml file. > > If you're a frequent contributor(s) and want to be able to add tags and be > assigned on issues and PRs, you may share your github users ID or raise a > Github issue. Thanks. > > [1] > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub > > > Regards. > > > > -- Daan
Re: [proposal] Consistency of naming in Cloudstack
Giles, just about point one as the others follow from it. On Fri, Jun 9, 2023 at 10:17 AM Giles Sirett wrote: > > Hi Daan - thanks for your input. Some comments inline below > > > > Kind Regards > Giles > > > > > -----Original Message- > From: Daan Hoogland > Sent: Thursday, June 8, 2023 4:17 PM > To: dev@cloudstack.apache.org > Subject: Re: [proposal] Consistency of naming in Cloudstack > > Giles, the principle of what you are saying seems good but I have a few > remarks; 1. Consistency should not become a goal. Clarity is and if context > might give rise to a different understanding of the same work consistency is > detrimental to understanding > > >> I *think* I understand your point, but I see high correlation between > >> consistency of naming and clarity. Surely, using different names (or > >> metaphors!) for the same object type inherently reduces clarity?. Could > >> you give an example of where using different names for one cloudstack > >> object type could increase clarity ? When under "compute", there is the occurrence of "instance", this is not accurate. It is not a "compute instance". Would this item occur under "Virtual Machines" there would not be an issue. I am sure we can find many instances for the use of "instance" that would not refer to a VM instance. (that sentence was not more than a happy incident!) So far the only good argument I read about using "instance" is the fact that iot has already been used a lot. which is "kind of" weak. As far as I can see the industry is already doing damage control, specifying other uses of instance further to avoid cognitive clashes. > €0.02 > > [1] > https://medium.com/swlh/the-importance-of-metaphors-in-programming-philosophy-and-trading-a0030ed176b6 > [2] http://www.extremeprogramming.org/rules/metaphor.html > > On Thu, Jun 8, 2023 at 4:47 PM Giles Sirett > wrote: > > > > Background > > Recently, I have been looking at a number of issues relating to the > > "first use" / "first impression" use of cloudstack. What to people > > think of Cloudstack as a new user? What is peoples perception of > > Cloudstack as a new user ? How easy is it for people to understand > > cloudstack & its concepts and to get help > > > > > > One thing I have seen is that CloudStack is inconsistent with what we call > > VM's/Instances: > > > > > > * In the UI main menu, we say Instances. We then have a very large > > "Create instance" button. All lifecycle operations are then "Foo Instance" > > * In various other places in the UI (many text messages, error > > messages, column headers, for example) we say "VM" > > * The API uses Instance, VM and Virtual Machine > > * The documentation, again, uses all 3 terms > > > > Now - I know everybody on this list (myself included for the last 10 > > years) has always used these terms interchangeably - we all KNOW that > > these are the same things. However, I think it could cause confusion > > to people seeing Cloudstack for the first time and create negative > > impressions. Also, there is no consistency when searching > > documentation - one page uses one term, one the other (and some even > > use both on the same page) . I don't know of many other pieces of > > software that use 2/3 different names for their primary functional > > object > > > > > > My proposal is to move towards having consistency of this naming and would > > look something like this: > > > > > > 1. Choose the name to use going forwards (more on that later) > > 2. Undertake a remedial exercise: > > * Update UI elements to [new name] > > * Update documentation to [New Name] > > * Leave Global Settings names alone, but change their description > > to reflect [New Name] > > * Leave the API alone - theres no way of getting consistency there > > without breaking compatibility > > 3. Encourage contributors to use [new name] in all work going > > forwards > > > > > > The remedial exercise (hopefully) could be a find/replace (with some > > manual checking) - I'd be happy to take that on with some help from work > > colleagues As/when/if we do do Cloudstack 5.0, then look at the API, but > > IMO this is lower priority as people that's not usdually "first impression" > > > > > > So - first proposal point: any objections to me undertaking this work ? > > > > > > Second point: wh
Re: [proposal] Consistency of naming in Cloudstack
Giles, the principle of what you are saying seems good but I have a few remarks; 1. Consistency should not become a goal. Clarity is and if context might give rise to a different understanding of the same work consistency is detrimental to understanding 2. Metaphor is an important aspect in system development [1] first introduced into software development in xtreme programming [2] I think instance is a bad metaphor to use for Virtual Machine Instances in a system that is full of all kinds of items (first class citizens) that can also be seen as instances. I would go for "VM instance", "VM-instance" or just machines. I am not saying either of these are ideal but they are all better than instance. and finally 3. The industry standard is not a good reason to go for a term. we can improve on the industry standard and so we should. €0.02 [1] https://medium.com/swlh/the-importance-of-metaphors-in-programming-philosophy-and-trading-a0030ed176b6 [2] http://www.extremeprogramming.org/rules/metaphor.html On Thu, Jun 8, 2023 at 4:47 PM Giles Sirett wrote: > > Background > Recently, I have been looking at a number of issues relating to the "first > use" / "first impression" use of cloudstack. What to people think of > Cloudstack as a new user? What is peoples perception of Cloudstack as a new > user ? How easy is it for people to understand cloudstack & its concepts and > to get help > > > One thing I have seen is that CloudStack is inconsistent with what we call > VM's/Instances: > > > * In the UI main menu, we say Instances. We then have a very large > "Create instance" button. All lifecycle operations are then "Foo Instance" > * In various other places in the UI (many text messages, error messages, > column headers, for example) we say "VM" > * The API uses Instance, VM and Virtual Machine > * The documentation, again, uses all 3 terms > > Now - I know everybody on this list (myself included for the last 10 years) > has always used these terms interchangeably - we all KNOW that these are the > same things. However, I think it could cause confusion to people seeing > Cloudstack for the first time and create negative impressions. Also, there is > no consistency when searching documentation - one page uses one term, one the > other (and some even use both on the same page) . I don't know of many other > pieces of software that use 2/3 different names for their primary functional > object > > > My proposal is to move towards having consistency of this naming and would > look something like this: > > > 1. Choose the name to use going forwards (more on that later) > 2. Undertake a remedial exercise: > * Update UI elements to [new name] > * Update documentation to [New Name] > * Leave Global Settings names alone, but change their description to > reflect [New Name] > * Leave the API alone - theres no way of getting consistency there > without breaking compatibility > 3. Encourage contributors to use [new name] in all work going forwards > > > The remedial exercise (hopefully) could be a find/replace (with some manual > checking) - I'd be happy to take that on with some help from work colleagues > As/when/if we do do Cloudstack 5.0, then look at the API, but IMO this is > lower priority as people that's not usdually "first impression" > > > So - first proposal point: any objections to me undertaking this work ? > > > Second point: what to call these things ? > It is my view that we should call them Instances. These are my reasons: > > * Nearly all Cloud computing platforms refer to them as instances (i.e. > industry standard) . Yes, it is a VM "behind the scenes", but Instance is an > accepted term that is slightly abstracted from VM > * Our primary UI already uses Instance ns most prominent places, renaming > top level nav and functionality is a step backwards IMO > * Today, Cloudstack provides these through VMs , but that could change in > the future (please don't read anything into that comment) - instance doesn't > tie us to VMs (which is probably why most cloud providers use it) > > So, my proposal is to bring consistency and use the term Instance > > From brief discussions, I know other people favour other terms and may have > objections to the term Instance (despite it having been in use in ACS for > many years) - but happy to take all inputs if people feel this is just wrong. > > > > > > Kind Regards > Giles > > > > -- Daan
Re: [DISCUSS] Upgrading Mockito & phasing out powermock
I like your approach Vishesh +1 from me On Tue, Jun 6, 2023 at 2:18 PM Vishesh Jindal wrote: > > Hi all, > > I am working on upgrading Mockito's version & phasing out powermock. For new > maven modules, I would request all to use Mockito's mockStatic instead of > Powermock. > > Why? > Powermock's last release was on Nov 2, 2020. The project seems to have been > abandoned. Powermock has compatibility issues with Mockito's latest version > as well. > > How? > The only usage for PowerMock I could see in code was for mocking static > methods. Since Mockito v3.4.0, it has the capability to mock static methods. > I plan to migrate tests to Mockito's mockStatic instead of PowerMock. This > will have to be done module by module and will take some time. > > I have prepared a PR here: https://github.com/apache/cloudstack/pull/7577 > > This PR upgrades mockito from v3.2.4 to v3.12.4 and removes the usage of > PowerMock from utils module. > > > Let me know if you have any questions/concerns. > > Regards, > Vishesh > > > > -- Daan
Re: Outdated wiki page
you should be able to edit now On Fri, Jun 2, 2023 at 3:44 PM Sina Kashipazha wrote: > > > Yes, I just created one, my username is "esterlinkof" > > > --- Original Message --- > On Friday, June 2nd, 2023 at 15:22, Daan Hoogland > wrote: > > > > > > > > Yes Sina, > > do you have an account on cwiki.apache.org? > > > > On Fri, Jun 2, 2023 at 3:14 PM Sina Kashipazha > > s.kashipa...@protonmail.com.invalid wrote: > > > > > Hey there, > > > > > > I found the following webpage on how to set up a Marvin test, but it's > > > pretty outdated and has some problems. Is it possible to edit it? > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python > > > > > > Kind regards, > > > Sina > > > > > > > > > > -- > > Daan -- Daan
Re: Outdated wiki page
Yes Sina, do you have an account on cwiki.apache.org? On Fri, Jun 2, 2023 at 3:14 PM Sina Kashipazha wrote: > > Hey there, > > I found the following webpage on how to set up a Marvin test, but it's pretty > outdated and has some problems. Is it possible to edit it? > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python > > Kind regards, > Sina -- Daan
Re: Introductions
nice, good luck and have fun On Fri, May 26, 2023 at 6:53 AM Ayush Pandey wrote: > Hi Everyone, > > I am Ayush Pandey, joining the community for a project as part of Google > Summer of code 2023. I will be working with my mentor Nicolas Vazquez on > "Extend Import-Export Instances to the KVM Hypervisor" > https://github.com/apache/cloudstack/issues/7127 > > I am really looking forward to collaborating with and learning from this > amazing community. > > Thank you, > Regards, > Ayush Pandey > -- Daan
Re: ACS upgrade to Log4J2 version 2.19
Daniel, comparing a dependency injection framework (or any larger framework) with a utility for something like logging is a false one. such a framework is implying design to a large part. The most complicated aspect of logging is its cross-cutting quality. I see this as a non-discussion and we should always create proxies for any libraries that can be proxied in order to reduce surface area in case we need to replace them. As for merge criteria: testing is the only thing missing I think. Again, this is not a missed opportunity, but then we can do that as a second step. On Thu, May 11, 2023 at 2:14 AM Daniel Salvador wrote: > Daan, > > IMHO, proxying libraries would bring us more disadvantages than benefits. > If we define that the standard is to proxy libraries such as Utils, Log4J, > and others, we would have to proxy all of them (even Spring); it would > require a huge effort (way more than this work with Log4j) to introduce and > maintain those proxies. Also, ACS already is a complex system to work; > proxying libraries would add one more layer of complexity to the platform > (and one more point of failure); thus, making it difficult for new > contributors to join the community. > > The community already put a lot of effort into the Log4J2 upgrade. The PR > being discussed in this thread is ready for merge (besides the conflicts > that the author is resolving as soon as they appear), it has been tested > (it could benefit from more testing though) with a variety of setups and > use cases, and the impact on conflicts is minimal (giving its size and > nature); therefore, along with what I pointed out, I do not think proxying > libraries would be a good approach. > > Furthermore, to conclude. If the community seems to count on support of > both users and other devs, and we have already done quite an extensive test > round, what else are we missing to move along with that PR? Is any of the > merging criteria missing to move on with it? > > Best regards, > Daniel Salvador (gutoveronezi) > > On Tue, May 9, 2023 at 1:52 PM Daan Hoogland > wrote: > > > Rohit, Daniel, > > > > Let me weigh in a bit. I held back about this as I have discussed this in > > the past a lot in different settings and do not want to take sides. My > > personal motivation for either reload4j or log4j2 are slim but I can see > > that people might want to lean to either. For this reason I want to bring > > up another pet preference of mine: > > > > I think we should proxy each and every external library we use with our > own > > packages. This means not even using something like slf4j but implement > our > > own framework and let people choose either on package or on deploytime > what > > to use, with a reasonable default of course. > > At the moment I would lean towards log4j2 as the default but I do not > want > > my clients to have to use that as I know some of them will blame me for > > extra night shifts if we do. > > > > This pet preference is valid for more than logging but is very applicable > > on the subject. > > > > This will require some extra effort, so feel free to push back but I > think > > it will be worth it. > > > > that all said the standardisation of the calling side of things is going > to > > be a pain but should be done as well. (imnsho) > > > > regards, > > > > > > On Sat, May 6, 2023 at 3:31 AM Daniel Salvador > > wrote: > > > > > Thanks, Rohit for the reply > > > > > > Not only the author, but me and other colleagues from the community can > > > build DEB and RPM packages (commands [1] and [2]). We already did, and > > the > > > process to build RPM and DEB works just fine. > > > > > > Also, basic CloudStack installation, setup and zone deployment, VM and > > > volume lifecycles with KVM and VMware, and so on, have already been > > tested > > > and that was reported on the PR and this thread. The problem here is > that > > > blueorangutan is failing and it is a black box; therefore, the author > > does > > > not know what is happening inside it. > > > > > > The conflicts that might happen in other PRs is mostly renaming the > > > loggers, which the fixes can be easily automated via scripts. For the > > > efforts on the release management, I am pretty sure some colleagues > from > > > the community would be glad to help as well. > > > > > > We understand the process and everybody seems to agree on this step > > > forward; is there any technical reason not to? Anyone else have > thoughts > > on > > > this
Re: [VOTE] Upgrade Log4j to Log4j2
-0 Joao, Daniel reacted negatively to my question to create a proxy with bad arguments and I had no time to respond yet. I think not adding a proxy at this time is a missed opportunity and I would full heartedly +1 if we had. Not creating a proxy class (with or without configurability) is a waste of your effort. All the standardisation of calls is very useful irrespective. On Tue, May 16, 2023 at 8:45 PM Daniel Salvador wrote: > Hello, João > > Considering the discussion we had in the thread[1] and that the conflicts > will be mostly regarding loggers names (which is simple to fix), I am +1 on > the proposal. > > Best regards, > Daniel Salvador (gutoveronezi) > > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2 > > On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti < > j...@scclouds.com.br> > wrote: > > > Hello guys, > > > > I am opening this voting thread as result of the discussion in thread > > "ACS upgrade to Log4J2 version 2.19"[1]. > > > > The voting aims to continue the efforts and conclude the upgrade of the > > ACS logging library to Log4j2 through PR 7131[2]; merge the PR as soon > > as possible and provide ways to contributors solve the conflicts easily, > > so all the contributors have time to fix their merge conflicts before > > 4.19; announce that change in the release notes and provide ways to > > users upgrade their customization made to the default log4j > > configuration files. > > > > 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) > > > > Best regards, > > João Jandre (JoaoJandre) > > > > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2 > > [2] https://github.com/apache/cloudstack/pull/7131 > > > > > -- Daan
Re: ACS upgrade to Log4J2 version 2.19
Rohit, Daniel, Let me weigh in a bit. I held back about this as I have discussed this in the past a lot in different settings and do not want to take sides. My personal motivation for either reload4j or log4j2 are slim but I can see that people might want to lean to either. For this reason I want to bring up another pet preference of mine: I think we should proxy each and every external library we use with our own packages. This means not even using something like slf4j but implement our own framework and let people choose either on package or on deploytime what to use, with a reasonable default of course. At the moment I would lean towards log4j2 as the default but I do not want my clients to have to use that as I know some of them will blame me for extra night shifts if we do. This pet preference is valid for more than logging but is very applicable on the subject. This will require some extra effort, so feel free to push back but I think it will be worth it. that all said the standardisation of the calling side of things is going to be a pain but should be done as well. (imnsho) regards, On Sat, May 6, 2023 at 3:31 AM Daniel Salvador wrote: > Thanks, Rohit for the reply > > Not only the author, but me and other colleagues from the community can > build DEB and RPM packages (commands [1] and [2]). We already did, and the > process to build RPM and DEB works just fine. > > Also, basic CloudStack installation, setup and zone deployment, VM and > volume lifecycles with KVM and VMware, and so on, have already been tested > and that was reported on the PR and this thread. The problem here is that > blueorangutan is failing and it is a black box; therefore, the author does > not know what is happening inside it. > > The conflicts that might happen in other PRs is mostly renaming the > loggers, which the fixes can be easily automated via scripts. For the > efforts on the release management, I am pretty sure some colleagues from > the community would be glad to help as well. > > We understand the process and everybody seems to agree on this step > forward; is there any technical reason not to? Anyone else have thoughts on > this? > > Best regards, > Daniel Salvador (gutoveronezi) > > [1] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id -u)" > -e "USER_GID=$(id -g)" -e "ACS_BUILD_OPTS=-Dnoredist" > scclouds/cloudstack-deb-builder:ubuntu2004-jdk11-python3 --git-remote > https://github.com/apache/cloudstack.git --git-ref refs/pull/7131/head > [2] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id -u)" > -e "USER_GID=$(id -g)" scclouds/cloudstack-rpm-builder:centos7-jdk11 > --distribution centos7 --pack noredist --git-remote > https://github.com/apache/cloudstack.git --git-ref refs/pull/7131/head > > > On Thu, May 4, 2023 at 3:45 AM Rohit Yadav > wrote: > > > Daniel, > > > > On your remarks; > > > > * The currently logging process indeed allows us to make changes to > > the log config xml which is read by the framework to affect what is > logged, > > without restarting say the management server, kvm agent or the ssvm/cpvm > > agents. Few of my colleagues have confirmed this works already. I'm not > > sure about any other features (or lack of them). > > > > * You're right about Reload4j's project statement to not add major > > changes, however, they state they'll do performance improvements, > > enhancements, and (security) fixes. I think this meets the requirements > of > > having a stable, reliable logging library. But you're right about the > > general innovation argument. > > > > That said if we've features we require, then I would look at (a) can > there > > be a central library framework/utility allowing users to choose what > > library they want to use, or (b) let's just agree and move to the > proposed > > log4j2.x if there are clear advantages. > > > > From what I've learned so far I don't see such clear advantages for the > > use cases I'm thinking or I've considered. I would be wrong by a mile, > but > > happy to hear what others think. > > > > * On testing the PR, those of us with access can certainly help as we > > help on all community PRs to review and help test. Pl go ahead and ask > any > > specifics, I'm sure we'd be happy to assist. I see a few contributors > with > > access are already helping. > > > > Another option the authors have is to try and build the rpm and deb > > packages themselves (we've documentation I think, and container images > that > > BO/Trilian uses here https://hub.docker.com/u/shapeblue). With such > > packages, the authors can at least test basic CloudStack installation, > > setup and zone deployment, VM, volume lifecycles. They may also try to > > deploy such env if packages are available and run smoketests using mbx > > which is a lite-version of BO/Trillian CI system, or that may be done > even > > manually (say with KVM in a VM?). > > > > * We shouldn't favour a particular pull request over others, or for > >
Re: [PROPOSE] ACS 4.18.1.0 release
+1, you have my support @weiz...@apache.org On Thu, 4 May 2023, 10:02 Rohit Yadav, wrote: > +1 > > Thanks for volunteering Wei, yes our community absolutely will benefits > with a 4.18.1.0 maintenance release! > > > Regards. > > > From: Wei ZHOU > Sent: Thursday, May 4, 2023 14:04 > To: dev@cloudstack.apache.org ; users < > us...@cloudstack.apache.org> > Subject: [PROPOSE] ACS 4.18.1.0 release > > Hi all, > > Currently CloudStack 4.18.0.0 is the latest LTS release. There are some > bugs and pull requests with 4.18.0.0 [1], including the fix for the upgrade > issue if users use MySQL 5.6 and 5.7. > > I would like to propose the release of 4.18.1.0 and the timeline > > - from now till the end of July (3 months): accept bug fixes and minor > improvements [2] > - first week in Aug: stablisation efforts, accept only blocker and critical > bug fixes. > - Aug: start cutting RCs, vote and finish release work. > > I will push myself as the release manager (RM) of 4.18.1.0, if nobody > objects. > In case anyone wants to include a bug fix or a pull request in 4.18.1.0 > milestone, please mention me (weizhouapache) on github. > > [1] https://github.com/apache/cloudstack/milestone/27 > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS > > > Any suggestions ? > > Kind regards, > Wei > > > >
Re: [PROPOSE] RM for 4.19.0
On Wed, May 3, 2023 at 12:01 PM Abhishek Kumar wrote: > Daan, Rohit and others, > > Personally, I don't see log4j2 PR alone or one particular feature/PR that > can be the reason for managing the release. Though I certainly understand > it may create some additional work for the RM. > I definitely agree with you on that, Abhishek. But whether you or Daniel is the RM, we still need to conclude in aggreement on this point before we can think of a release in my opinion. For users (and maybe to a lesser degree to operators) it might not seem as a big functional change, but it going be *a* defining feature for developers. Since Daniel also has an interest in being the RM for the 4.19 release, is > happy to do that additional work and RM work is not the most exciting work > for me :-P, I'm happy to support Daniel for the role. I, like others, can > help him where I can. > > Regards, > Abhishek > > > On Wed, 3 May 2023 at 14:49, Rohit Yadav > wrote: > > > +1 > > > > Thanks for volunteering Abhishek. As you've worked already as a RM for > > CloudStack LTS maintenance releases that you've shared and I think you > have > > all the necessary experience to work as the 4.19 RM. > > > > Daan, I don't see any mention of log4j on this thread or feel that > > Abhishek has disregarded the log4j issue. As an individual contributor, > > he's well within his rights to volunteer as a release manager and share > his > > opinion and thoughts in the community in this or any other threads. > > > > We shouldn't force or expect anybody to conclude a discussion in a way we > > would want. We must all conduct and treat one another professionally and > > politely on the mailing lists [1]. > > > > [1] https://cloudstack.apache.org/mailing-lists.html > > > > > > Regards. > > > > > > From: Daan Hoogland > > Sent: Tuesday, May 2, 2023 13:19 > > To: dev@cloudstack.apache.org > > Cc: us...@cloudstack.apache.org > > Subject: Re: [PROPOSE] RM for 4.19.0 > > > > Abhishek, I think the discussion about log4j2 needs to be concluded in > > coercion with this. I am fine if you and/or Daniel co-RM this release for > > instance, but the log4j issue may not be disregarded on these grounds and > > must be fully discussed and agreed upon. > > > > On Tue, May 2, 2023 at 9:43 AM Suresh Kumar Anaparti < > > sureshkumar.anapa...@gmail.com> wrote: > > > > > +1, Good luck Abhishek! > > > > > > Regards, > > > Suresh > > > > > > On Mon, May 1, 2023 at 7:49 PM Boris Stoyanov > > > wrote: > > > > > > > > +1, thanks Abhishek. I know we’re in safe hands with you! > > > > > > > > Bobby. > > > > > > > > From: Harikrishna Patnala > > > > Date: Monday, 1 May 2023, 9:21 > > > > To: us...@cloudstack.apache.org , > > > dev@cloudstack.apache.org > > > > Subject: Re: [PROPOSE] RM for 4.19.0 > > > > +1, thanks for volunteering and good luck Abhishek. > > > > > > > > Regards, > > > > Harikrishna > > > > > > > > From: Abhishek Kumar > > > > Date: Sunday, 30 April 2023 at 10:23 PM > > > > To: dev@cloudstack.apache.org , > > > us...@cloudstack.apache.org > > > > Subject: [PROPOSE] RM for 4.19.0 > > > > Dear All, > > > > > > > > I would like to propose and put myself forward as the release manager > > > for 4.19.0 release. In the past, I've RM'd 4.17.1.0 release and > co-RM'd a > > > couple of releases before that. I would like to take experiences from > > those > > > to work on a successful release. > > > > > > > > I propose we start early, sometime in Q3 2023, with the planning, > > > triaging, bug-fixing, etc to get back on the traditional two-release > per > > > year cycle. With this we can aim to cut the RC sometime in October. I > > will > > > propose a detailed timeline soon. > > > > > > > > I hope to have your support. Please let me know if you have any > > > thoughts/comments. > > > > > > > > Regards, > > > > Abhishek > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Daan > > > > > > > > > -- Daan
Re: [PROPOSE] RM for 4.19.0
On Wed, May 3, 2023 at 11:19 AM Rohit Yadav wrote: > +1 > > Thanks for volunteering Abhishek. As you've worked already as a RM for > CloudStack LTS maintenance releases that you've shared and I think you have > all the necessary experience to work as the 4.19 RM. > > Daan, I don't see any mention of log4j on this thread or feel that > Abhishek has disregarded the log4j issue. As an individual contributor, > he's well within his rights to volunteer as a release manager and share his > opinion and thoughts in the community in this or any other threads. > Sorry if I wasn't clear, there is no mention of log4j on this thread, but there is mention of RM work on the log4j thread [2]. [2] https://lists.apache.org/thread/t62rp2pzsrl21vjlqbdgg49kmdxgjxgd I am not saying that either Daniel or Abhishek should be the RM, but the work that we are going to have should be agreed upon. Having two RM candidates is a luxury we should not squander. If they can join efforts and get to a mutual supported plan that would be ideal. We shouldn't force or expect anybody to conclude a discussion in a way we > would want. We must all conduct and treat one another professionally and > politely on the mailing lists [1]. > > [1] https://cloudstack.apache.org/mailing-lists.html In short, I stand by my previous mail on this thread. This is provided there is no misunderstanding on what was meant. > > > > Regards. > > > From: Daan Hoogland > Sent: Tuesday, May 2, 2023 13:19 > To: dev@cloudstack.apache.org > Cc: us...@cloudstack.apache.org > Subject: Re: [PROPOSE] RM for 4.19.0 > > Abhishek, I think the discussion about log4j2 needs to be concluded in > coercion with this. I am fine if you and/or Daniel co-RM this release for > instance, but the log4j issue may not be disregarded on these grounds and > must be fully discussed and agreed upon. > > > ... > > > -- > Daan > > > > -- Daan
Re: [VOTE] Release Apache CloudStack CloudMonkey 6.3.0 - RC1
+1 (binding), monkey tested (no pun intended) connected to different local and remote envs bot by restarting and set profile commands. tried different commands and command completions Also trusting on Rohit's due diligence On Wed, May 3, 2023 at 11:32 AM Rohit Yadav wrote: > +1 (binding) > > The tarball/source and signatures are okay: > > # gpg --verify apache-cloudstack-cloudmonkey-6.3.0-src.tar.bz2.asc > gpg: assuming signed data in > 'apache-cloudstack-cloudmonkey-6.3.0-src.tar.bz2' > gpg: Signature made Mon May 1 19:36:51 2023 IST > gpg:using RSA key 4A64E2F46BBC136DD92D71FB5B7DEFE0508A4AD8 > gpg: Good signature from "Boris Stoyanov " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 4A64 E2F4 6BBC 136D D92D 71FB 5B7D EFE0 508A 4AD8 > > I was able to build cmk from the tarball source code and also tested the > uploaded community/convinience binaries and checksum - LGTM. > > I also checked the md5 checksum for the binaries on the Github > pre-release, they match the description on the pre-release: > > > md5 cmk.* > MD5 (cmk.darwin.arm64) = 1e9768e47350da347e5dae9c84db60e7 > MD5 (cmk.darwin.x86-64) = 132b6e32bf24f5c4472c7db31a12c4b9 > MD5 (cmk.linux.arm32) = fc881649ff02c91eb28f0a83229125f2 > MD5 (cmk.linux.arm64) = 8dfc3b284ee12b7c2564b9cf1bb47cb8 > MD5 (cmk.linux.x86) = 6f0a0776fdd0acd010f919413937c33c > MD5 (cmk.linux.x86-64) = 85616fd8c48648b353065878f78ae7d4 > MD5 (cmk.windows.x86-64.exe) = e0f726ce7ce518275dc4f8cad8e8bad3 > MD5 (cmk.windows.x86.exe) = b7e7109f6ab8c9899bb0c0635bd66a1c > > The version/build ID checks OK: > > On Mac OSX arm64: > # ./cmk.darwin.arm64 -v > Apache CloudStack CloudMonkey 6.3.0 (build: 860771a, > 2023-04-28T15:06:57+0300) > > On Ubuntu Linux 22.04 x86_64: > # ./bin/cmk -v > Apache CloudStack CloudMonkey 6.3.0 (build: 860771a, > 2023-04-28T15:06:55+0300) > > I performed basic API calls to list various resources and deploy VM [1] > using the cmk CLI on darwin/arm64, both in interpreter mode and in a shell > script. Tested against a local 4.17.2.0 env and also the community QA > server; > > [1] cmd ref: deploy virtualmachine > serviceofferingid=1be5e5c5-1a1e-4a61-b717-b19ba10579aa > templateid=0392376b-ac6c-46cd-be15-48d8ea3ba175 > zoneid=c843ba49-21c3-4616-a3ff-07bb91db3a6b > networkids=6d625e42-f1cc-4fe1-be95-a28256fc6df2 > > > Regards. > > > From: Boris Stoyanov > Sent: Monday, May 1, 2023 19:48 > To: dev@cloudstack.apache.org ; > us...@cloudstack.apache.org > Subject: [VOTE] Release Apache CloudStack CloudMonkey 6.3.0 - RC1 > > Hi All, > > I've created a v6.3.0 release of CloudMonkey, with the following > artifacts up for a vote: > > Git Branch and commit SHA: > > https://github.com/apache/cloudstack-cloudmonkey/commit/860771ad1e2a759a8099a4dbeb264c342e3b9577 > > Commit: > 860771ad1e2a759a8099a4dbeb264c342e3b9577 > > GitHub pre-release (for RC1 testing, contains changelog, > artifacts/binaries to test, checksums/usage details): > https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.3.0 > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-6.3.0/ > > > PGP release keys (signed using 4A64E2F46BBC136DD92D71FB5B7DEFE0508A4AD8) > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > The vote will be open until 5th May, 2023. > > 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 the reason why) > > > > > > > > -- Daan
Re: [PROPOSE] RM for 4.19.0
Abhishek, I think the discussion about log4j2 needs to be concluded in coercion with this. I am fine if you and/or Daniel co-RM this release for instance, but the log4j issue may not be disregarded on these grounds and must be fully discussed and agreed upon. On Tue, May 2, 2023 at 9:43 AM Suresh Kumar Anaparti < sureshkumar.anapa...@gmail.com> wrote: > +1, Good luck Abhishek! > > Regards, > Suresh > > On Mon, May 1, 2023 at 7:49 PM Boris Stoyanov > wrote: > > > > +1, thanks Abhishek. I know we’re in safe hands with you! > > > > Bobby. > > > > From: Harikrishna Patnala > > Date: Monday, 1 May 2023, 9:21 > > To: us...@cloudstack.apache.org , > dev@cloudstack.apache.org > > Subject: Re: [PROPOSE] RM for 4.19.0 > > +1, thanks for volunteering and good luck Abhishek. > > > > Regards, > > Harikrishna > > > > From: Abhishek Kumar > > Date: Sunday, 30 April 2023 at 10:23 PM > > To: dev@cloudstack.apache.org , > us...@cloudstack.apache.org > > Subject: [PROPOSE] RM for 4.19.0 > > Dear All, > > > > I would like to propose and put myself forward as the release manager > for 4.19.0 release. In the past, I've RM'd 4.17.1.0 release and co-RM'd a > couple of releases before that. I would like to take experiences from those > to work on a successful release. > > > > I propose we start early, sometime in Q3 2023, with the planning, > triaging, bug-fixing, etc to get back on the traditional two-release per > year cycle. With this we can aim to cut the RC sometime in October. I will > propose a detailed timeline soon. > > > > I hope to have your support. Please let me know if you have any > thoughts/comments. > > > > Regards, > > Abhishek > > > > > > > > > > > > > > > -- Daan
Re: ACS upgrade to Log4J2 version 2.19
I agree we should go to log4j2. I think if you used any scripts to do the renaming, João, you should share those here and on your PR. This will help people with dealing with the conflicts mentioned by Wei on users@. Also thank you for the effort to help this forward. regards, On Fri, Apr 28, 2023 at 2:57 PM João Jandre Paraquetti wrote: > In PR #7131 (https://github.com/apache/cloudstack/pull/7131) I have > proposed to normalize ACS's loggers, and more importantly, upgrade the > library log4j to log4j2 version 2.19. > > Log4j2 has a lot of features that could offer benefits to ACS: > > * Async Loggers - performance similar to logging switched off > * Custom log levels > * Automatically reload its configuration upon modification without > loosing log events during reconfigurations. > * Java 8-style lambda support for lazy logging (which enables methods > to be executed only when necessary, i.e.: the right log level) > * Log4j 2 is garbage-free (or at least low-garbage) since version 2.6 > * Plugin Architecture - easy to extend by building custom components > * Log4j 2 API is separated from the Log4j 2 implementation. > * Log4j 2 API supports more than just logging Strings: CharSequences, > Objects and custom Messages. Messages allow support for interesting > and complex constructs to be passed through the logging system and > be efficiently manipulated. Users are free to create their own > Message types and write custom Layouts, Filters and Lookups to > manipulate them. > * Concurrency improvements: log4j2 uses java.util.concurrent libraries > to perform locking at the lowest level possible. Log4j-1.x has known > deadlock issues. > * Configuration via XML, JSON, YAML, properties configuration files or > programmatically. > > In my personal experience using it in some other projects, log4j2 is > easier to work with in general, has better performance, and is an active > project with constant development, innovation, and security patches. > Moreover, it is under a well known and trusted open source organization. > > The change proposed in PR #7131 > (https://github.com/apache/cloudstack/pull/7131) has been tested and > validated in a lot of different scenarios by different people. We have > already tested the logging in the management server, usage, agents, and > system VMs; all of that using KVM and Vmware + Veeam. Most feature sets > were tested, create/delete/update VMs, disks, cresate snapshots, user > management and so on. > > The proposal has been discussed since January, 2023 in the PR > (https://github.com/apache/cloudstack/pull/7131), but I have been > requested to bring it to the mailing list. I would love to hear your > opinions on it, also, any reviews to the PR would be welcome. -- Daan
coming conflicts
Devs, There are two PRs [1][2] to be merged soon that have several hundreds of files involved. One is to unify the line-endings and the other one to (finaly) upgrade log4j. please beware that this is going to cause you to resolve conflicts in your PRs. regards, [1] https://github.com/apache/cloudstack/pull/7083 [2] https://github.com/apache/cloudstack/pull/7131 -- Daan
Re: Daan Hoogland - New ASF Member
thanks all, will try to be worthy ;) On Fri, Mar 24, 2023 at 2:17 PM Simon Weller wrote: > Wow, that's fantastic. Congratulations Daan! > > -Si > > On Fri, Mar 24, 2023 at 4:29 AM Paul Angus wrote: > > > > > > > It is my pleasure to announce that Daan Hoogland as been elected to > become > > a > > member of the ASF. > > > > The ASF would like to recognize both his practical involvement and the > way > > in which he has interacted with others in and around the ASF. > > > > > > > > Congratulations Daan. > > > > > > > > > > > > > > > > > > > > Kind regards > > > > > > > > Paul Angus > > > > > > > > > -- Daan
Fwd: TAC supporting Berlin Buzzwords
-- Forwarded message - From: Gavin McDonald Date: Fri, Mar 24, 2023 at 10:57 AM Subject: TAC supporting Berlin Buzzwords To: PMCs, Please forward to your dev and user lists. Hi All, The ASF Travel Assistance Committee is supporting taking up to six (6) people to attend Berlin Buzzwords In June this year. This includes Conference passes, and travel & accommodation as needed. Please see our website at https://tac.apache.org for more information and how to apply. Applications close on 15th April. Good luck to those that apply. Gavin McDonald (VP TAC) -- Daan
Apache CloudStack 4.18 LTS is released
We are pleased to announce that the Apache CloudStack 4.18.0.0 LTS Releaseis out. The Apache Software Foundation Announces Apache® CloudStack® v4.18. Apache CloudStack 4.18.0.0 is a 4.18 LTS release with 300+ new features, improvements, and bug fixes since 4.17, including 19 major new features. Some of the highlights include: - Edge Zones - Autoscaling - Managed User Data - Two-Factor Authentication Framework - Support for Time-based OTP (TOTP) Authenticator - Volume Encryption - SDN Integration – Tungsten Fabric - Ceph Multi Monitor Support - API-Driven Console Access - Console Access Security Improvements - New Global settings UI - Configurable MTU for VR - Adaptative Affinity Groups - Custom DNS Servers for Networks - Improved Guest OS Support Framework - Support for Enterprise Linux 9 - Networker Backup Plugin for KVM Hypervisor - Custom Quota Tariffs - Secure VNC for KVM Documentation The full list of new features can be found in the project release notes at http://docs.cloudstack.apache.org/en/4.18.0.0/releasenotes/changes.html The CloudStack documentation includes upgrade instructions from previous versions of Apache CloudStack, and can be found at: http://docs.cloudstack.apache.org/en/4.18.0.0/upgrading/index.html The official installation, administration and API documentation for each of the releases are available on our documentation page: http://docs.cloudstack.apache.org/ Downloads The official source code for the 4.18.0.0 release can be downloaded from our downloads page: http://cloudstack.apache.org/downloads.html In addition to the official source code release, individual contributors have also made convenience binaries available on the Apache CloudStack download page, and can be found at: https://download.cloudstack.org/ubuntu/dists/ https://download.cloudstack.org/centos/7/ https://download.cloudstack.org/centos/8/ https://download.cloudstack.org/suse/15 https://www.shapeblue.com/packages/
www
I know of some here that have trouble rebuilding the website with middleman. I am one of them. Is there anybody out there that can still do the build? -- Daan
[DRAFT][ANNOUNCEMENT][4.18] Pleased to announce Apache CloudStack 4.18
Marketeers, Please have a read through the following announcement and point me to any errors or omissions that need to be dealt with. Hopefully we can send this out on monday. NOTA BENE: the packages will be in place by than, but are not yet. Apache CloudStack 4.18.0.0 LTS Release The Apache Software Foundation Announces Apache® CloudStack® v4.18. Apache CloudStack 4.18.0.0 is a 4.18 LTS release with 300+ new features, improvements, and bug fixes since 4.17, including 19 major new features. Some of the highlights include: - Edge Zones - Autoscaling - Managed User Data - Two-Factor Authentication Framework - Support for Time-based OTP (TOTP) Authenticator - Volume Encryption - SDN Integration – Tungsten Fabric - Ceph Multi Monitor Support - API-Driven Console Access - Console Access Security Improvements - New Global settings UI - Configurable MTU for VR - Adaptative Affinity Groups - Custom DNS Servers for Networks - Improved Guest OS Support Framework - Support for Enterprise Linux 9 - Networker Backup Plugin for KVM Hypervisor - Custom Quota Tariffs - Secure VNC for KVM Documentation The full list of new features can be found in the project release notes at http://docs.cloudstack.apache.org/en/4.18.0.0/releasenotes/changes.html The CloudStack documentation includes upgrade instructions from previous versions of Apache CloudStack, and can be found at: http://docs.cloudstack.apache.org/en/4.18.0.0/upgrading/index.html The official installation, administration and API documentation for each of the releases are available on our documentation page: http://docs.cloudstack.apache.org/ Downloads The official source code for the 4.18.0.0 release can be downloaded from our downloads page: http://cloudstack.apache.org/downloads.html In addition to the official source code release, individual contributors have also made convenience binaries available on the Apache CloudStack download page, and can be found at: https://download.cloudstack.org/ubuntu/dists/ https://download.cloudstack.org/centos/7/ https://download.cloudstack.org/centos/8/ https://download.cloudstack.org/suse/15 https://www.shapeblue.com/packages/ regards,
Re: [RESULT][VOTE] Apache CloudStack 4.18.0.0
devs, main, 4.17 and 4.18 are open for any approved commit now that the milestone is closed and the release is ready to be announced. On Wed, Mar 15, 2023 at 7:32 PM Daan Hoogland wrote: > Hi all, > > After 72 hours, the vote for CloudStack 4.18.0.0 *passes* with > 5 PMC + 0 non-PMC votes. > > +1 (PMC / binding) > * Nux (lucian) > * Rohit > * Simon > * Boris > * Nicolas > > +1 (non binding) > None > > 0 > none > > -1 > none > > Thanks to everyone participating. > > I will now prepare the release announcement to go out after 24 hours to give > the mirrors time to catch up. > >
[RESULT][VOTE] Apache CloudStack 4.18.0.0
Hi all, After 72 hours, the vote for CloudStack 4.18.0.0 *passes* with 5 PMC + 0 non-PMC votes. +1 (PMC / binding) * Nux (lucian) * Rohit * Simon * Boris * Nicolas +1 (non binding) None 0 none -1 none Thanks to everyone participating. I will now prepare the release announcement to go out after 24 hours to give the mirrors time to catch up.
Re: [4.18][RC3][VOTE] new release candidate 4.18.0.0-RC20230311T0935
packages are available at https://download.cloudstack.org/testing/4.18-rc3/ and http://packages.shapeblue.com/cloudstack/upstream/testing/4.18.0.0-RC20230311T0935/ On Sat, Mar 11, 2023 at 9:45 AM Daan Hoogland wrote: > Hi All, > > I've created a new 4.18 release candidate, with the following artifacts up > for a vote: > > Git Branch and Commit > SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230311T0935 > Commit: 0574087284f8b646ebc41617cfd70b3a31e3ae94 > > Source release (checksums and signatures are available at the same > location): https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0 > > PGP release keys (signed using > 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4):https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > Vote will be open for 72 hours. (aiming for wednesday late) > > 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) > > As usual lately, I will work on getting some convenience packages ready and > will follow up on this thread to link you to those. > > enjoy > >
[4.18][RC3][VOTE] new release candidate 4.18.0.0-RC20230311T0935
Hi All, I've created a new 4.18 release candidate, with the following artifacts up for a vote: Git Branch and Commit SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230311T0935 Commit: 0574087284f8b646ebc41617cfd70b3a31e3ae94 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0 PGP release keys (signed using 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4):https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. (aiming for wednesday late) 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) As usual lately, I will work on getting some convenience packages ready and will follow up on this thread to link you to those. enjoy
Re: [4.18][RELEASE] RC2 up for vote
I've been a bit silent. As several new issues were brought forward I have not attempted to create a new RC yet. The most pressing one is that volumes can get lost during migrate on vmware and a fix is being devised as we write. I will update you at the end of the week. On Thu, Mar 2, 2023 at 10:07 AM Rohit Yadav wrote: > Thanks Daan, looking at the outstanding issues/PRs list here are some > suggestions that you can help triage and include in RC3: > > https://github.com/apache/cloudstack/pull/7302 > https://github.com/apache/cloudstack/pull/7304 > https://github.com/apache/cloudstack/pull/7268 (needs manual > QA/regression test) > https://github.com/apache/cloudstack/pull/7291 (needs manual > QA/regression test) > https://github.com/apache/cloudstack/pull/7237 (PR author to advise if > this is critical?) > https://github.com/apache/cloudstack/pull/7229 (not sure if this causes a > critical billing/usage issue?) > > > Regards. > > > From: Daan Hoogland > Sent: Thursday, March 2, 2023 14:31 > To: dev@cloudstack.apache.org > Cc: users ; PMC < > priv...@cloudstack.apache.org> > Subject: Re: [4.18][RELEASE] RC2 up for vote > > unfortunately I am -1 myself :( > > Last night Marcus and Wei explored a security issue in the new feature of > volume encryption. A fix is underway. I will create an RC3 asap. > Please reply here with any other critical issues you want included in the > next release candidate? > > regard, > > On Wed, Mar 1, 2023 at 5:29 PM Vladimir Petrov < > vladimir.pet...@shapeblue.com> wrote: > > > Hi all, > > > > +1, I tested different upgrades (from 4.15, 4.16 and 4.17 using different > > hypervisors) and the common operations and found no issues. > > > > Best wishes, > > Vladi > > > > > > > > Daan Hoogland wrote: > > > > > > Hi All, > > some small errata, > > - I added my key > > - I will keep this vote open till friday, we've had a weekend and being > > lenient on those 72 hours will not hurt the quality, I think. > > It has taken some time but; > > > > I've created a second 4.18.0.0 release candidate, with the following > > artifacts up for a vote: > > > > Git Branch and Commit > > SH: > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230224T1301 > > Commit: 77961d6aa583a347b289af4cbb732b77c8be8ebe > > > > Source release (checksums and signatures are available at the following > > location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0/ > > > > PGP release keys (signed using > > 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > Vote will be open for at least 72 hours. > > > > 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) > > > > > > > > > > -- > Daan > > > > -- Daan
Re: [4.18][RELEASE] RC2 up for vote
unfortunately I am -1 myself :( Last night Marcus and Wei explored a security issue in the new feature of volume encryption. A fix is underway. I will create an RC3 asap. Please reply here with any other critical issues you want included in the next release candidate? regard, On Wed, Mar 1, 2023 at 5:29 PM Vladimir Petrov < vladimir.pet...@shapeblue.com> wrote: > Hi all, > > +1, I tested different upgrades (from 4.15, 4.16 and 4.17 using different > hypervisors) and the common operations and found no issues. > > Best wishes, > Vladi > > > > Daan Hoogland wrote: > > > Hi All, > some small errata, > - I added my key > - I will keep this vote open till friday, we've had a weekend and being > lenient on those 72 hours will not hurt the quality, I think. > It has taken some time but; > > I've created a second 4.18.0.0 release candidate, with the following > artifacts up for a vote: > > Git Branch and Commit > SH: > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230224T1301 > Commit: 77961d6aa583a347b289af4cbb732b77c8be8ebe > > Source release (checksums and signatures are available at the following > location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0/ > > PGP release keys (signed using > 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > Vote will be open for at least 72 hours. > > 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) > > > > -- Daan
Re: [4.18][RELEASE] RC2 up for vote
Hi All, some small errata, - I added my key - I will keep this vote open till friday, we've had a weekend and being lenient on those 72 hours will not hurt the quality, I think. It has taken some time but; I've created a second 4.18.0.0 release candidate, with the following artifacts up for a vote: Git Branch and Commit SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230224T1301 Commit: 77961d6aa583a347b289af4cbb732b77c8be8ebe Source release (checksums and signatures are available at the following location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0/ PGP release keys (signed using 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4):https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for at least 72 hours. 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)
Re: [4.18][RELEASE] RC2 up for vote
Ah, yes, I had to create a new key as the old ones (also in the KEYS file were no longer valid (at least none that I knew) ``` sec rsa4096 2023-02-14 [SC] 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4 uid [ultimate] Daan Hoogland (CODE SIGNING KEY) ssb rsa4096 2023-02-14 [E] ``` I forgot to add it to the message. On Mon, Feb 27, 2023 at 8:24 AM Rohit Yadav wrote: > Verified the source tarball is OK for RC2: (assuming Daan's signing key ID > 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4 from KEYS file, not explicitly > mentioned in the vote mail) > > > gpg --verify apache-cloudstack-4.18.0.0-src.tar.bz2.asc > apache-cloudstack-4.18.0.0-src.tar.bz2 > gpg: Signature made Fri Feb 24 17:31:21 2023 IST > gpg:using RSA key 256ABDFB8D89EDE07540BE6ACEF9E802B86FEED4 > gpg: Good signature from "Daan Hoogland (CODE SIGNING KEY) < > d...@apache.org>" [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 256A BDFB 8D89 EDE0 7540 BE6A CEF9 E802 B86F EED4 > > > Regards. > > > From: Daan Hoogland > Sent: Monday, February 27, 2023 02:33 > To: priv...@cloudstack.apache.org > Cc: dev@cloudstack.apache.org ; users < > us...@cloudstack.apache.org> > Subject: Re: [4.18][RELEASE] RC2 up for vote > > There are now also convenience packages on > download.cloudstack.org/testing/4.18-rc2 for a variety of systems. The > ubuntu packages are not indexed but are downloadable at least. > regards, > > On Fri, Feb 24, 2023 at 5:25 PM Daan Hoogland > wrote: > > > There are convenience packages available at > > > http://packages.shapeblue.com/cloudstack/upstream/testing/4.18.0.0-RC20230224T1301/ > > for el7 el8 and debian. > > > > On Fri, Feb 24, 2023 at 1:44 PM Daan Hoogland > > wrote: > > > >> I am building packages as well, I had some issues uploading to > >> download.cloudstack.org, last time. There will be shapeblue packages > >> soon. > >> > > > > > > On Fri, Feb 24, 2023 at 1:40 PM Wei ZHOU wrote: > >> > >>> Cloudstack-simulator docker image > >>> > >>> > >>> > https://hub.docker.com/layers/apache/cloudstack-simulator/4.18.0.0-RC2/images/sha256-946698fe9f90c353b1d7bfa7ce8486b9a85954446c9eccbbf1ddce682c66b1ae?context=explore > >>> > >>> -Wei > >>> > >>> > >>> On Friday, 24 February 2023, Daan Hoogland wrote: > >>> > >>>> 77961d6aa583a347b289af4cbb732b77c8be8ebe > >>>> > >>>> Hi All, > >>>> It has taken some time but; > >>>> > >>>> I've created a second 4.18.0.0 release candidate, with the following > >>>> artifacts up for a vote: > >>>> > >>>> Git Branch and Commit > >>>> SH: > >>>> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230224T1301 > >>>> Commit: 77961d6aa583a347b289af4cbb732b77c8be8ebe > >>>> > >>>> Source release (checksums and signatures are available at the > following > >>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.0.0/ > >>>> > >>>> PGP release keys (signed using > >>>> ):https://dist.apache.org/repos/dist/release/cloudstack/KEYS > >>>> > >>>> Vote will be open for 72 hours. > >>>> > >>>> 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) > >>>> > >>> > >> > >> -- > >> Daan > >> > > > > > > -- > > Daan > > > > > -- > Daan > -- Daan
