[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