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
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: [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: [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: [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: [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
[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: [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
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: [VOTE] next version 20 instead of 4.20
Joao, Could you start a separate [DISCUSS] thread, this is because your proposal is important in the context of future of ACS releases, but different from what this voting thread is about. There are no bylaw(s) on how many releases should be done in a year or have them done in a certain way; we have adopted a community-agreed guideline to have 1-2 major releases a year to ship new features to users (some find this faster; some find this slower still). I think there is scope of improving those guidelines. However, any committer or PMC (or even a contributor with committer/PMC support) should be able to volunteer and help lead a release as its release manager. The current development and release model has over the years seen deprecation and removal of features and components, such as API components (awsapi), (legacy) UI and old/unmaintained plugins. This is usually done over a course of time and releases with some support building and documentation/advisory, to allow feedback from the community. For deprecating justified areas and reasonable components of CloudStack, we can still do it without a new release model. I believe the imporant thing is to iterate a proposal that would be generally accepted and benefial for the larger community, and generaly not breaking CloudStack's userspace to the effect that it breaks users' automation, integration, systems and tooling that are built on top of CloudStack. Regards. From: João Jandre Paraquetti Sent: Thursday, March 14, 2024 23:49 To: dev@cloudstack.apache.org Subject: Re: [VOTE] next version 20 instead of 4.20 Hi all, I know that this discussion has cooled off, but I think it's still extremely relevant for the future of ACS. 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. On 3/6/24 07:11, Giles Sirett wrote: > IMO - they are two different subjects. > Everybody hopes that we'd never break API compatibility, but there may be a > situation at some point in the future where it may be required and we > fundamentally cant take a decision now that limits what the community may > want to do in 10 years time. Irrespective of what numbering scheme is being > used, that would still be a massive decision to make *at the time* and I'd > expect a vibrant debate on doing so > > > Yes, semantic is a well know agreed standard: giving consistency across lots > of different software - but there is absolutely nothing to say that > CloudStack HAS to stick to that convention (arguably, by removing the "4." , > we're coming away from that standard anyway) Lots of software doesn’t use > semantic release versioning at all. > > As long as we have a consistent versioning scheme and are clear about it - it > doesn’t matter what scheme we use IMO > > As Paul says the "X" in X.Y.Z is usually used as a simple way to warn of > API disruptive changes - but that warning can be given in other ways (in > documentation , a compatibility matrix, etc) *If* it ever happened, we would > be using the first number for bothand > > > > Kind Regards > Giles > > > > > -Original Message- > From: Rohit Yadav > Sent: Wednesday, March 6, 2024 4:54 AM > To: dev@cloudstack.apache.org > Subject: 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
