Open Stack

On 05/02/14 10:07, Joe Gordon wrote:
> On Tue, Feb 4, 2014 at 2:01 AM, Julien Danjou <julien at danjou.info> wrote:
>> On Mon, Feb 03 2014, Joe Gordon wrote:
>>
>>>> We know, Ceilometer has been broken several times because of that in the
>>>> past months. We know we shouldn't do that, but for now we don't have
>>>> enough work force to work on a batter solution unfortunately.
>>> Does this issue mean Ceilometer won't rwork for the most literal
>>> definition of continuous deployment?
>> They are tests intercepting the issue, so I don't think that invalidate
>> the use of CD.
>>
>>> Has this ever been a problem in the stable branches?
>> It has been a problem only because we were referencing nova-master in
>> test-requirements, but changing it to the reference the same version as
>> Ceilometer (e.g. havana) fixed it.
>>
>>> Whats the underlying problem here? nova notifications aren't
>>> versioned?  Nova should try to support ceilometer's use case so it
>>> sounds like there is may be a nova issue in here as well.
>> Oh you're far from it.
>>
>> Long story short, the problem is that when an instance is detroyed, we
>> need to poll one last time for its CPU, IO, etc statistics to send them
>> to Ceilometer. The only way we found to do that in Nova is to plug a
>> special notification driver that intercepts the deletion notification in
>> Nova, run the pollsters, and then returns to Nova execution.
>
> Ceilometer running a plugin in nova is bad (for all the reasons
> previously discussed), this broke ceilometer for in Havana
> (https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues_7).
> So what can nova do to help this?  It sounds like you have a valid use
> case that nova should support without requiring a plugin.
>
>
I would like to also point out that if we are handling the terminate 
case it would be good to handle:
suspend, resize, soft_reboot, hard_reboot, shutdown, and rebuild. Pause 
still allows metric gathering, so that case is fine.

Mainly because in all those cases cumulative data is lost because the 
metrics are reset before the next poll interval. It would be nice to 
have a poll occur before any shutdown/suspend and also on start/resume 
so we can final values and be certain that the next ceilometer sample is 
a reset value. Or in the case of rebuild/reboot/resize, a poll on 
event.start and event.end so we get final reading, and clear reset value.

Otherwise we aren't getting accurate and consistent data.