[PR] Change default java version [cloudstack-documentation]
vishesh92 opened a new pull request, #384: URL: https://github.com/apache/cloudstack-documentation/pull/384 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] systemvm: Update patch systemvm support matrix [cloudstack-documentation]
weizhouapache commented on PR #382: URL: https://github.com/apache/cloudstack-documentation/pull/382#issuecomment-1954103894 https://cloudstack-documentation--382.org.readthedocs.build/en/382/upgrading/upgrade/_sysvm_restart.html   -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Add UEFI support [cloudstack-terraform-provider]
vdombrovski commented on code in PR #83:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/83#discussion_r1495629658
##
cloudstack/resource_cloudstack_instance.go:
##
@@ -277,6 +283,11 @@ func resourceCloudStackInstanceCreate(d
*schema.ResourceData, meta interface{})
p.SetRootdisksize(int64(rootdisksize.(int)))
}
+ if d.Get("uefi").(bool) {
+ p.SetBoottype("UEFI")
+ p.SetBootmode("Legacy")
Review Comment:
I was thinking about adding this as a second step, if the community needs
it. Currently I don't have any way to test the UEFI Secure mode (I'm not even
sure it works properly in ACS).
For now this is meant to be an easy and naive implementation that covers the
most important need, which is to run UEFI cloud images; This is also a pressing
issue now that some distros (e.g. Ubuntu) are providing [UEFI only cloud
images](https://cloud-images.ubuntu.com/noble/current/).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
RE: [VOTE] next version 20 instead of 4.20
Hi Daan, >From our wiki page: -- Quote For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor 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 > > 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 info
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
Re: [PR] feature: tagged resource limits [cloudstack-documentation]
rohityadavcloud commented on PR #379: URL: https://github.com/apache/cloudstack-documentation/pull/379#issuecomment-1953790288 Is this ready for merging @shwstppr ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] feature: tagged resource limits [cloudstack-documentation]
shwstppr commented on PR #379: URL: https://github.com/apache/cloudstack-documentation/pull/379#issuecomment-1953816038 @rohityadavcloud yes -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Community Over Code Asia 2024 Travel Assistance Applications now open!
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code Asia 2024 are now open! We will be supporting Community over Code Asia, Hangzhou, China July 26th - 28th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this year's applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, May 10th, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you to apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Hangzhou, China in July, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
Re: [I] v2.15.0 breaking change regarding displayText handling for CreateNetwork [cloudstack-go]
rohityadavcloud commented on issue #70: URL: https://github.com/apache/cloudstack-go/issues/70#issuecomment-1953745775 Agree with @weizhouapache, cc @shwstppr -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] v2.15.0 breaking change regarding displayText handling for CreateNetwork [cloudstack-go]
shwstppr commented on issue #70: URL: https://github.com/apache/cloudstack-go/issues/70#issuecomment-1953684551 @weizhouapache okay I'll add those removed methods -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] v2.15.0 breaking change regarding displayText handling for CreateNetwork [cloudstack-go]
weizhouapache commented on issue #70: URL: https://github.com/apache/cloudstack-go/issues/70#issuecomment-1953673993 @shwstppr to keep backward compatibility, can we manually add the methods which are removed by #76 ? (keep both new and old methods) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
