Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest
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
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
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
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
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
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
Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest
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
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
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
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
+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
+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
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
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
