Open Stack

On Sat, Aug 9, 2014 at 6:29 AM, Eoghan Glynn <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]
>
> 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 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/20140811/85ff3300/attachment-0001.html>