Open Stack

On Mon, Aug 11, 2014 at 3:53 PM, Devananda van der Veen <
devananda.vdv at gmail.com> wrote:

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

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140811/29bfbf00/attachment.html>