Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Joe Gordon]

On Mon, Aug 11, 2014 at 3:53 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> On Mon, Aug 11, 2014 at 3:27 PM, Joe Gordon  wrote:
> >
> >
> >
> > On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn  wrote:
> >>
> >>
> >>
> >> > 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.
> >>
> >> Just checking to see that I fully understand what you mean there, Joe.
> >>
> >> So would we:
> >>
> >>  (a) add a new integrated-gate-ceilometer project-template to [1],
> >>  in the style of integrated-gate-neutron or integrated-gate-sahara,
> >>  which would replicate the main integrated-gate template but with
> >>  the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)
> >>
> >> or:
> >>
> >>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from
> >>  the experimental column[2] in the openstack-ceilometer project,
> >>  to the gate column on that project
> >>
> >> or:
> >>
> >>  (c) something else
> >>
> >> Please excuse the ignorance of gate mechanics inherent in that question.
> >
> >
> >
> > Correct, AFAIK (a) or (b) would be sufficient.
> >
> > There is another option, which is make the mongodb version the default in
> > integrated-gate and only run SQLA on ceilometer.
> >
>
> Joe,
>
> I believe this last option is equivalent to making mongodb the
> recommended implementation by virtue of suddenly being the most tested
> implementation. I would prefer not to see that.
>

Agreed, I included this option for completeness.


>
> Eoghan,
>
> IIUC (and I am not an infra expert) I would suggest (b) since this
> keeps the mongo tests within the ceilometer project only, which I
> think is fine from a "what we test is what we recommend" standpoint.
>
> Also, if there is a situation where a change in Nova passes with
> ceilometer+mysql and thus lands in Nova, but fails with
> ceilometer+mongodb, yes, that would break the ceilometer project's
> gate (but not the integrated gate). It would also indicate a
> substantial abstraction violation within ceilometer. I have proposed
> exactly this model for Ironic's deploy driver testing, and am willing
> to accept the consequences within the project if we break our own
> abstractions.
>
> Regards,
> Devananda
>
> ___
> 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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> >> So would we:
> >>
> >>  (a) add a new integrated-gate-ceilometer project-template to [1],
> >>  in the style of integrated-gate-neutron or integrated-gate-sahara,
> >>  which would replicate the main integrated-gate template but with
> >>  the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)
> >>
> >> or:
> >>
> >>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from
> >>  the experimental column[2] in the openstack-ceilometer project,
> >>  to the gate column on that project
> >>
> >> or:
> >>
> >>  (c) something else
> >>
> >> Please excuse the ignorance of gate mechanics inherent in that question.
> >
> >
> >
> > Correct, AFAIK (a) or (b) would be sufficient.
> >
> > There is another option, which is make the mongodb version the default in
> > integrated-gate and only run SQLA on ceilometer.
> >
> 
> Joe,
> 
> I believe this last option is equivalent to making mongodb the
> recommended implementation by virtue of suddenly being the most tested
> implementation. I would prefer not to see that.
> 
> Eoghan,
> 
> IIUC (and I am not an infra expert) I would suggest (b) since this
> keeps the mongo tests within the ceilometer project only, which I
> think is fine from a "what we test is what we recommend" standpoint.

Fair enough ... though I think (a) would also have that quality
of encapsulation, as long as the new integrated-gate-ceilometer
project-template was only referenced by the openstack/ceilometer
project.

I'm not sure it makes a great deal of difference though, so would
be happy enough to go with either (b) or (a).

> Also, if there is a situation where a change in Nova passes with
> ceilometer+mysql and thus lands in Nova, but fails with
> ceilometer+mongodb, yes, that would break the ceilometer project's
> gate (but not the integrated gate). It would also indicate a
> substantial abstraction violation within ceilometer. I have proposed
> exactly this model for Ironic's deploy driver testing, and am willing
> to accept the consequences within the project if we break our own
> abstractions.

Fair point.

Cheers,
Eoghan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Devananda van der Veen]

On Mon, Aug 11, 2014 at 3:27 PM, Joe Gordon  wrote:
>
>
>
> On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn  wrote:
>>
>>
>>
>> > 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.
>>
>> Just checking to see that I fully understand what you mean there, Joe.
>>
>> So would we:
>>
>>  (a) add a new integrated-gate-ceilometer project-template to [1],
>>  in the style of integrated-gate-neutron or integrated-gate-sahara,
>>  which would replicate the main integrated-gate template but with
>>  the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)
>>
>> or:
>>
>>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from
>>  the experimental column[2] in the openstack-ceilometer project,
>>  to the gate column on that project
>>
>> or:
>>
>>  (c) something else
>>
>> Please excuse the ignorance of gate mechanics inherent in that question.
>
>
>
> Correct, AFAIK (a) or (b) would be sufficient.
>
> There is another option, which is make the mongodb version the default in
> integrated-gate and only run SQLA on ceilometer.
>

Joe,

I believe this last option is equivalent to making mongodb the
recommended implementation by virtue of suddenly being the most tested
implementation. I would prefer not to see that.

Eoghan,

IIUC (and I am not an infra expert) I would suggest (b) since this
keeps the mongo tests within the ceilometer project only, which I
think is fine from a "what we test is what we recommend" standpoint.

Also, if there is a situation where a change in Nova passes with
ceilometer+mysql and thus lands in Nova, but fails with
ceilometer+mongodb, yes, that would break the ceilometer project's
gate (but not the integrated gate). It would also indicate a
substantial abstraction violation within ceilometer. I have proposed
exactly this model for Ironic's deploy driver testing, and am willing
to accept the consequences within the project if we break our own
abstractions.

Regards,
Devananda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Joe Gordon]

On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn  wrote:

>
>
> > 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.
>
> Just checking to see that I fully understand what you mean there, Joe.
>
> So would we:
>
>  (a) add a new integrated-gate-ceilometer project-template to [1],
>  in the style of integrated-gate-neutron or integrated-gate-sahara,
>  which would replicate the main integrated-gate template but with
>  the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)
>
> or:
>
>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from
>  the experimental column[2] in the openstack-ceilometer project,
>  to the gate column on that project
>
> or:
>
>  (c) something else
>
> Please excuse the ignorance of gate mechanics inherent in that question.
>


Correct, AFAIK (a) or (b) would be sufficient.

There is another option, which is make the mongodb version the default in
integrated-gate and only run SQLA on ceilometer.



>
> Cheers,
> Eoghan
>
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n238
> [2]
> http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n801
>
>
> > [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
> >
>
> ___
> 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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> 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.

Just checking to see that I fully understand what you mean there, Joe.

So would we:

 (a) add a new integrated-gate-ceilometer project-template to [1],
 in the style of integrated-gate-neutron or integrated-gate-sahara,
 which would replicate the main integrated-gate template but with
 the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)

or:

 (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from
 the experimental column[2] in the openstack-ceilometer project,
 to the gate column on that project

or:

 (c) something else

Please excuse the ignorance of gate mechanics inherent in that question.

Cheers,
Eoghan


[1] 
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n238
[2] 
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n801

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Joe Gordon]

On Sat, Aug 9, 2014 at 6:29 AM, Eoghan Glynn  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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> Agreed, testing options is good; and should likely be disjoint from the legal
> questions around mongodb...
> 
> Although if there is really only one viable & scalable option and that option
> has legal usage questions surrounding it then it makes me wonder how much we
> are kidding ourselves on there being anything optional about this... Not
> something I can answer but someone likely should?.?.
> 
> I guess it really depends on what the desired outcome of testing with mongodb
> is, if the outcome is to satisfy a TC requirement for improved testing via
> *any* backend then this would seem applicable. If instead it's around
> testing a backend that isn't legally encumbered (and is also realistically
> viable to use) then we are in a different area altogether...

Usual IANAL caveats, I just want to ensure that some code that's used in
the wild to also be tested upstream :)

So as stated in response to Devananda, I'm happy for this change to have
more the character of an *expansion* in overall coverage, as opposed to
an *exchange* of one type of coverage for another.

Assuming of course that the QA/infra side of the house are willing to
accommodate that, it would seem to satisfy both requirements?

Not to open another hornet's nest, but note that there is actually a
third opensource option for ceilometer storage, in the form of the
hbase driver (Apache 2.0 being the applicable license for the backend
in this case). In performance testing done by Ilya Tyaptin, this
backend shows same-ballpark performance characteristics to mongodb.

