Re: [I] v2.15.0 breaking change regarding displayText handling for CreateNetwork [cloudstack-go]
shwstppr closed issue #70: v2.15.0 breaking change regarding displayText handling for CreateNetwork URL: https://github.com/apache/cloudstack-go/issues/70 -- 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-1999201665 Closing this based on recent changes and provision for forcing params to be required in #79 @hrak please reopen if we need further work. -- 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
[DISCUSS] Define a release schedule for the project
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.
Re: [PROPOSE] RM for Cloudstack Terraform Provider
All, Kiran is release manager for the next Terraform provider release (v0.5.0) but isn't a committer to have commit privileges to the upstream repo (something PMC can help into?). To assist him, I've created a pre-RC (alpha) build for testing purposes and we encourage users to test and report regressions/bugs. The binaries are here: https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre For some reason, Terraform registry isn't picking up the Github release from the 'cloudstack' org which is used because of Terraform registry's strict repo naming convention - https://registry.terraform.io/providers/cloudstack/cloudstack/latest (which should pick release information from https://github.com/cloudstack/terraform-provider-cloudstack/releases/tag/v0.5.0-pre). I've logged a ticket with Hashicorp to look into the resync/sync issue. In the meantime, users can use the following alpha/pre-rc builds for testing from: https://registry.terraform.io/providers/shapeblue/cloudstack/latest or, binaries from: https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre Users are welcome to report any regressions or issues here: https://github.com/apache/cloudstack-terraform-provider/issues Thanks and regards, Rohit & Kiran From: Kiran Chavala Sent: Monday, March 4, 2024 17:29 To: us...@cloudstack.apache.org ; dev@cloudstack.apache.org Subject: [PROPOSE] RM for Cloudstack Terraform Provider Hi All, Greetings I'd like to propose and put myself forward as the release manager for v0.5.0 release of cloudstack-terraform-provider(https://github.com/apache/cloudstack-terraform-provider) if no objections are there. Since the last release of the cloudstack-terraform-provider (v0.4.0) was in 2022. I am proposing to have the v0.5.0 as a quicker release. I am also proposing the keep the scope of v0.5 release minimal and it should only contain minor improvements and bug fixes Regarding timeline for the v0.5.0 release, I am targeting it by March 25th 2024. We can have a alpha release of v0.5.0 by March 18th 2024 which allows the community users to test and report any issues. After the v0.5 release we can spend some more time on adding new features and improvements to the cloudstack-terraform-provider and do a proper release of v0.6.0 in the coming months Please ping me (@kiranchavala) on GitHub, in case you want to include any Issue/PR in the v0.5.0 release. Please let me know if you have any thoughts/comments. [1] https://github.com/apache/cloudstack-terraform-provider/compare/v0.4.0...main [2] https://github.com/apache/cloudstack-terraform-provider/milestone/2 [3] https://github.com/apache/cloudstack-terraform-provider/issues Regards Kiran
Re: [PR] Update SDKs [cloudstack-terraform-provider]
fabiomatavelli commented on PR #71: URL: https://github.com/apache/cloudstack-terraform-provider/pull/71#issuecomment-2000341643 @CodeBleu I was looking into migrating directly to the terraform plugin framework and it will require a huge effort for that. It will be not as simple as migrating from v1 to v2. So my proposal is to continue the migration to sdkv2 to, at least, have a more recent version of the SDK, then start working on the migration to the plugin framework. I've already implemented some new things in my contribution, like muxing the provider and the terraform plugin testing in tests, so then it will be easier to migrate to the plugin framework. -- 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 SDKs [cloudstack-terraform-provider]
fabiomatavelli commented on PR #71: URL: https://github.com/apache/cloudstack-terraform-provider/pull/71#issuecomment-2000343098 @vishesh92 @rohityadavcloud I've added another matrix to the acceptance test so multiple versions of terraform can be tested. -- 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]
kohrar commented on issue #32:
URL:
https://github.com/apache/cloudstack-terraform-provider/issues/32#issuecomment-2000422662
@vishesh92 I don't think that's a valid solution. There are cases where I
need to specify both VPC and network ID. For instance, when I need to assign a
public IP address to a specific network within a specific VPC.
Not specifying both results in an error. Here's an example:
```
│ Error: Error associating a new IP address: Undefined error:
{"errorcode":431,"errortext":"Can't assign ip to the network directly when
network belongs to VPC.Specify vpcId to associate ip address to VPC"}
│
│ with cloudstack_ipaddress.test_public_ip,
│ on guacamole.tf line 151, in resource "cloudstack_ipaddress"
"test_public_ip":
│ 151: resource "cloudstack_ipaddress" "test_public_ip" {
│
```
This is what I'm using:
```
resource "cloudstack_ipaddress" "test_public_ip" {
# vpc_id = "${cloudstack_vpc.default.id}"
network_id = "${cloudstack_network.guacamole-net.id}"
zone = "zone1"
project = "${var.cloudstack_project_id}"
}
```
--
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]
kohrar commented on issue #32: URL: https://github.com/apache/cloudstack-terraform-provider/issues/32#issuecomment-2000433572 Perhaps I'm misunderstanding how public IPs are assigned to VPC and networks. I don't actually need to specify the network if I'm using VPCs. The above example would work if I specified the VPC only as the network_id isn't necessary. -- 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 SDKs [cloudstack-terraform-provider]
CodeBleu commented on PR #71: URL: https://github.com/apache/cloudstack-terraform-provider/pull/71#issuecomment-2000607396 > @CodeBleu I was looking into migrating directly to the terraform plugin framework and it will require a huge effort for that. It will be not as simple as migrating from v1 to v2. So my proposal is to continue the migration to sdkv2 to, at least, have a more recent version of the SDK, then start working on the migration to the plugin framework. > > I've already implemented some new things in my contribution, like muxing the provider and the terraform plugin testing in tests, so then it will be easier to migrate to the plugin framework. @fabiomatavelli TF Plugin be a v0.7.0 milestone? -- 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
