On Sat, Aug 9, 2014 at 6:29 AM, Eoghan Glynn <egl...@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] > > Sure, the main goal is to have full mongodb-based coverage in the gate. > > So, if the QA/infra folks are prepared to host *both* jobs, then I'd be > happy to change my request to simply: > > let's promote the mongodb-based Tempest variant to the first tier, > to run alongside the current sqlalchemy-based job > 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. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html [1] http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n238 > > Does that work for you Devananda? > > Cheers, > Eoghan > > > -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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev