Title: Restrict the number of managed clustered file systems per compute cluster by mike-tutkowski · Pull Request #2500 · apache/cloudstack · GitHub
Open Graph Title: Restrict the number of managed clustered file systems per compute cluster by mike-tutkowski · Pull Request #2500 · apache/cloudstack
X Title: Restrict the number of managed clustered file systems per compute cluster by mike-tutkowski · Pull Request #2500 · apache/cloudstack
Description: Description For managed storage, each time a virtual disk is created, a new SR is created (when on XenServer) or a new datastore is created (when on VMware). XenServer 6.5 can support around 500 - 600 SRs per compute cluster before the creation of the next SR starts taking a fairly long time (over a minute). This is, for some admins, unacceptable and they would like a way to stop CloudStack from creating SRs once a certain admin-specified limit is reached. To be clear, though, once the SR is created, it does not suffer performance issues. VMware can support 256 datastores per compute cluster. This is a hard limit. CloudStack has never had the ability to limit the number of SRs or datastores it creates when using managed storage (the admin has needed to pay attention to this via some other process outside of CloudStack). This code aims to address the main use cases in CloudStack that can create SRs or datastores and fails the applicable operations if no more SRs or datastores can be created (based on a new cluster-scoped setting that specifies how many SRs or datastores the admin is OK with CloudStack creating). https://issues.apache.org/jira/browse/CLOUDSTACK-10336 Types of changes Breaking change (fix or feature that would cause existing functionality to change) New feature (non-breaking change which adds functionality) Bug fix (non-breaking change which fixes an issue) Enhancement (improves an existing feature and functionality) Cleanup (Code refactoring and cleanup, that may add test cases) How Has This Been Tested? This code deals with two main situations: When creating a new VM that requires managed storage When attaching a new data disk that requires managed storage to a VM In each of those situations, the code checks a new cluster-scoped setting (can be set by the admin) to see if the new SR or datastore can be created. I ran through a substantial number of manual tests to confirm that the applicable operations succeed or fail depending on if a new SR or datastore can be created. Checklist: I have read the CONTRIBUTING document. My code follows the code style of this project. My change requires a change to the documentation. I have updated the documentation accordingly. I have added tests to cover my changes. All new and existing tests passed. @blueorangutan package
Open Graph Description: Description For managed storage, each time a virtual disk is created, a new SR is created (when on XenServer) or a new datastore is created (when on VMware). XenServer 6.5 can support around 500 - ...
X Description: Description For managed storage, each time a virtual disk is created, a new SR is created (when on XenServer) or a new datastore is created (when on VMware). XenServer 6.5 can support around 500 - ...
Opengraph URL: https://github.com/apache/cloudstack/pull/2500
X: @github
Domain: github.com
| route-pattern | /:user_id/:repository/pull/:id/files(.:format) |
| route-controller | pull_requests |
| route-action | files |
| fetch-nonce | v2:0171f7c7-4678-fca6-1f4e-ffccc50c4e4e |
| current-catalog-service-hash | ae870bc5e265a340912cde392f23dad3671a0a881730ffdadd82f2f57d81641b |
| request-id | CB4C:34BFFD:2F938DC:4185C5B:6A4F13B2 |
| html-safe-nonce | bfe9d982d7e4b4e882dc7e3f55fe11ca5532fdd98df6d1dff51dbdae1143817c |
| visitor-payload | eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiJDQjRDOjM0QkZGRDoyRjkzOERDOjQxODVDNUI6NkE0RjEzQjIiLCJ2aXNpdG9yX2lkIjoiNDM3OTkwMDQ2OTMzNTQ5NTYwMiIsInJlZ2lvbl9lZGdlIjoiaWFkIiwicmVnaW9uX3JlbmRlciI6ImlhZCJ9 |
| visitor-hmac | 26d3fe15255e3f84127f786aa0e95d46e1564bf497d980a623cd2aacf576e3a3 |
| hovercard-subject-tag | pull_request:176607929 |
| github-keyboard-shortcuts | repository,pull-request-list,pull-request-conversation,pull-request-files-changed,copilot |
| google-site-verification | Apib7-x98H0j5cPqHWwSMm6dNU4GmODRoqxLiDzdx9I |
| octolytics-url | https://collector.github.com/github/collect |
| analytics-location | / |
| fb:app_id | 1401488693436528 |
| apple-itunes-app | app-id=1477376905, app-argument=https://github.com/apache/cloudstack/pull/2500/files |
| twitter:image | https://avatars.githubusercontent.com/u/3019295?s=400&v=4 |
| twitter:card | summary_large_image |
| og:image | https://avatars.githubusercontent.com/u/3019295?s=400&v=4 |
| og:image:alt | Description For managed storage, each time a virtual disk is created, a new SR is created (when on XenServer) or a new datastore is created (when on VMware). XenServer 6.5 can support around 500 - ... |
| og:site_name | GitHub |
| og:type | object |
| hostname | github.com |
| expected-hostname | github.com |
| None | b92d11c0aa4a77d54ef4af1078b6a15fb5a70a215b30c4ecf28889d5a8e656d9 |
| turbo-cache-control | no-preview |
| diff-view | unified |
| go-import | github.com/apache/cloudstack git https://github.com/apache/cloudstack.git |
| octolytics-dimension-user_id | 47359 |
| octolytics-dimension-user_login | apache |
| octolytics-dimension-repository_id | 9759448 |
| octolytics-dimension-repository_nwo | apache/cloudstack |
| octolytics-dimension-repository_public | true |
| octolytics-dimension-repository_is_fork | false |
| octolytics-dimension-repository_network_root_id | 9759448 |
| octolytics-dimension-repository_network_root_nwo | apache/cloudstack |
| turbo-body-classes | logged-out env-production page-responsive full-width |
| disable-turbo | true |
| browser-stats-url | https://api.github.com/_private/browser/stats |
| browser-errors-url | https://api.github.com/_private/browser/errors |
| release | 2b8f23afb982271f1b22258a94aede67a6b77760 |
| ui-target | full |
| theme-color | #1e2327 |
| color-scheme | light dark |
Links:
Viewport: width=device-width