Open Stack

On 08/08/12 23:22 +0100, Nick Barcet wrote:
>On 08/08/2012 08:52 PM, Julien Danjou wrote:
>> On Wed, Aug 08 2012, Nick Barcet wrote:
>>
>> Hi Nick,
>>
>>> - our polling interval are 5 min or more.  Would this be acceptable for
>>> a resource to remain unavailable that long?  Increasing this interval
>>> would drastically increase our data volume, and since we need to keep
>>> this data, volume does count.  There is a tool that we have to estimate
>>> volumes [2]. I don't think your tool would need to keep as much
>>> information for as long.
>>
>> Data volume is relative. I don't think that's a good argument.
>
>Could you please explain?  Not sure I follow the "is relative" argument
>here. If we increase the periodicity of messages and send them all to
>the collector, the volume of data will increase without an ounce of a doubt.

Yes I too was concerned how the current architecture would deal with the
increased data volume.

>
>>> - Ceilometer gather data from the infrastructure and has no plan to help
>>> monitor instances.  Wouldn't this be a requirement for CloudWatch?
>>
>> This is probably a real problem, but I think that can be circumved using
>> the source property and a layer between instances and Ceilometer. But
>> that's not Ceilometer problem, more likely CloudWatch's one.
>
>Sure, but wouldn't this end up in forcing the solution with a big
>shoehorn?  I would happily see our agents sending informations to
>multiple destinations at different intervals to serve different
>purposes, but using the same transport, collector and storage would not
>seem appropriate to me.

This seems like a good start.
So to clarify, I wasn't assuming we use _all_ of the current infrastructure.

We could just start off with just using the pollsters/agents and write
a different api server & collector. Then if it makes sense, we can merge
to a more common architecture later. I still think it word make sense
putting this code in Ceilometer given the amount of overlap.

>
>>> - Ceilometer has strong requirements for traceability of information,
>>> something that you would not care about to collect performance metrics.
>>
>> That is true, but we may make this configurable on a per source basis.
>
>So this would really transform the proposal to "can agents be extended
>to serve other needs, as it would make sense to code how to fetch and
>send information only once?".  This does make some sense.

Cool.

>
>>> Sorry to push you back on this, but I am afraid that the requirements
>>> you expose would not match our own set of requirements.  I do value your
>>> objective highly however, and hope that such a tool would be made
>>> available for OpenStack deployments, as I can see many uses cases this
>>> would solve.
>>
>> I don't think we should push this back too quickly. If there's a chance
>> Ceilometer can be used by CloudWatch, we should listen.
>>
>> So far, it does not seem to me that we are asked to change anything in
>> Ceilometer's design to fullful CloudWatch requirement. And even if some
>> are requested explicitely, we should discuss the amount of bending we
>> are ready to do to help, and if we do.
>
>Well, it would be adding quite a few use cases that would modify the
>scope of the project quite a bit,

I understand, but it wouldn't having this capability make the project
more compelling? I think it is very powerful functionality.

>and I would think that at this time we
>should be focusing on delivering what we have already designed rather
>than adding new requirements.  However, you make a good point that this
>could be a topic to discuss at ODS in October.

Sure, I am sending this ahead of time just to start thinking about
the problems so it not a suprise later. I don't want to cause you
problems in delivering metering.

I understand the idea of doing one thing well. But if it means we
then need to re-implement quite a bit of what is in ceilometer
then that doesn't make sense either. Perhaps the "one thing" can
be a more general "statistics"? Also there will be more developers
on ceilometer which is always a good thing (instead of spreading
this effort across 2 projects).


-Angus

>
>Nick
>
>
>
>



>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev