Open Stack

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.

> 2. Idea about spawning several collectors is suspicious (btw there is a
> patch that run several collectors:
> https://review.openstack.org/#/c/79962/ .)

Correct, given that the collector is already one of the most expensive
processes in a devstack run.

> Let's try to get back to original problem. All these solutions were
> suggested to solve the problem of high load on Ceilometer. AFAIK,
> Tempest's goal is to test projects` interactions, not performance
> testing. The perfect tempest's behaviour would be "start ceilometer only
> for Ceilometer tests". From one hand it will allow not to load db during
> other tests, from the other hand "projects` interactions" will be tested
> because during Ceilometer test we create volums, images and instances.
> But I'm afraid that this scenario is not possible technically.
> There is one more idea. Make Ceilometer able to monitor not all messages
> but filtered set of messages. But anyway this is a new feature and
> cannot be added right now.
> 
> Tempest guys, if you have any thoughts about first suggestion "start
> ceilometer only for Ceilometer tests" please share.

The point of the gate is that it's integrated and testing the
interaction between projects. Ceilometer can be tested on it's own in
ceilometer unit tests, or by creating ceilometer functional tests that
only run on the ceilometer jobs.

While I agree that Tempest's job is not to test performance, we do have
to give some basic sanity checking here that the software is running in
some performance profile that we believe is base usable.

Based on the latest dstat results, I think that's a dubious assessment.
The answer on the collector side has to be something other than
horizontal scaling. Because we're talking about the collector being the
3rd highest utilized process on the box right now (we should write a
dstat plugin to give us cumulative data, just haven't gotten there yet).

So right now, I think performance analysis for ceilometer on sqla is
important, really important. Not just horizontal scaling, but actual
performance profiling.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/ff5abf04/attachment.pgp>