Open Stack

On Thursday, December 19, 2013 8:49:13 AM, Vladik Romanovsky wrote:
> Or
>
> ceilometer meter-list -q resource_id='vm_uuid'
>
> ----- Original Message -----
>> From: "Daniel P. Berrange" <berrange at redhat.com>
>> To: "John Garbutt" <john at johngarbutt.com>
>> Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
>> Sent: Thursday, 19 December, 2013 9:34:02 AM
>> Subject: Re: [openstack-dev] [nova] VM diagnostics - V3 proposal
>>
>> On Thu, Dec 19, 2013 at 02:27:40PM +0000, John Garbutt wrote:
>>> On 16 December 2013 15:50, Daniel P. Berrange <berrange at redhat.com> wrote:
>>>> On Mon, Dec 16, 2013 at 03:37:39PM +0000, John Garbutt wrote:
>>>>> On 16 December 2013 15:25, Daniel P. Berrange <berrange at redhat.com>
>>>>> wrote:
>>>>>> On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
>>>>>>> I'd like to propose the following for the V3 API (we will not touch
>>>>>>> V2
>>>>>>> in case operators have applications that are written against this –
>>>>>>> this
>>>>>>> may be the case for libvirt or xen. The VMware API support was added
>>>>>>> in I1):
>>>>>>>
>>>>>>>   1.  We formalize the data that is returned by the API [1]
>>>>>>
>>>>>> Before we debate what standard data should be returned we need
>>>>>> detail of exactly what info the current 3 virt drivers return.
>>>>>> IMHO it would be better if we did this all in the existing wiki
>>>>>> page associated with the blueprint, rather than etherpad, so it
>>>>>> serves as a permanent historical record for the blueprint design.
>>>>>
>>>>> +1
>>>>>
>>>>>> While we're doing this I think we should also consider whether
>>>>>> the 'get_diagnostics' API is fit for purpose more generally.
>>>>>> eg currently it is restricted to administrators. Some, if
>>>>>> not all, of the data libvirt returns is relevant to the owner
>>>>>> of the VM but they can not get at it.
>>>>>
>>>>> Ceilometer covers that ground, we should ask them about this API.
>>>>
>>>> If we consider what is potentially in scope for ceilometer and
>>>> subtract that from what the libvirt get_diagnostics impl currently
>>>> returns, you pretty much end up with the empty set. This might cause
>>>> us to question if 'get_diagnostics' should exist at all from the
>>>> POV of the libvirt driver's impl. Perhaps vmware/xen return data
>>>> that is out of scope for ceilometer ?
>>>
>>> Hmm, a good point.
>>
>> So perhaps I'm just being dumb, but I deployed ceilometer and could
>> not figure out how to get it to print out the stats for a single
>> VM from its CLI ? eg, can someone show me a command line invocation
>> for ceilometer that displays CPU, memory, disk and network I/O stats
>> in one go ?
>>
>>
>> Daniel
>> --
>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I just wanted to point out for anyone that hasn't reviewed it yet, but 
Gary's latest design wiki [1] is quite a departure from his original 
set of patches for this blueprint, which was pretty straight-forward, 
just namespacing the diagnostics dict when using the nova v3 API.  The 
keys were all still hypervisor-specific.

The proposal now is much more generic and attempts to translate 
hypervisor-specific keys/data into a common standard versioned set and 
allows for some wiggle room for the drivers to still provide custom 
data if necessary.

I think this is a better long-term solution but is a lot more work than 
the original blueprint and given there seems to be some feeling of 
"does nova even need this API, can ceilometer provider it instead?" I'd 
like there to be some agreement within nova that this is the right way 
to go before Gary spends a bunch of time on it - and I as the bp 
sponsor spend a bunch of time reviewing it. :)

[1] https://wiki.openstack.org/wiki/Nova_VM_Diagnostics

--

Thanks,

Matt Riedemann