Re: [Discussion] Versioning
Hello Rohit, > I think we need to break out the topics and discuss them separately. Personally I wouldn't be able to work & vote this weekend, but I can try to participate during work days next week. We can vote again if required, but I think voting isn't required if consensus is achieved. These topics are intertwined, I believe that discussing them separately will hinder the discussions. Also, as we are changing a process that has been followed for many years, voting is an important step to formalize the changes. > On #1: I don't think we follow semver [1] strictly anymore. Our versioning scheme is currently A.B.C.D (where D is for security, C is maintenance/path; but B is considered a major release, A relates to API backward compatibility). To give some historical context - the original authors started with semver because they needed something to base versioning scheme on and followed it b/w 4.0 and 4.5; then starting security releases I think around 2016-2017 we introduced the security patch created our own versioning scheme & DB upgrade paths mechanisms around it. With LTS [1] guidelines adopted a few years back, we created a way for us to support new hypervisor support delivered in maintenance/minor releases which often have DB changes (adding guest os mappings, capabilities etc.) and any core infra blockers. For the most part - for marketing purposes, in events, conferences, announcements etc we consider "A.B" as a major ACS release (for example, we say 4.21 is the next major LTS release...), and we refer to A.B.C as a maintenance/minor release. (for example 4.20.1.0, or 4.19.3.0). We do not follow strictly semver, as per the link you mentioned, however, the same link specifies that the only change is the following: --- ... where NON-SECURITY PATCH is incremented for all bug fix releases except those addressing a CVE. The SECURITY PATCH is only incremented for security releases that fix one or more CVEs. --- The rest should be semver. Also regarding the page you mentioned, it specifies that the MAJOR would be our 4, as it is the first number; therefore, we cannot consider "A.B" the MAJOR, as it is a MINOR. Again, the community has not been following its own guidelines and it seems that there are confusions regarding the versioning. **This is why we must discuss and solidify our process**. > My view is, it's not in our community's best interest to introduce severely disruptive changes (APIs for example) as we've built a momentum of users, sub-projects and sister-projects that depend on CloudStack (APIs). So, if we can accept that there will be never a major release (from a semver PoV) disrupting the APIs, we can drop the "4." and call the next set of releases 22, 23 etc. forking our version of "semver" even further. If that's the extent of the proposal, I'm supportive of that. > On a pedantic note, the proposed voting thread's subject is about versioning process but it suggest that the proposer "will start another thread regarding our version naming" - making it harder for community to vote on something that's not well defined or proposed. It seems that two different topics are being mixed here, on one hand we have the versiong process, on the other we have the naming. They do go hand in hand, but they can be discussed separately, I see that you have an interest in changing our version naming, I do not oppose that; however, I'm interested in the versioning process, this is what this thread is about and why I want to create a new thread for version naming discussion. Regarding the disruptive changes, we have already been introducing these types of changes, but as we have not been following a proper process, these changes have been made to the MINOR release, and what is worse, a lot of times users are not informed of such changes in advance. Here are a few example of disruptive changes: - https://github.com/apache/cloudstack/pull/9518. Changed the default connection pool library. This was not communicated to the community and we have caught problems caused by this change, where we had to revert to the old library. - https://github.com/apache/cloudstack/pull/7131. Updated the log library. This change was announced in the MLs (see https://lists.apache.org/thread/wnh2d0r3dyphzmc0c6rytj2mbd21z2gs) and was explicit on release notes for example, but I still feel like we could've communicated a bit better about the change, for example notifying the deprecation of log4j 1.29 in the previous version. In any case, this is a disruptive change that was not made in a MAJOR version as defined by semver. - https://github.com/apache/cloudstack/pull/8609. JRE Upgrade, removed support for EL7. Again, this was communicated in the release notes, but as far as I know we did not notify the users of the deprecation EL7 in the previous versions. > On #2: we already have a deprecation policy [1] which was led by Rafael and we've used it alrea
[PR] Update network offering usage record (inline with the response) [cloudstack-documentation]
sureshanaparti opened a new pull request, #505:
URL: https://github.com/apache/cloudstack-documentation/pull/505
Update network offering usage record (inline with the response).
```
(usageenv) 🐱 > list usagerecords startdate=2025-05-11 enddate=2025-05-13
type=13 usageid=bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77
{
"count": 110,
"usagerecord": [
{
"account": "admin",
"accountid": "a5f9d055-1ea1-11f0-8a38-1e00b50002f5",
"description": "Network offering
DefaultIsolatedNetworkOfferingWithSourceNatService
(bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77) usage for VM testvm01
(0c74f18a-2f1b-4bbe-b17e-bd16f4e55d86) ",
"domain": "ROOT",
"domainid": "676c3952-1ea1-11f0-8a38-1e00b50002f5",
"domainpath": "/",
"enddate": "2025-05-11'T'00:59:59+00:00",
"isdefault": true,
"offeringid": "bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77",
"rawusage": "1",
"startdate": "2025-05-11'T'00:00:00+00:00",
"tags": [],
"usage": "1 Hrs",
"usagetype": 13,
"virtualmachineid": "0c74f18a-2f1b-4bbe-b17e-bd16f4e55d86",
"zoneid": "cd989e1a-0024-439d-8164-7db39e046c6f"
},
{
"account": "admin",
"accountid": "a5f9d055-1ea1-11f0-8a38-1e00b50002f5",
"description": "Network offering
DefaultIsolatedNetworkOfferingWithSourceNatService
(bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77) usage for VM testvm02
(617f7798-7a5f-4eb7-9d13-40a3eab641df) ",
"domain": "ROOT",
"domainid": "676c3952-1ea1-11f0-8a38-1e00b50002f5",
"domainpath": "/",
"enddate": "2025-05-11'T'00:59:59+00:00",
"isdefault": true,
"offeringid": "bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77",
"rawusage": "1",
"startdate": "2025-05-11'T'00:00:00+00:00",
"tags": [],
"usage": "1 Hrs",
"usagetype": 13,
"virtualmachineid": "617f7798-7a5f-4eb7-9d13-40a3eab641df",
"zoneid": "cd989e1a-0024-439d-8164-7db39e046c6f"
},
{
"account": "admin",
"accountid": "a5f9d055-1ea1-11f0-8a38-1e00b50002f5",
"description": "Network offering
DefaultIsolatedNetworkOfferingWithSourceNatService
(bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77) usage for VM testvm01
(0c74f18a-2f1b-4bbe-b17e-bd16f4e55d86) ",
"domain": "ROOT",
"domainid": "676c3952-1ea1-11f0-8a38-1e00b50002f5",
"domainpath": "/",
"enddate": "2025-05-11'T'01:59:59+00:00",
"isdefault": true,
"offeringid": "bfcb52bf-cb33-4c7d-bd9d-9b4b57d65a77",
"rawusage": "1",
"startdate": "2025-05-11'T'01:00:00+00:00",
"tags": [],
"usage": "1 Hrs",
"usagetype": 13,
"virtualmachineid": "0c74f18a-2f1b-4bbe-b17e-bd16f4e55d86",
"zoneid": "cd989e1a-0024-439d-8164-7db39e046c6f"
},
...
```
--
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 network offering usage record (inline with the response) [cloudstack-documentation]
sureshanaparti commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875647076 @blueorangutan docbuild -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
blueorangutan commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875655160 QA-Doc build preview: https://qa.cloudstack.cloud/builds/docs-build/pr/505. (QA-JID 340) -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
sureshanaparti commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875659081 @blueorangutan docbuild -- 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 usage types in the docs [cloudstack-documentation]
sureshanaparti commented on PR #504: URL: https://github.com/apache/cloudstack-documentation/pull/504#issuecomment-2875662632 @rajujith Update the usage types (still the record formats for these to be updated) -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
blueorangutan commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875651849 @sureshanaparti a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
blueorangutan commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875691766 QA-Doc build preview: https://qa.cloudstack.cloud/builds/docs-build/pr/505. (QA-JID 341) -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
blueorangutan commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875688239 @sureshanaparti a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. -- 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 network offering usage record (inline with the response) [cloudstack-documentation]
sureshanaparti commented on PR #505: URL: https://github.com/apache/cloudstack-documentation/pull/505#issuecomment-2875686274 @blueorangutan docbuild -- 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] Storage Access Groups documentation [cloudstack-documentation]
sureshanaparti commented on code in PR #503: URL: https://github.com/apache/cloudstack-documentation/pull/503#discussion_r2086363440 ## source/adminguide/storage.rst: ## @@ -252,6 +252,38 @@ same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same. +Storage Access Groups +~ + +When a primary storage is added in CloudStack, either at the Zone or Cluster scope, +it gets connected to all the hosts within that scope. Using Storage Access Groups, +this behavior can be controlled by defining groups on both primary storage and hosts, +ensuring connections are established only within those groups. When a Storage Access +Group is set on a primary storage (a text string attribute similar to tag), +and the same group is assigned to a host, the primary storage will connect only to that host. +A Storage Access Group can also be applied at the Cluster, Pod, or Zone level, allowing +all hosts in that entity to inherit the group automatically. + +For example, if there are 50 hosts across 10 clusters, with 5 hosts per cluster, +and a zone-wide primary storage is added, it will connect to all 50 hosts. If the +operator wants to limit the connection to a few hosts in just the first 2 clusters, +Storage Access Groups can be set on the primary storage and those specific hosts — +or directly on the two clusters to achieve the same effect. + +Adding Storage Access Group on a primary storage. + +|adding-storage-access-group-on-primary-storage.png| + +Adding Storage Access Group on a host. Similarly it can be applied Cluster/Pod/Zone. + +|adding-storage-access-group-on-host.png| + +A primary storage with a Storage Access Group will connect only to hosts that have the +same Storage Access Group. A storage pool without a Storage Access Group will connect to all hosts, +including those with or without any Storage Access Group. + +Note: Storage Access Groups are not applicable for local primary storages. Currently this is tested with NFS +and Dell Powerflex storages. Review Comment: ```suggestion and Dell PowerFlex storages. ``` -- 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
[PR] Update usage types in the docs [cloudstack-documentation]
sureshanaparti opened a new pull request, #504:
URL: https://github.com/apache/cloudstack-documentation/pull/504
This PR updates/sync the usage types in docs with the API response and code.
Current doc:
https://docs.cloudstack.apache.org/en/latest/adminguide/usage.html#usage-types.
list usagetypes API response =>
```
(usageenv) 🐱 > list usagetypes
{
"count": 25,
"usagetype": [
{
"description": "Running Vm Usage",
"usagetypeid": 1
},
{
"description": "Allocated Vm Usage",
"usagetypeid": 2
},
{
"description": "IP Address Usage",
"usagetypeid": 3
},
{
"description": "Network Usage (Bytes Sent)",
"usagetypeid": 4
},
{
"description": "Network Usage (Bytes Received)",
"usagetypeid": 5
},
{
"description": "Volume Usage",
"usagetypeid": 6
},
{
"description": "Template Usage",
"usagetypeid": 7
},
{
"description": "ISO Usage",
"usagetypeid": 8
},
{
"description": "Snapshot Usage",
"usagetypeid": 9
},
{
"description": "Security Group Usage",
"usagetypeid": 10
},
{
"description": "Load Balancer Usage",
"usagetypeid": 11
},
{
"description": "Port Forwarding Usage",
"usagetypeid": 12
},
{
"description": "Network Offering Usage",
"usagetypeid": 13
},
{
"description": "VPN users usage",
"usagetypeid": 14
},
{
"description": "VM Disk usage(I/O Read)",
"usagetypeid": 21
},
{
"description": "VM Disk usage(I/O Write)",
"usagetypeid": 22
},
{
"description": "VM Disk usage(Bytes Read)",
"usagetypeid": 23
},
{
"description": "VM Disk usage(Bytes Write)",
"usagetypeid": 24
},
{
"description": "VM Snapshot storage usage",
"usagetypeid": 25
},
{
"description": "Volume on secondary storage usage",
"usagetypeid": 26
},
{
"description": "VM Snapshot on primary storage usage",
"usagetypeid": 27
},
{
"description": "Backup storage usage",
"usagetypeid": 28
},
{
"description": "Bucket storage usage",
"usagetypeid": 29
},
{
"description": "Network usage",
"usagetypeid": 30
},
{
"description": "VPC usage",
"usagetypeid": 31
}
]
}
(usageenv) 🐱 >
```
code =>
https://github.com/apache/cloudstack/blob/39c5641cbe674b19bc77082b850565f634a7cb84/api/src/main/java/org/apache/cloudstack/usage/UsageTypes.java#L24-L50
--
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 usage types in the docs [cloudstack-documentation]
sureshanaparti commented on PR #504: URL: https://github.com/apache/cloudstack-documentation/pull/504#issuecomment-2875603420 @blueorangutan docbuild -- 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 usage types in the docs [cloudstack-documentation]
blueorangutan commented on PR #504: URL: https://github.com/apache/cloudstack-documentation/pull/504#issuecomment-2875609874 QA-Doc build preview: https://qa.cloudstack.cloud/builds/docs-build/pr/504. (QA-JID 339) -- 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 usage types in the docs [cloudstack-documentation]
blueorangutan commented on PR #504: URL: https://github.com/apache/cloudstack-documentation/pull/504#issuecomment-2875607106 @sureshanaparti a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. -- 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 XenServer supported versions [cloudstack-documentation]
DaanHoogland merged PR #502: URL: https://github.com/apache/cloudstack-documentation/pull/502 -- 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: [Discussion] Versioning
I've made my position clear, if there's no scope for further discussion I'll add my vote. Thanks. From: João Jandre Sent: Tuesday, May 13, 2025 19:08 To: dev@cloudstack.apache.org Subject: Re: [Discussion] Versioning Hello Rohit, > I think we need to break out the topics and discuss them separately. Personally I wouldn't be able to work & vote this weekend, but I can try to participate during work days next week. We can vote again if required, but I think voting isn't required if consensus is achieved. These topics are intertwined, I believe that discussing them separately will hinder the discussions. Also, as we are changing a process that has been followed for many years, voting is an important step to formalize the changes. > On #1: I don't think we follow semver [1] strictly anymore. Our versioning scheme is currently A.B.C.D (where D is for security, C is maintenance/path; but B is considered a major release, A relates to API backward compatibility). To give some historical context - the original authors started with semver because they needed something to base versioning scheme on and followed it b/w 4.0 and 4.5; then starting security releases I think around 2016-2017 we introduced the security patch created our own versioning scheme & DB upgrade paths mechanisms around it. With LTS [1] guidelines adopted a few years back, we created a way for us to support new hypervisor support delivered in maintenance/minor releases which often have DB changes (adding guest os mappings, capabilities etc.) and any core infra blockers. For the most part - for marketing purposes, in events, conferences, announcements etc we consider "A.B" as a major ACS release (for example, we say 4.21 is the next major LTS release...), and we refer to A.B.C as a maintenance/minor release. (for example 4.20.1.0, or 4.19.3.0). We do not follow strictly semver, as per the link you mentioned, however, the same link specifies that the only change is the following: --- ... where NON-SECURITY PATCH is incremented for all bug fix releases except those addressing a CVE. The SECURITY PATCH is only incremented for security releases that fix one or more CVEs. --- The rest should be semver. Also regarding the page you mentioned, it specifies that the MAJOR would be our 4, as it is the first number; therefore, we cannot consider "A.B" the MAJOR, as it is a MINOR. Again, the community has not been following its own guidelines and it seems that there are confusions regarding the versioning. **This is why we must discuss and solidify our process**. > My view is, it's not in our community's best interest to introduce severely disruptive changes (APIs for example) as we've built a momentum of users, sub-projects and sister-projects that depend on CloudStack (APIs). So, if we can accept that there will be never a major release (from a semver PoV) disrupting the APIs, we can drop the "4." and call the next set of releases 22, 23 etc. forking our version of "semver" even further. If that's the extent of the proposal, I'm supportive of that. > On a pedantic note, the proposed voting thread's subject is about versioning process but it suggest that the proposer "will start another thread regarding our version naming" - making it harder for community to vote on something that's not well defined or proposed. It seems that two different topics are being mixed here, on one hand we have the versiong process, on the other we have the naming. They do go hand in hand, but they can be discussed separately, I see that you have an interest in changing our version naming, I do not oppose that; however, I'm interested in the versioning process, this is what this thread is about and why I want to create a new thread for version naming discussion. Regarding the disruptive changes, we have already been introducing these types of changes, but as we have not been following a proper process, these changes have been made to the MINOR release, and what is worse, a lot of times users are not informed of such changes in advance. Here are a few example of disruptive changes: - https://github.com/apache/cloudstack/pull/9518. Changed the default connection pool library. This was not communicated to the community and we have caught problems caused by this change, where we had to revert to the old library. - https://github.com/apache/cloudstack/pull/7131. Updated the log library. This change was announced in the MLs (see https://lists.apache.org/thread/wnh2d0r3dyphzmc0c6rytj2mbd21z2gs) and was explicit on release notes for example, but I still feel like we could've communicated a bit better about the change, for example notifying the deprecation of log4j 1.29 in the previous version. In any case, this is a disruptive change that was not made in a MAJOR version as defined by semver. - https://github.com/apache/cloudstack/pull/8609. JRE Upgrade, removed support for EL7. Again, this was communicated in the release notes, but as far
