[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest
Eoghan Glynn
eglynn at redhat.com
Mon Aug 11 23:14:04 UTC 2014
> >> 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
More information about the OpenStack-dev
mailing list