[openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer tempest testing in gate

David Kranz dkranz at redhat.com
Thu Mar 20 15:35:29 UTC 2014

On 03/20/2014 06:15 AM, Sean Dague wrote:
> On 03/20/2014 05:49 AM, Nadya Privalova wrote:
>> Hi all,
>> First of all, thanks for your suggestions!
>> To summarize the discussions here:
>> 1. We are not going to install Mongo (because "is's wrong" ?)
> We are not going to install Mongo "not from base distribution", because
> we don't do that for things that aren't python. Our assumption is
> dependent services come from the base OS.
> That being said, being an integrated project means you have to be able
> to function, sanely, on an sqla backend, as that will always be part of
> your gate.
This is a claim I think needs a bit more scrutiny if by "sanely" you 
mean "performant". It seems we have an integrated project that no one 
would deploy using the sql db driver we have in the gate. Is any one 
doing that?  Is having a scalable sql back end a goal of ceilometer?

More generally, if there is functionality that is of great importance to 
any cloud deployment (and we would not integrate it if we didn't think 
it was) that cannot be deployed at scale using sqla, are we really going 
to say it should not be a part of OpenStack because we refuse, for 
whatever reason, to run it in our gate using a driver that would 
actually be used? And if we do demand an sqla backend, how much time 
should we spend trying to optimize it if no one will really use it? 
Though the slow heat job is a little different because the slowness 
comes directly from running real use cases, perhaps we should just set 
up a "slow ceilometer" job if the sql version is too slow for its budget 
in the main job.

It seems like there is a similar thread, at least in part, about this 
around marconi.



More information about the OpenStack-dev mailing list