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

2014-08-11 Thread Joe Gordon
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


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

2014-08-11 Thread 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

2014-08-11 Thread Joe Gordon
On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn egl...@redhat.com 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

2014-08-11 Thread Devananda van der Veen
On Mon, Aug 11, 2014 at 3:27 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn egl...@redhat.com 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

2014-08-11 Thread 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

2014-08-11 Thread 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 joe.gord...@gmail.com wrote:
 
 
 
  On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn egl...@redhat.com 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


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

2014-08-09 Thread 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


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

2014-08-09 Thread 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 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


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

2014-08-09 Thread Devananda van der Veen
On Aug 9, 2014 4:22 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]

-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

2014-08-09 Thread 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

2014-08-09 Thread 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

2014-08-09 Thread 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 
devananda@gmail.commailto:devananda@gmail.com wrote:


On Aug 9, 2014 4:22 AM, Eoghan Glynn 
egl...@redhat.commailto: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.orgmailto: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

2014-08-09 Thread 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

2014-08-09 Thread 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 egl...@redhat.com 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

2014-08-09 Thread 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 egl...@redhat.com 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