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" <[email protected]>
To: "John Garbutt" <[email protected]>
Cc: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
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 <[email protected]> wrote:
On Mon, Dec 16, 2013 at 03:37:39PM +0000, John Garbutt wrote:
On 16 December 2013 15:25, Daniel P. Berrange <[email protected]>
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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
