Open Stack

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.

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

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

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

Nick




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