Re: CSEUG - September, Germany
Hi all, Will be Frankfurt. Swen from proIO is really excited to help us organise, so we have somebody on place to support, which is really cool. Best regards, On 1 Mar 2024, at 11:06, Wido den Hollander wrote: Op 28/02/2024 om 16:29 schreef Ivet Petrova: Hi all, I would like to propose to organise the CSEUG next meeting on September 12th in Germany. I already had a few informal conversations with community members in Germany, who are willing to help. Do you all think the date is OK and we can meet there? Works for me on 12-09. Just wondering, Germany is big, which city are we looking at? Frankfurt? Berlin? München? Düsseldorf? :-) Wido I consider the usual formal of half day talks and will need 5-6 speakers on place. Best regards,
[PR] added podid parameter [cloudstack-terraform-provider]
kiranchavala opened a new pull request, #89: URL: https://github.com/apache/cloudstack-terraform-provider/pull/89 This PR fixes #87 Added Pod id to the cloudstack instance resource https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs/resources/instance -- 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] added podid parameter [cloudstack-terraform-provider]
rohityadavcloud merged PR #89: URL: https://github.com/apache/cloudstack-terraform-provider/pull/89 -- 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] Improvement request - Support specifying POD name as resource [cloudstack-terraform-provider]
rohityadavcloud closed issue #87: Improvement request - Support specifying POD name as resource URL: https://github.com/apache/cloudstack-terraform-provider/issues/87 -- 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] details changes are not beeing applied [cloudstack-terraform-provider]
kiranchavala commented on issue #58: URL: https://github.com/apache/cloudstack-terraform-provider/issues/58#issuecomment-1978316336 Able to reproduce the issue i belive this is because the terraform code (resourceCloudStackInstanceUpdate) doesn't have the details parameter https://github.com/apache/cloudstack-terraform-provider/blob/c8279b9ae5f45f29c16322ad21271e2325ec3d81/cloudstack/resource_cloudstack_instance.go#L488 https://cloudstack.apache.org/api/apidocs-4.19/apis/updateVirtualMachine.html cc @vishesh92 -- 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] error retrieving ID of zone all: No match found for all: &{Count:0 Zones:[]} [cloudstack-terraform-provider]
kiranchavala commented on issue #48: URL: https://github.com/apache/cloudstack-terraform-provider/issues/48#issuecomment-1978338596 I think this can be fixed by including the zoneids parameter Need to include zoneids parameter in the terraform code (resourceCloudStackTemplate, resourceCloudStackTemplateCreate) https://github.com/apache/cloudstack-terraform-provider/blob/c8279b9ae5f45f29c16322ad21271e2325ec3d81/cloudstack/resource_cloudstack_template.go#L32 https://cloudstack.apache.org/api/apidocs-4.19/apis/registerTemplate.html cc @vishesh92 -- 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] Support hot resize of disk [cloudstack-terraform-provider]
kiranchavala commented on issue #72:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/72#issuecomment-1978593625
@vdombrovski
I have cross-checked the issue and disk resize is happening when you use a
custom disk offering
Terraform is performing the resize operation :
```
# cloudstack_disk.test-disk will be updated in-place
~ resource "cloudstack_disk" "test-disk" {
id = "d5a695d5-7bd7-46f8-b63f-be81152584bf"
name = "test-disk"
~ size = 5 -> 10
tags = {}
# (6 unchanged attributes hidden)
}
```
Please make sure to use a custom disk offering
```
resource "cloudstack_disk" "default" {
name = "test-disk"
attach = "true"
disk_offering = "custom"
size = 50
virtual_machine_id = "server-1"
zone = "zone-1"
}
```
--
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] Add Override root disk offering and Disk Offerings to cloudstack_instance Resource [cloudstack-terraform-provider]
kiranchavala commented on issue #68:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/68#issuecomment-1978716001
@vishesh92
We need to add the parameter "overridediskofferingid" to the resource
cloudstack_instance
https://cloudstack.apache.org/api/apidocs-4.19/apis/deployVirtualMachine.html
https://github.com/apache/cloudstack-terraform-provider/blob/main/cloudstack/resource_cloudstack_instance.go
https://github.com/apache/cloudstack-go/blob/main/cloudstack/VirtualMachineService.go#L40
When I added the following code and try to build it locally getting the
following exception
```
"overridediskofferingid": {
Type: schema.TypeString,
Optional: true,
},
if overridediskofferingid, ok := d.GetOk("overridediskofferingid"); ok {
p.SetOverridediskofferingid(overridediskofferingid.(string))
}
```
```
cloudstack-terraform-provider git:(add-overridediskofferingid) ✗ go build
# github.com/terraform-providers/terraform-provider-cloudstack/cloudstack
cloudstack/resource_cloudstack_instance.go:291:5:
p.SetOverridediskofferingid undefined (type
*"github.com/apache/cloudstack-go/v2/cloudstack".DeployVirtualMachineParams has
no field or method SetOverridediskofferingid)
```
--
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] Registry 404 error - failed to │ retrieve authentication checksums for provider [cloudstack-terraform-provider]
kiranchavala commented on issue #29: URL: https://github.com/apache/cloudstack-terraform-provider/issues/29#issuecomment-1978725813 Closing the issue as the issue is not observed anymore @synergiator please reopen if you are observing the issue again -- 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] Registry 404 error - failed to │ retrieve authentication checksums for provider [cloudstack-terraform-provider]
kiranchavala closed issue #29: Registry 404 error - failed to │ retrieve authentication checksums for provider URL: https://github.com/apache/cloudstack-terraform-provider/issues/29 -- 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
CloudStack Collaboration Conference 2024
Hi all, The CloudStack Collaboration Conference 2024 will happen in Nov - 20-22 in Madrid, Spain. With some community members we are now researching for the best venue for the event. Although we have a lot of time, we have started slowly the organisation. There are a few things we need to decide as a community: - the event platform - last 3 years we were using Hubilo, which was great. However, the price they give me for this year for a single event is 8000 USD. Last year we pay 3000, which was also crazy expensive. As this is crazy amount of money, I would suggest we have this years event just as a physical event and no live-streaming. We will record the sessions and post them on our YouTube channel. IMO the best would be to have physical event only, but I would like to get your feedback and preferences also. - event fee - last year some of the event participants shared that in their opinion we shall charge for the event - sell tickets. Of course we will have early bird discounts, free tickets for students, committers, PMC members, option for the sponsors to provide free tickets to people they would like to invite, etc. But what would be a reasonable amount as a ticket fee according to you all? I wanted to share these two important things with the community and start early discussions on it. Best regards,
Re: [I] Failure to add secondary IP to a NIC for a VM in a project [cloudstack-terraform-provider]
kiranchavala commented on issue #31:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/31#issuecomment-1978939126
@Pearl1594
Not able to reproduce the issue, I was able to deploy a vm and add secondary
IP to a NIC for a VM in a project.
Let me know if can close the issue
My sample terraform file
```
provider "cloudstack" {
api_url= var.cloudstack_api_url
api_key= var.cloudstack_api_key
secret_key = var.cloudstack_secret_key
}
resource "cloudstack_network" "test-network" {
name = var.network_name
cidr = "10.0.0.0/24"
network_offering = var.network_offering
zone = var.zone
project = "test"
}
resource "cloudstack_instance" "test-vm" {
name = var.instance_name
service_offering = var.instance_service_offering
network_id = cloudstack_network.test-network.id
template = var.instance_template
zone = var.zone
project = "test"
expunge = true
depends_on = [
cloudstack_network.test-network
]
}
resource "cloudstack_secondary_ipaddress" "default" {
virtual_machine_id = cloudstack_instance.test-vm.id
depends_on = [ cloudstack_network.test-network,
cloudstack_instance.test-vm ]
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Added encrypt and tags option to disk offering [cloudstack-terraform-provider]
kiranchavala closed pull request #84: Added encrypt and tags option to disk offering URL: https://github.com/apache/cloudstack-terraform-provider/pull/84 -- 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] Added encrypt and tags option to disk offering [cloudstack-terraform-provider]
kiranchavala commented on PR #84: URL: https://github.com/apache/cloudstack-terraform-provider/pull/84#issuecomment-1978968098 Closed the PR as it' majorly already covered by #77 -- 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] network_id remains empty after creating IP address resource [cloudstack-terraform-provider]
kiranchavala commented on issue #32: URL: https://github.com/apache/cloudstack-terraform-provider/issues/32#issuecomment-1979008581 @kohrar I am not hitting the issue on the latest build. Let me know if i can close the issue https://github.com/apache/cloudstack-terraform-provider/assets/1401014/04e176a1-e77f-4081-9193-a798e79ccc66";> -- 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
As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0). The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki. Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote? Regards. From: Paul Angus Sent: Tuesday, February 20, 2024 15:55 To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: 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 version
Re: [I] Allow connecting network ACL to a (VPC) network according API specs [cloudstack-terraform-provider]
kiranchavala commented on issue #28:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/28#issuecomment-1979110909
@vishesh92
Need to add networkid parameter to the "resource_cloudstack_network_acl"
https://cloudstack.apache.org/api/apidocs-4.19/apis/createNetworkACL.html
https://github.com/apache/cloudstack-go/blob/main/cloudstack/NetworkACLService.go
When i performed the changes getting a build error
```
"network_id": {
Type: schema.TypeString,
Optional: true,
ForceNew: true,
},
if networkid, ok := d.GetOk("network_id"); ok {
p.SetNetworkid(networkid.(string))
}
```
```
cloudstack-terraform-provider git:(add-networkid) ✗ make build
==> Checking that code complies with gofmt requirements...
go install
# github.com/terraform-providers/terraform-provider-cloudstack/cloudstack
cloudstack/resource_cloudstack_network_acl.go:91:5: p.SetNetworkid undefined
(type
*"github.com/apache/cloudstack-go/v2/cloudstack".CreateNetworkACLListParams has
no field or method SetNetworkid)
make: *** [build] Error 1
```
--
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] API backward compatibility problem while deploying virtual machines using human readable template reference name [cloudstack-terraform-provider]
kiranchavala commented on issue #18:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/18#issuecomment-1979156884
@synergiator
Not able to reproduce the issue able to deploy instance by giving the
template name, tested on the latest cloudstack 4.19 release.
Let me know if i can go ahead and close the issue
```
# cloudstack_instance.test-vm will be created
+ resource "cloudstack_instance" "test-vm" {
+ display_name = (known after apply)
+ expunge = true
+ group= (known after apply)
+ id = (known after apply)
+ ip_address = (known after apply)
+ name = "hyd-demo-test"
+ network_id = (known after apply)
+ project = (known after apply)
+ root_disk_size = (known after apply)
+ service_offering = "9c870dca-a857-468c-a804-29b256af6b53"
+ start_vm = true
+ tags = (known after apply)
+ template = "Centos7"
+ zone = "49e9ad34-8a3d-4f87-8ff5-90d65859f839"
}
```
--
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: CSEUG - September, Germany
Great! Thanks Swen! -Wei On Tuesday, March 5, 2024, Ivet Petrova wrote: > Hi all, > > Will be Frankfurt. Swen from proIO is really excited to help us organise, > so we have somebody on place to support, which is really cool. > > Best regards, > > > > > On 1 Mar 2024, at 11:06, Wido den Hollander wrote: > > > > Op 28/02/2024 om 16:29 schreef Ivet Petrova: > Hi all, > I would like to propose to organise the CSEUG next meeting on September > 12th in Germany. > I already had a few informal conversations with community members in > Germany, who are willing to help. > Do you all think the date is OK and we can meet there? > > Works for me on 12-09. Just wondering, Germany is big, which city are we > looking at? > > Frankfurt? Berlin? München? Düsseldorf? :-) > > Wido > > I consider the usual formal of half day talks and will need 5-6 speakers > on place. > Best regards, > > >
RE: [VOTE] next version 20 instead of 4.20
Hi Rohit, thank you So to recap; Semantic versioning goes (in our use): . . . And as I understand it you're looking to go . . Starting from 20 I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth). I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning. So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to . . I would be ok to +1 that ^^^ -paul -Original Message- From: Rohit Yadav Sent: Tuesday, March 5, 2024 4:02 PM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Re: [VOTE] next version 20 instead of 4.20 As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0). The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki. Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote? Regards. From: Paul Angus Sent: Tuesday, February 20, 2024 15:55 To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: 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 adj
[PR] Force some param to be required [cloudstack-go]
vishesh92 opened a new pull request, #79: URL: https://github.com/apache/cloudstack-go/pull/79 Addresses https://github.com/apache/cloudstack-go/issues/70 & https://github.com/apache/cloudstack-go/pull/77 cc: @shwstppr @rohityadavcloud @weizhouapache -- 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
By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. That is not what was discussed in the thread [1]. If we agree that we will not break APIs, I am -1 on dropping the "4". We need to create a protocol along with the proposal, otherwise, we will be subjective about the topic and will be agreeing on something for different reasons. [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv On 3/5/24 15:10, Paul Angus wrote: Hi Rohit, thank you So to recap; Semantic versioning goes (in our use): . . . And as I understand it you're looking to go . . Starting from 20 I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth). I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning. So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to . . I would be ok to +1 that ^^^ -paul -Original Message- From: Rohit Yadav Sent: Tuesday, March 5, 2024 4:02 PM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Re: [VOTE] next version 20 instead of 4.20 As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0). The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki. Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote? Regards. From: Paul Angus Sent: Tuesday, February 20, 2024 15:55 To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: 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
Re: [PR] restore methods with 4.19 optional API params [cloudstack-go]
shwstppr closed pull request #77: restore methods with 4.19 optional API params URL: https://github.com/apache/cloudstack-go/pull/77 -- 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
Daniel, Daan, others, Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility? Regards. From: Guto Veronezi Sent: Wednesday, March 6, 2024 4:00:30 AM To: dev@cloudstack.apache.org Subject: Re: [VOTE] next version 20 instead of 4.20 > By agreeing to drop the "4" I think we're effectively voting and agreeing > that we'll not be breaking APIs. That is not what was discussed in the thread [1]. If we agree that we will not break APIs, I am -1 on dropping the "4". We need to create a protocol along with the proposal, otherwise, we will be subjective about the topic and will be agreeing on something for different reasons. [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv On 3/5/24 15:10, Paul Angus wrote: > Hi Rohit, thank you > > So to recap; > > Semantic versioning goes (in our use): > . . . > > > And as I understand it you're looking to go > > . . > Starting from 20 > > I'd ask the question - are there any big/disruptive changes people would want > to bundle together to keep the semantic versioning and move to 5.x.y.z > > I'm assuming not, so the move proposed is to drop semantic versioning and > continue from 20, understanding that we would lose the mechanism to warn of > very disruptive changes (for what it's worth). > > I've no objection to it. The issue was, that reading the thread, people had > different takes on what the change was, what would it do and what it meant. > And also incorrect understandings of semantic versioning. > > So, to be pedantic, and have a clearly defined vote, I'd change the vote to > something like "Drop semantic versioning and continue from 20". And include > your explanation about moving to > . . > > I would be ok to +1 that ^^^ > > -paul > > -Original Message- > From: Rohit Yadav > Sent: Tuesday, March 5, 2024 4:02 PM > To: dev@cloudstack.apache.org; us...@cloudstack.apache.org > Subject: Re: [VOTE] next version 20 instead of 4.20 > > As I understand Daan's vote proposal and from the previous discussion thread, > the current scheme that results in a release like 4.20.x.y would simply > become 20.a.b, wherein "a" is for maintenance release (counter, starting with > 0) and "b" is only used for security releases (counter, starting with 0). > > The voting thread is about "deciding to drop the 4 from our versioning > scheme", wherein the next CloudStack version would become "20" instead of > "4.20". By agreeing to drop the "4" I think we're effectively voting and > agreeing that we'll not be breaking APIs. Some other opensource projects have > done something similar too. Of course, this needs to be properly explained > and documented both by a blog article and on the project wiki. > > Paul - are you satisfied with the explanations and discussions, are you still > blocking this vote thead or do you want to reconsider your vote? > > > Regards. > > > > > > From: Paul Angus > Sent: Tuesday, February 20, 2024 15:55 > To: dev@cloudstack.apache.org > Cc: us...@cloudstack.apache.org > Subject: 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
Re: [PR] Zonewizard [cloudstack-terraform-provider]
kiranchavala commented on PR #67: URL: https://github.com/apache/cloudstack-terraform-provider/pull/67#issuecomment-1980094048 @poddm could you please help in resolving the conflicts -- 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] Support adding templates in all zones [cloudstack-terraform-provider]
rohityadavcloud merged PR #92: URL: https://github.com/apache/cloudstack-terraform-provider/pull/92 -- 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] error retrieving ID of zone all: No match found for all: &{Count:0 Zones:[]} [cloudstack-terraform-provider]
rohityadavcloud closed issue #48: error retrieving ID of zone all: No match
found for all: &{Count:0 Zones:[]}
URL: https://github.com/apache/cloudstack-terraform-provider/issues/48
--
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] Update details if changed for an instance [cloudstack-terraform-provider]
rohityadavcloud merged PR #91: URL: https://github.com/apache/cloudstack-terraform-provider/pull/91 -- 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] details changes are not beeing applied [cloudstack-terraform-provider]
rohityadavcloud closed issue #58: details changes are not beeing applied URL: https://github.com/apache/cloudstack-terraform-provider/issues/58 -- 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] added noderootdisksize parameter [cloudstack-terraform-provider]
rohityadavcloud merged PR #90: URL: https://github.com/apache/cloudstack-terraform-provider/pull/90 -- 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] Please include "noderootdisksize" in "resource_cloudstack_kubernetes_cluster.go" [cloudstack-terraform-provider]
rohityadavcloud closed issue #41: Please include "noderootdisksize" in "resource_cloudstack_kubernetes_cluster.go" URL: https://github.com/apache/cloudstack-terraform-provider/issues/41 -- 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] Improves service offering resource [cloudstack-terraform-provider]
vishesh92 commented on code in PR #64:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/64#discussion_r1513882158
##
cloudstack/resource_cloudstack_service_offering.go:
##
@@ -42,6 +42,61 @@ func resourceCloudStackServiceOffering() *schema.Resource {
Type: schema.TypeString,
Required: true,
},
+ "cpu_number": {
+ Description: "Number of CPU cores",
+ Type:schema.TypeInt,
+ Optional:true,
+ ForceNew:true,
+ },
+ "cpu_speed": {
+ Description: "Speed of CPU in Mhz",
+ Type:schema.TypeInt,
+ Optional:true,
+ ForceNew:true,
+ },
+ "host_tags": {
+ Description: "The host tag for this service
offering",
+ Type:schema.TypeString,
+ Optional:true,
+ },
+ "limit_cpu_use": {
+ Description: "Restrict the CPU usage to
committed service offering",
+ Type:schema.TypeBool,
+ Optional:true,
+ ForceNew:true,
+ Default: false,
+ },
+ "memory": {
+ Description: "The total memory of the service
offering in MB",
+ Type:schema.TypeInt,
+ Optional:true,
+ ForceNew:true,
+ },
+ "offer_ha": {
+ Description: "The HA for the service offering",
+ Type:schema.TypeBool,
+ Optional:true,
+ ForceNew:true,
+ Default: false,
+ },
+ "storage_type": {
+ Description: "The storage type of the service
offering. Values are local and shared",
+ Type:schema.TypeString,
+ Optional:true,
+ ForceNew:true,
+ Default: "local",
Review Comment:
```suggestion
Default: "shared",
```
shared is the default for the API. Let's keep the same here.
--
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] Adding configuration resource [cloudstack-terraform-provider]
vishesh92 commented on code in PR #57:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/57#discussion_r1513890780
##
cloudstack/provider.go:
##
@@ -84,13 +84,12 @@ func Provider() terraform.ResourceProvider {
ResourcesMap: map[string]*schema.Resource{
"cloudstack_affinity_group":
resourceCloudStackAffinityGroup(),
"cloudstack_autoscale_vm_profile":
resourceCloudStackAutoScaleVMProfile(),
+ "cloudstack_configuration":
resourceCloudStackConfiguration(),
"cloudstack_disk":
resourceCloudStackDisk(),
"cloudstack_egress_firewall":
resourceCloudStackEgressFirewall(),
"cloudstack_firewall":
resourceCloudStackFirewall(),
"cloudstack_instance":
resourceCloudStackInstance(),
"cloudstack_ipaddress":
resourceCloudStackIPAddress(),
- "cloudstack_kubernetes_cluster":
resourceCloudStackKubernetesCluster(),
Review Comment:
why is it required to remove this?
--
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] Adding configuration resource [cloudstack-terraform-provider]
vishesh92 commented on code in PR #57:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/57#discussion_r1513894181
##
cloudstack/resource_cloudstack_instance.go:
##
@@ -570,7 +570,7 @@ func resourceCloudStackInstanceUpdate(d
*schema.ResourceData, meta interface{})
if d.HasChange("keypair") {
log.Printf("[DEBUG] SSH keypair changed for %s,
starting update", name)
- p :=
cs.SSH.NewResetSSHKeyForVirtualMachineParams(d.Id(), d.Get("keypair").(string))
+ p :=
cs.SSH.NewResetSSHKeyForVirtualMachineParams(d.Id())
Review Comment:
you should set the `keypair` param here as well.
--
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] Adding configuration resource [cloudstack-terraform-provider]
vishesh92 commented on code in PR #57:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/57#discussion_r1513895386
##
cloudstack/resource_cloudstack_private_gateway.go:
##
@@ -100,7 +100,6 @@ func resourceCloudStackPrivateGatewayCreate(d
*schema.ResourceData, meta interfa
d.Get("gateway").(string),
ipaddress,
d.Get("netmask").(string),
- d.Get("vlan").(string),
d.Get("vpc_id").(string),
)
Review Comment:
If vlan is available, update the params.
--
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] Adding configuration resource [cloudstack-terraform-provider]
vishesh92 commented on code in PR #57:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/57#discussion_r1513896738
##
cloudstack/resource_cloudstack_configuration.go:
##
@@ -0,0 +1,227 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package cloudstack
+
+import (
+ "fmt"
+
+ "github.com/apache/cloudstack-go/v2/cloudstack"
+ "github.com/hashicorp/terraform/helper/schema"
+)
+
+func resourceCloudStackConfiguration() *schema.Resource {
+ return &schema.Resource{
+ Create: resourceCloudStackConfigurationCreate,
+ Read: resourceCloudStackConfigurationRead,
+ Update: resourceCloudStackConfigurationUpdate,
+ Delete: resourceCloudStackConfigurationDelete,
+ Importer: &schema.ResourceImporter{
+ State: importStatePassthrough,
+ },
+
+ Schema: map[string]*schema.Schema{
+ "name": {
+ Type: schema.TypeString,
+ Required: true,
+ },
+ "accountid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "clusterid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "domainid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "imagestoreuuid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "storeid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "value": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ "zoneid": {
+ Type: schema.TypeString,
+ Optional: true,
+ },
+ // computed
+ "category": {
+ Type: schema.TypeString,
+ Computed: true,
+ },
+ "description": {
+ Type: schema.TypeString,
+ Computed: true,
+ },
+ "is_dynamic": {
+ Type: schema.TypeString,
+ Computed: true,
+ },
+ "scope": {
+ Type: schema.TypeString,
+ Computed: true,
+ },
+ },
+ }
+}
+
+func resourceCloudStackConfigurationRead(d *schema.ResourceData, meta
interface{}) error {
+ cs := meta.(*cloudstack.CloudStackClient)
+ p := cs.Configuration.NewListConfigurationsParams()
+
+ // required
+ p.SetName(d.Id())
+
+ // optional
+ if v, ok := d.GetOk("accountid"); ok {
+ p.SetAccountid(v.(string))
+ }
+ if v, ok := d.GetOk("category"); ok {
+ p.SetCategory(v.(string))
+ }
+ if v, ok := d.GetOk("clusterid"); ok {
+ p.SetClusterid(v.(string))
+ }
+ if v, ok := d.GetOk("domainid"); ok {
+ p.SetDomainid(v.(string))
+ }
+ if v, ok := d.GetOk("imagestoreuuid"); ok {
+ p.SetImagestoreuuid(v.(string))
+ }
+ if v, ok := d.GetOk("storeid"); ok {
+ p.SetStorageid(v.(string))
+ }
+ if v, ok := d.GetOk("zoneid"); ok {
+ p.SetZoneid(v.(string))
+ }
+
+ cfg, err := cs.Configuration.ListConfigurations(p)
+ if err != nil {
+ return err
+ }
+
+ f
Re: [PR] Force some param to be required [cloudstack-go]
weizhouapache commented on PR #79: URL: https://github.com/apache/cloudstack-go/pull/79#issuecomment-1980241864 good job ! @vishesh92 -- 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] Force some param to be required [cloudstack-go]
weizhouapache commented on PR #79: URL: https://github.com/apache/cloudstack-go/pull/79#issuecomment-1980244081 @vishesh92 there are some more params in @shwstppr 's PR #77 -- 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
