[openstack-dev] [ironic] [nova] [neutron] get_all_bw_counters in the Ironic virt driver

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Aug 2 13:58:35 UTC 2016

On 8/2/2016 6:22 AM, John Garbutt wrote:
> On 29 July 2016 at 19:58, Sean Dague <sean at dague.net> wrote:
>> On 07/29/2016 02:29 PM, Jay Pipes wrote:
>>> On 07/28/2016 09:02 PM, Devananda van der Veen wrote:
>>>> On 07/28/2016 05:40 PM, Brad Morgan wrote:
>>>>> I'd like to solicit some advice about potentially implementing
>>>>> get_all_bw_counters() in the Ironic virt driver.
>>>>> https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L438
>>>>> Example Implementation:
>>>>> https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L320
>>>>> I'm ignoring the obvious question about how this data will actually be
>>>>> collected/fetched as that's probably it's own topic (involving
>>>>> neutron), but I
>>>>> have a few questions about the Nova -> Ironic interaction:
>>>>> Nova
>>>>> * Is get_all_bw_counters() going to stick around for the foreseeable
>>>>> future? If
>>>>> not, what (if anything) is the replacement?
>>> I don't think Nova should be in the business of monitoring *any*
>>> transient metrics at all.
>>> There are many tools out there -- Nagios, collectd, HEKA, Snap, gnocchi,
>>> monasca just to name a few -- that can do this work.
>>> What action is taken if some threshold is reached is entirely
>>> deployment-dependent and not something that Nova should care about. Nova
>>> should just expose an API for other services to use to control the guest
>>> instances under its management, nothing more.
>> More importantly... *only* xenapi driver implements this, and it's not
>> exposed over the API. In reality that part of the virt driver layer
>> should probably be removed.
> AFAIK, it is only exposed via notifications:
> https://github.com/openstack/nova/blob/562a1fe9996189ddd9cc5c47ab070a498cfce258/nova/notifications/base.py#L276
> I think its emitted here:
> https://github.com/openstack/nova/blob/562a1fe9996189ddd9cc5c47ab070a498cfce258/nova/compute/manager.py#L5886
> Agreed with not adding to the legacy, and not to encourage new users of this.
> Long term, it feels like removing this from Nova is the correct thing
> to do, but I do worry about not having an obvious direct replacement
> yet, and a transition plan. (This also feeds back into being able to
> list deleted instances in the API, and DB soft_delete). Its not
> trivial.
>> Like jay said, there are better tools for collecting this than Nova.
> I am out of touch with what folks should use to get this data, and
> build a billing system? Ceilometer + something?
> It feels like that story has to be solid before we delete this
> support. Maybe thats already the case, and I just don't know what that
> is yet?
> Thanks,
> John
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

We also have the orphaned rows issue with the database which lxsli was 
trying to fix but it got messy:


But that will break the DB archive command if you're actually using these.



Matt Riedemann

More information about the OpenStack-dev mailing list