[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest
Devananda van der Veen
devananda.vdv at gmail.com
Mon Aug 11 22:53:52 UTC 2014
On Mon, Aug 11, 2014 at 3:27 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn <eglynn at 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
More information about the OpenStack-dev
mailing list