cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: [DISCUSS] Automatic usage reporting / call-home for CloudStack
Date Mon, 27 Jul 2015 12:46:47 GMT

On 27-07-15 11:52, Daan Hoogland wrote:
> gogogo

The PR is out there:

> On Mon, Jul 27, 2015 at 10:28 AM, Wido den Hollander <> wrote:
>> Hi,
>> It has been quite some time and this feature hasn't merged yet.
>> I created a issue for this:
>> The code is ready to merge and is in the "reporter" [0] branch on the
>> Git repo.
>> Even if the VM isn't ready, I would like to merge this feature into 4.6
>> and get a VERY CLEAR doc into the Release Notes.
>> Without Infra to send stats to, it seems like this feature is worthless,
>> but it isn't. Since we got the code running, so as soon as we get
>> online we are good.
>> Merging would just be sending a PR, before I do so, any objections?
>> Wido
>> [0]:
>> On 01-12-14 14:08, Wido den Hollander wrote:
>>> Hello,
>>> As a project we currently don't have a lot of insight information on
>>> about how CloudStack is being used. Surveys tell us a lot, but not
>>> everybody fills in the survey, so we still miss a lot of information.
>>> That's why I've written the Usage Reporting functionality for the
>>> management server which automatically sends back anonymous information
>>> about a CloudStack deployment.
>>> It's currently in the 'reporter' branch. [0]
>>> By default, every 7 days it generates a JSON document with:
>>> - Hosts (Number, version, type, hypervisor)
>>> - Clusters (Hypervisor en Management type)
>>> - Primary storage (Type and provider)
>>> - Zones (Network type and providers)
>>> - Instances (Number and types)
>>> This report is not complete yet, I'd like to add more information, but
>>> that will be Management Server information.
>>> The code on how this report is generated is obviously 100% Open Source,
>>> so end-users can always exactly see how the information was compiled.
>>> I want to discuss this new feature for CloudStack and the possible
>>> implications it might have.
>>> I'm opting for a opt-out. So every new or upgraded install to 4.6.0
>>> (master) will have this enabled. Yes, we have to be very explicit in the
>>> Release Notes that this has been added.
>>> Why? It's the small price we as a project ask for using CloudStack. We
>>> want a little bit of information on how CloudStack is being used so that
>>> we can use this to make CloudStack even better.
>>> Turning it off is also just one global setting and it will never turn on
>>> again.
>>> On the server-side there is a Python flask application [1] (found in the
>>> reporter directory) which stores all the incoming information in a
>>> ElasticSearch database. From there analytics can be gathered on
>>> CloudStack deployments.
>>> It currently points to which will NOT
>>> be the endpoint when this is merged into master.
>>> For 'production' I want to have
>>> where all reports are submitted.
>>> For every setup a unique ID is determined by hashing the first row in
>>> the 'version' table. This is the version + timestamp and that is hashed
>>> using SHA256. Using this unique ID we can track changes in deployments
>>> and see how they grow or shrink.
>>> Technically this wasn't that hard to implement, but the politics
>>> surrounding it might be the hardest part.
>>> What do other have to say about this? Should there be a VOTE for this
>>> feature to come into CloudStack? Opt-in, opt-out?
>>> Wido
>>> [0]:
>>> [1]:

View raw message