[nova][telemetry] does Telemetry still use the Nova server usage audit log API?

Tim Bell tim.bell at cern.ch
Sat Sep 7 15:16:13 UTC 2019


On 9/7/19 3:09 PM, Matt Riedemann wrote:
> On 9/6/2019 6:59 PM, melanie witt wrote:
>>
>> * If Telemetry is no longer using the server usage audit log API, we 
>> deprecate it in Nova and notify deployment tools to stop setting 
>> [DEFAULT]/instance_usage_audit = true to prevent further creation of 
>> nova.task_log records and recommend manual cleanup by users
>
> Deprecating the API would just be a signal to not develop new tools 
> based on it since it's effectively unmaintained but that doesn't mean 
> we can remove it since there could be non-Telemtry tools in the wild 
> using it that we'd never hear about. You might not be suggesting an 
> eventual path to removal of the API, I'm just bringing that part up 
> since I'm sure people are thinking it.
>
Tools like cASO (https://github.com/IFCA/caso) use this API. This is 
used by many of the EGI Federated Cloud sites to do accounting per VM 
(https://egi-federated-cloud-integration.readthedocs.io/en/latest/openstack.html)


> I'm also assuming that API isn't multi-cell aware, meaning it won't 
> traverse cells pulling records like listing servers or migration 
> resources.
Given scaling issues with the current Telemetry implementation, I 
suspect alternative approaches have had to be developed in any case. 
CERN uses libvirt data extraction.
>
> As for the config option to run the periodic task that creates these 
> records, that's disabled by default so deployment tools shouldn't be 
> enabling it by default - but maybe some do if they are configured to 
> deploy ceilometer.
>
>>
>> or
>>
>> * If Telemetry is still using the server usage audit log API, we 
>> create a new 'nova-manage db purge_task_log --before <date>' (or 
>> similar) command that will hard delete nova.task_log records before a 
>> specified date or all if --before is not specified
>
> If you can't remove the API then this is probably something that needs 
> to happen regardless, though we likely won't know if anyone uses it. 
> I'd consider it pretty low priority given how extremely latent this is 
> and would expect anyone that's been running with this enabled in 
> production has developed DB purge scripts for this table long ago.
>



More information about the openstack-discuss mailing list