<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 3:53 PM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 11, 2014 at 3:27 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>


><br>
><br>
><br>
> On Mon, Aug 11, 2014 at 3:07 PM, Eoghan Glynn <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> > Ignoring the question of is it ok to say: 'to run ceilometer in any sort<br>
>> > of<br>
>> > non-trivial deployment you must manager yet another underlying service,<br>
>> > mongodb' I would prefer not adding an addition gate variant to all<br>
>> > projects.<br>
>> > With the effort to reduce the number of gate variants we have [0] I<br>
>> > would<br>
>> > prefer to see just ceilometer gate on both mongodb and sqlalchemy and<br>
>> > the<br>
>> > main integrated gate [1] pick just one.<br>
>><br>
>> Just checking to see that I fully understand what you mean there, Joe.<br>
>><br>
>> So would we:<br>
>><br>
>>  (a) add a new integrated-gate-ceilometer project-template to [1],<br>
>>      in the style of integrated-gate-neutron or integrated-gate-sahara,<br>
>>      which would replicate the main integrated-gate template but with<br>
>>      the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)<br>
>><br>
>> or:<br>
>><br>
>>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from<br>
>>      the experimental column[2] in the openstack-ceilometer project,<br>
>>      to the gate column on that project<br>
>><br>
>> or:<br>
>><br>
>>  (c) something else<br>
>><br>
>> Please excuse the ignorance of gate mechanics inherent in that question.<br>
><br>
><br>
><br>
> Correct, AFAIK (a) or (b) would be sufficient.<br>
><br>
> There is another option, which is make the mongodb version the default in<br>
> integrated-gate and only run SQLA on ceilometer.<br>
><br>
<br>
</div></div>Joe,<br>
<br>
I believe this last option is equivalent to making mongodb the<br>
recommended implementation by virtue of suddenly being the most tested<br>
implementation. I would prefer not to see that.<br></blockquote><div><br></div><div>Agreed, I included this option for completeness.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Eoghan,<br>
<br>
IIUC (and I am not an infra expert) I would suggest (b) since this<br>
keeps the mongo tests within the ceilometer project only, which I<br>
think is fine from a "what we test is what we recommend" standpoint.<br>
<br>
Also, if there is a situation where a change in Nova passes with<br>
ceilometer+mysql and thus lands in Nova, but fails with<br>
ceilometer+mongodb, yes, that would break the ceilometer project's<br>
gate (but not the integrated gate). It would also indicate a<br>
substantial abstraction violation within ceilometer. I have proposed<br>
exactly this model for Ironic's deploy driver testing, and am willing<br>
to accept the consequences within the project if we break our own<br>
abstractions.<br>
<br>
Regards,<br>
Devananda<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>