Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of runseb@gmail.com designates
 74.125.82.51 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [DISCUSS] Automatic usage reporting / call-home for CloudStack
From: Sebastien Goasguen <runseb@gmail.com>
In-Reply-To: <547C6832.7090502@widodh.nl>
Date: Mon, 1 Dec 2014 08:15:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0157CDE0-C492-46D1-AC4B-25F8A84ABE06@gmail.com>
References: <547C6832.7090502@widodh.nl>
To: dev@cloudstack.apache.org


On Dec 1, 2014, at 8:08 AM, Wido den Hollander <wido@widodh.nl> wrote:

> Hello,
>=20
> 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.
>=20
> That's why I've written the Usage Reporting functionality for the
> management server which automatically sends back anonymous information
> about a CloudStack deployment.
>=20
> It's currently in the 'reporter' branch. [0]
>=20
> 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)
>=20
> This report is not complete yet, I'd like to add more information, but
> that will be Management Server information.
>=20
> 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.
>=20
> I want to discuss this new feature for CloudStack and the possible
> implications it might have.
>=20
> 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.
>=20
> 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.
>=20
> Turning it off is also just one global setting and it will never turn =
on
> again.
>=20
> 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. =46rom there analytics can be gathered on
> CloudStack deployments.
>=20
> It currently points to http://cs-report.widodh.nl/report which will =
NOT
> be the endpoint when this is merged into master.
>=20
> For 'production' I want to have
> https://report.cloudstack.apache.org/report where all reports are =
submitted.
>=20
> 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.
>=20
> Technically this wasn't that hard to implement, but the politics
> surrounding it might be the hardest part.
>=20
> What do other have to say about this? Should there be a VOTE for this
> feature to come into CloudStack? Opt-in, opt-out?
>=20

We should ask users@ as well.

I am +1 on this,=20

> Wido
>=20
> [0]:
> =
https://git-wip-us.apache.org/repos/asf?p=3Dcloudstack.git;a=3Dshortlog;h=3D=
refs/heads/reporter
> [1]:
> =
https://git-wip-us.apache.org/repos/asf?p=3Dcloudstack.git;a=3Dblob;f=3Dre=
porter/usage-report-collector.py;h=3D500a4d284b5172fd93acea08f5460cfff5520=
855;hb=3Dreporter