[I] Improvement request - Support the following resource creation via terraform [cloudstack-terraform-provider]
kiranchavala opened a new issue, #82: URL: https://github.com/apache/cloudstack-terraform-provider/issues/82 ISSUE TYPE Improvement request SUMMARY Improvement request - Support the following resource creation via terraform The following resource creations are not available via terraform cloudstack provider 1. Creation of roles by terraform 2. Creation of projects 3. Creation of Buckets and object storage 4. Creation of snapshots /templates from volume 5. Creation of user data 6. Creation of primary storage 7. Creation of secondary storage 8. Creation of pods 9. Creation of clusters 10. Creation of hosts 11. Creation of iso 12. Creation of instance snapshots The creation of the resources will be helpful to the end users -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PROPOSE] RM for 4.19.1.0
Thanks for volunteering Suresh. Regards, Harikrishna From: Suresh Anaparti Date: Monday, 12 February 2024 at 5:20 PM To: dev@cloudstack.apache.org , us...@cloudstack.apache.org Subject: [PROPOSE] RM for 4.19.1.0 Hi All, CloudStack 4.19.0.0 is the latest LTS release. There are already some open issues [1] and pull requests [2] targeted for 4.19.1.0 [3] release. I'd like to propose and put myself forward as the release manager for 4.19.1.0 if no objections there. Please ping me (@sureshanaparti) on GitHub, in case you want to include any Issue/PR in 4.19.1.0. I propose to have a window of at least 8 weeks (2 months), which allows the community / users to test, use 4.19.0.0 and report any issues. We can aim to cut RC1 in Q2 2024 (maybe, sometime in May-2024). I'll propose the timeline details soon. I hope to have your support. Please let me know if you have any thoughts/comments. [1] https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.19.1.0 [2] https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.19.1.0+is%3Aopen [3] https://github.com/apache/cloudstack/milestone/31 Regards, Suresh
Re: [PROPOSE] RM for 4.19.1.0
Great. Go ahead Suresh ! -Wei On Mon, 12 Feb 2024 at 12:50, Suresh Anaparti wrote: > Hi All, > > CloudStack 4.19.0.0 is the latest LTS release. There are already some open > issues [1] and pull requests [2] targeted for 4.19.1.0 [3] release. > > I'd like to propose and put myself forward as the release manager for > 4.19.1.0 if no objections there. Please ping me (@sureshanaparti) on > GitHub, in case you want to include any Issue/PR in 4.19.1.0. > > I propose to have a window of at least 8 weeks (2 months), which allows > the community / users to test, use 4.19.0.0 and report any issues. We can > aim to cut RC1 in Q2 2024 (maybe, sometime in May-2024). I'll propose the > timeline details soon. I hope to have your support. > > Please let me know if you have any thoughts/comments. > > [1] > https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.19.1.0 > [2] > https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.19.1.0+is%3Aopen > [3] https://github.com/apache/cloudstack/milestone/31 > > > Regards, > Suresh > > > >
[DISCUSS] Closing issues & PR after a certain time
Hi everyone, I was going through the issues and PRs, and I noticed that a lot of them are really old and some of them are waiting for the original author to reply. I wanted to discuss if we should add a github action (https://github.com/marketplace/actions/close-stale-issues) for auto closing the issues and PRs after a certain time. >From the github actions' documentation, this is how it works: * Add a label "Stale" on issues and pull requests after 60 days of inactivity and comment on them * Close the stale issues and pull requests after 7 days of inactivity * If an update/comment occur on stale issues or pull requests, the stale label will be removed and the timer will restart Instead of using the defaults, I would like to: * mark the issue/PR stale after 90 days * close the stale issue/PR after 30 days Let me know if this sounds good. I will create the PR to set this up. Regards, Vishesh
Re: [PROPOSAL] version naming : drop the 4.
Daan, As we still plan to introduce disruptive changes (in a cautious and structured way) in the major versions, all my concerns are met; I do not have further technical reasons to keep the "4.". Best regards, Daniel Salvador (gutoveronezi) On 2/12/24 11:55, Daan Hoogland wrote: bump, @Daniel Salvador is there any technical reason to keep the 4? any reason why there must be a 5 instead of a 21, 22 or 23? We are maintaining 4 number semantic versioning for no reason, as I see it. On Tue, Jan 30, 2024 at 12:02 PM Daan Hoogland wrote: Daniel, "technical" reasons for dropping the 4 are all in the field of social engineering. In practice (as I think Wei also described) we are already treating the "minor" version number as major version. Since 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but never enough reason and or commitment to make it real. We could argue about it a lot. so ¨¨¨ The main point is: *we have to understand the technical reasons for the proposal and what we expect from it before deciding anything. ¨¨¨ The most important point is that we expect that people understand that we treat the number that now seems to be "minor" as major release numbers. On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU wrote: Hi Daniel, If we are discussing 5.0, I would have the same concern as you. What we are discussing is dropping 4.x. The fact is, we will never release 5.0 (anyone disagree ?) In this case, the major version 4.x becomes useless. If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better. IMHO due to the similar reason, the Java version has been changed from 1.x to java 1.7/1.8 (=java 7/8) then to java 11/14/17. of course there will be some issues if semantic changes, I think it is under control. Regarding the compatibility, I think we can change the APIs gradually. I noticed the following recently when I tested VR upgrade to debian12/python3 root@r-431-VM:~# python Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. import cgi :1: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 For the API changes you mentioned, we could try the similar - in version X, add new APIs, mark the old APIs as deprecated - tell users the old APIs will be removed in version Y, please use new APIs instead. - in version Y, remove the old APIs. This can be done in each major/minor release. No need to wait for 5.0. -Wei On Fri, 26 Jan 2024 at 18:51, Guto Veronezi wrote: Exactly, so you understand now why we must discuss what we intend. Although, incompatibilities are needed sometimes so we can evolve, leaving old ways and deprecated technologies and techniques in the past. *The main point is: *we have to understand the technical reasons for the proposal and what we expect from it before deciding anything. Best regards, Daniel Salvador (gutoveronezi) -- Daan
Re: [DISCUSS] Closing issues & PR after a certain time
Good idea Vishesh +1 for using Githubactions Regards Kiran From: Vishesh Jindal Date: Tuesday, 13 February 2024 at 6:33 PM To: dev@cloudstack.apache.org Subject: [DISCUSS] Closing issues & PR after a certain time Hi everyone, I was going through the issues and PRs, and I noticed that a lot of them are really old and some of them are waiting for the original author to reply. I wanted to discuss if we should add a github action (https://github.com/marketplace/actions/close-stale-issues) for auto closing the issues and PRs after a certain time. From the github actions' documentation, this is how it works: * Add a label "Stale" on issues and pull requests after 60 days of inactivity and comment on them * Close the stale issues and pull requests after 7 days of inactivity * If an update/comment occur on stale issues or pull requests, the stale label will be removed and the timer will restart Instead of using the defaults, I would like to: * mark the issue/PR stale after 90 days * close the stale issue/PR after 30 days Let me know if this sounds good. I will create the PR to set this up. Regards, Vishesh
