Open Stack

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:

https://review.openstack.org/#/q/topic:newton-db+status:abandoned

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

-- 

Thanks,

Matt Riedemann