Open Stack

+2 from me,

More mongodb adoption (as stated) when it's questionable legally doesn't seem like a good long term strategy (I know it will/does impact yahoo adopting or using ceilometer...). Is this another one of those tactical changes that we keep on making that ends up being yet another piece of technical debt that someone will have to cleanup :-/

If we thought a little more about this strategically maybe we would end up in a better place short term *and* long term??

Sent from my really tiny device...

On Aug 9, 2014, at 8:59 AM, "Devananda van der Veen" <devananda.vdv at gmail.com<mailto:devananda.vdv at gmail.com>> wrote:


On Aug 9, 2014 4:22 AM, "Eoghan Glynn" <eglynn at redhat.com<mailto:eglynn at redhat.com>> wrote:
>
>
> Hi Folks,
>
> Dina Belova has recently landed some infra patches[1,2] to create
> an experimental mongodb-based Tempest job. This effectively just
> overrides the ceilometer storage backend config so that mongodb
> is used instead of sql-alchemy. The new job has been running
> happily for a few days so I'd like now to consider the path
> forwards with this.
>
> One of our Juno goals under the TC gap analysis was to more fully
> gate against mongodb, given that this is the storage backend
> recommended/supported by many distros. The sql-alchemy backend,
> on the other hand, is more suited for proofs of concept or small
> deployments. However up to now we've been hampered from reflecting
> that reality in the gate, due to the gate being stuck on Precise
> for a long time, as befits LTS, and the version of mongodb needed
> by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
> release (in fact it was limited to 2.0.4).
>
> So the orientation towards gating on sql-alchemy was mostly
> driven by legacy issues in the gate's usage of Precise, as
> opposed to this being considered the most logical basket in
> which to put all our testing eggs.
>
> However, we're now finally in the brave new world of Trusty :)
> So I would like to make the long-delayed change over soon.
>
> This would involve transposing the roles of sql-alchemy and
> mongodb in the gate - the mongodb variant becomes the "blessed"
> job run by default, whereas the sql-alchemy based job to
> relegated to the second tier.
>
> So my questions are:
>
>  (a) would the QA side of the house be agreeable to this switch?
>
> and:
>
>  (b) how long would the mongodb job need to be stable in this
>      experimental mode before we pull the trigger on swicthing?
>
> If the answer to (a) is yes, we can get infra patches proposed
> early next week to make the swap.
>
> Cheers,
> Eoghan
>
> [1] https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
> [2] https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z
>

My interpretation of the gap analysis [1] is merely that you have coverage, not that you switch to it and relegate the SQLAlchemy tests to second chair. I believe that's a dangerous departure from current standards. A dependency on mongodb, due to it's AGPL license, and lack of sufficient support for a non-AGPL storage back end, has consistently been raised as a blocking issue for Marconi. [2]

-Deva

[1] https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage

[2] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html is a very articulate example of this objection

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140809/abc3c4f3/attachment.html>