+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....@gmail.com<mailto:devananda....@gmail.com>> wrote:

On Aug 9, 2014 4:22 AM, "Eoghan Glynn" 
<egl...@redhat.com<mailto: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]



[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 mailing list

Reply via email to