Re: [I] network_id remains empty after creating IP address resource [cloudstack-terraform-provider]
vishesh92 commented on issue #32: URL: https://github.com/apache/cloudstack-terraform-provider/issues/32#issuecomment-1996877510 @kohrar I did a few tests. When I associate an ip_address with a network id, associated network id is set in response. But when I associate it with a vpc id, associated network id is not set. I am adding a check in the provider to not allow both vpc_id and network_id in this PR - https://github.com/apache/cloudstack-terraform-provider/pull/99/files -- 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] Restore methods with optional params for 4.19 compatability [cloudstack-go]
weizhouapache commented on PR #80: URL: https://github.com/apache/cloudstack-go/pull/80#issuecomment-1997179814 thanks @vishesh92 it looks terraform will not work https://github.com/apache/cloudstack-terraform-provider/blob/d524e07e497b44caf3252fe9ffeefbc6bd138570/cloudstack/resource_cloudstack_kubernetes_cluster.go#L165 ``` // Create a new parameter struct p := cs.Kubernetes.NewCreateKubernetesClusterParams(name, kubernetesVersionID, name, serviceOfferingID, size, zoneID) ``` -- 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] Restore methods with optional params for 4.19 compatability [cloudstack-go]
shwstppr merged PR #80: URL: https://github.com/apache/cloudstack-go/pull/80 -- 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] Fail when both network_id & vpc_id are set in ipaddress [cloudstack-terraform-provider]
vishesh92 merged PR #99: URL: https://github.com/apache/cloudstack-terraform-provider/pull/99 -- 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]
vishesh92 closed issue #32: network_id remains empty after creating IP address resource URL: https://github.com/apache/cloudstack-terraform-provider/issues/32 -- 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 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 both and 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 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 ^^^ -
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 m
