wido opened a new pull request, #13985:
URL: https://github.com/apache/cloudstack/pull/13985
### Description
**This is a WIP / RFC to gather feedback before it is finished. Not intended
to be merged as-is.**
This proposes an opt-in Usage Reporter ("call-home") for CloudStack. The
goal is to give the project insight into how CloudStack is actually deployed in
the wild: which hypervisors, storage types, network offerings and versions are
in use, and how large environments typically are. Today we simply do not know,
which makes it hard to decide what to prioritise, what to deprecate and what to
test.
Two parts are included:
1. **Management Server side** (`UsageReporter`): periodically collects
aggregated counters and POSTs them as JSON to an endpoint of the CloudStack
project over HTTPS.
2. **Collector side** (`reporter/`): a small Python Flask/WSGI application
that validates incoming reports and stores them as JSON files on disk, one
directory per environment, with the receive timestamp as filename. Submissions
are rate limited and bounded per environment, and reports with an unexpected
structure are rejected.
### Opt-in and privacy
- Disabled by default: `usage.report.interval = 0`. An operator has to
explicitly set an interval (7 days recommended) and restart the Management
Server.
- `usage.report.uri` defaults to `https://reporting.cloudstack.org/report`
and can be pointed elsewhere. Only HTTPS is accepted; plain HTTP is refused.
- Only **aggregated** statistics are sent: counts per hypervisor type,
host/cluster types, storage pool type/provider/scope, zone network and service
providers, instance states/types, disk offering characteristics, and the
version upgrade history. No hostnames, IP addresses, account names, UUIDs of
resources, tags or any other free-form data.
- The environment is identified by a SHA-256 hash derived from the `version`
table, so reports from the same environment can be correlated over time without
identifying it.
### Open points for discussion
- Is the set of collected metrics the right one — anything missing, anything
that should not be there?
- Where and how should the collector be hosted, and who has access to the
collected reports?
- Do we need a documented retention and publication policy for the
aggregated data before this is enabled anywhere?
- The `reporter/` collector may be better off in a separate repository
rather than in the main tree.
- Documentation and tests are not written yet.
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] 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)
- [ ] build/CI
- [ ] test (unit or integration test code)
### How Has This Been Tested?
Manually against a local Management Server with `usage.report.interval` set
to a low value and the collector running locally behind HTTPS. Verified that
nothing is sent with the default configuration.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
