<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 9, 2014 at 6:29 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><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]<br>
> > <a href="https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z" target="_blank">https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z</a><br>


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


> ><br>
><br>
> My interpretation of the gap analysis [1] is merely that you have coverage,<br>
> not that you switch to it and relegate the SQLAlchemy tests to second chair.<br>
> I believe that's a dangerous departure from current standards. A dependency<br>
> on mongodb, due to it's AGPL license, and lack of sufficient support for a<br>
> non-AGPL storage back end, has consistently been raised as a blocking issue<br>
> for Marconi. [2]<br>
<br>
</div></div>Sure, the main goal is to have full mongodb-based coverage in the gate.<br>
<br>
So, if the QA/infra folks are prepared to host *both* jobs, then I'd be<br>
happy to change my request to simply:<br>
<br>
  let's promote the mongodb-based Tempest variant to the first tier,<br>
  to run alongside the current sqlalchemy-based job<br></blockquote><div><br></div><div><br></div><div>Ignoring the question of is it ok to say: 'to run ceilometer in any sort of non-trivial deployment you must manager yet another underlying service, mongodb' I would prefer not adding an addition gate variant to all projects.  With the effort to reduce the number of gate variants we have [0] I would prefer to see just ceilometer gate on both mongodb and sqlalchemy and the main integrated gate [1] pick just one.</div>

<div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html</a></div><div>[1] <a href="http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n238">http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n238</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Does that work for you Devananda?<br>
<br>
Cheers,<br>
Eoghan<br>
<div class="im"><br>
> -Deva<br>
><br>
><br>
> [1]<br>
> <a href="https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage" target="_blank">https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage</a><br>
><br>
> [2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html</a><br>
> is a very articulate example of this objection<br>
<br>
</div><div class=""><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>