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