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

> [2] <a href="https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z">https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z</a><br>

></p>
<p dir="ltr">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] </p>

<p dir="ltr">-Deva<br></p>
<p dir="ltr">[1] <a href="https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage">https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage</a></p>
<p dir="ltr">[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html">http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html</a> is a very articulate example of this objection</p>