Cheers,
Eoghan
 
> Just my 2cents.
> 
> Sent from my really tiny device...
> 
> > On Aug 9, 2014, at 10:53 AM, "Eoghan Glynn"  wrote:
> > 
> > 
> > 
> >> +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??
> > 
> > Hi Joshua,
> > 
> > Since we currently do support mongodb as an *optional* storage driver,
> > and some distros do recommend its usage, then surely we should test this
> > driver fully in the upstream gate to support those users who take that
> > option?
> > 
> > (i.e. those users who accept MongoDB Inc's assurances[1] in regard to
> > licensing of the client-side driver)
> > 
> > Cheers,
> > Eohgan
> > 
> > [1] http://www.mongodb.org/about/licensing/
> > 
> > ___
> > 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
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Joshua Harlow]

Agreed, testing options is good; and should likely be disjoint from the legal 
questions around mongodb...

Although if there is really only one viable & scalable option and that option 
has legal usage questions surrounding it then it makes me wonder how much we 
are kidding ourselves on there being anything optional about this... Not 
something I can answer but someone likely should?.?.

I guess it really depends on what the desired outcome of testing with mongodb 
is, if the outcome is to satisfy a TC requirement for improved testing via 
*any* backend then this would seem applicable. If instead it's around testing a 
backend that isn't legally encumbered (and is also realistically viable to use) 
then we are in a different area altogether...

Just my 2cents.

Sent from my really tiny device...

> On Aug 9, 2014, at 10:53 AM, "Eoghan Glynn"  wrote:
> 
> 
> 
>> +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??
> 
> Hi Joshua,
> 
> Since we currently do support mongodb as an *optional* storage driver,
> and some distros do recommend its usage, then surely we should test this
> driver fully in the upstream gate to support those users who take that
> option?
> 
> (i.e. those users who accept MongoDB Inc's assurances[1] in regard to
> licensing of the client-side driver)
> 
> Cheers,
> Eohgan
> 
> [1] http://www.mongodb.org/about/licensing/
> 
> ___
> 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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> +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??

Hi Joshua,

Since we currently do support mongodb as an *optional* storage driver,
and some distros do recommend its usage, then surely we should test this
driver fully in the upstream gate to support those users who take that
option?

(i.e. those users who accept MongoDB Inc's assurances[1] in regard to
licensing of the client-side driver)

Cheers,
Eohgan

[1] http://www.mongodb.org/about/licensing/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Joshua Harlow]

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


On Aug 9, 2014 4:22 AM, "Eoghan Glynn" 
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]

-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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> Eoghan,
> 
> Nice work on this. I think that first of all this job should be run on every
> patch for some period of time (not only in experimental pipe)
> 
> By the way, If you would like we can help from Rally side.
> We are running benchmarks on every patch in it's gates. Ceilometer is fully
> turned on in these jobs, so we can be first adopters and switch to mongodb.

Hi Boris,

Excellent, that additional coverage would certainly be helpful.

Though in terms of the performance characteristics reported by
Rally, I'm guessing we wouldn't see much change, given the faster
metering store access would all be happening asynchronously to
the paths measured by Rally, amiright?

Cheers,
Eoghan

> This will ensure that everything works stable even under load, and i hope
> convince people to switch integrate gate to mongo.
> 
> 
> Best regards,
> Boris Pavlovic
> 
> 
> On Sat, Aug 9, 2014 at 3:19 PM, 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
> 
> ___
> 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
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

> > 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 

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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Devananda van der Veen]

On Aug 9, 2014 4:22 AM, "Eoghan Glynn"  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]

-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

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Boris Pavlovic]

Eoghan,

Nice work on this. I think that first of all this job should be run on
every patch for some period of time (not only in experimental pipe)

By the way, If you would like we can help from Rally side.
We are running benchmarks on every patch in it's gates. Ceilometer is fully
turned on in these jobs, so we can be first adopters and switch to mongodb.
This will ensure that everything works stable even under load, and i hope
convince people to switch integrate gate to mongo.


Best regards,
Boris Pavlovic


On Sat, Aug 9, 2014 at 3:19 PM, Eoghan Glynn  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
>
> ___
> 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

[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

[Eoghan Glynn]

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev