Re: [Openstack] [Ceilometer] Problem with nova resize events

2013-07-24 Thread Alessandro Barabesi 
Hi Jay and Julien

thanks very much for your help. I am not terribly familiar with github and code 
reviews, 
I am not a developer :(, so maybe I am not using the correct terms here.

We are using version 2013.1.2  of ceilometer, so we have no 
ComputeInstanceNotificationBase class in notifications.py, instead we have 

 class _Base(plugin.NotificationBase) , which handles events with

get_event_types():
return ['compute.instance.create.end',
'compute.instance.exists',
'compute.instance.delete.start',
'compute.instance.finish_resize.end',
'compute.instance.resize.revert.end']

like ComputeInstanceNotificationBase does.

What is your suggestion in order to enable handlings of more compute events, 
considering we will go live in 2-3 weeks time?

1- We wait for Julien's patch to be approved and we upgrade to the patched 
version. 
2- We modify ourselves get_event_types() on our installation
3- ?

Thanks
Alex

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: mercoledì 24 luglio 2013 17:39
To: Jay Lau
Cc: Alessandro Barabesi; openstack@lists.launchpad.net
Subject: Re: [Openstack] [Ceilometer] Problem with nova resize events

On Wed, Jul 24 2013, Jay Lau wrote:

 Hi Alex,

 Not sure if it is a bug, but you are right, ceiloemeter did not send 
 the notification that you required. Perhaps you can log a bug or else 
 you can patch your cluster directly to enable this.

 class ComputeInstanceNotificationBase(ComputeNotificationBase):
 Convert compute.instance.* notifications into Counters
 
 @staticmethod
 def get_event_types():
 return ['compute.instance.create.start',
 'compute.instance.create.end',
 'compute.instance.exists',
 'compute.instance.update',
 'compute.instance.delete.start',
 'compute.instance.delete.end',
 'compute.instance.finish_resize.end',
 'compute.instance.resize.revert.end']
 Thanks,

Not really a bug, but we know we could do better.
I've just cooked a patch that should improve that:

   https://review.openstack.org/38485

--
Julien Danjou
# Free Software hacker # freelance consultant # http://julien.danjou.info
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Ceilometer] Problems with query fields in filters

2013-07-12 Thread Alessandro Barabesi 
Hi everybody,

I have the following problems with query fields in filters.

1) Filtering by metadata.size in v2/meters/image apparently is not working. 
The following request returns also samples with metadata.size=0.


GET http://10.10.10.10:8777/v2/meters/image 


{
q: [{
field: project_id,
op: eq,
value: 77b461539c8542909f67b29939ec87dd
},
{
field: timestamp,
op: ge,
value: 2013-07-11T13:36:00
},
{
field: timestamp,
op: lt,
value: 2013-07-11T13:39:00
},
{
field: metadata.size,
op: gt,
value: 0
}]

}

I am probably doing something wrong but I can't figure out what.


2) Filtering by counter_volume returns the folloving error message:

error_message={debuginfo: null, faultcode: Client, faultstring: 
Unknown argument: \counter_volume\: unrecognized query field}

Is this a bug or filtering by counter-volume is not allowed?


Many thanks
Alex
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Ceilometer] Problems with query fields in filters

2013-07-12 Thread Alessandro Barabesi 
Hi Julien

thanks for your reply, unfortunately volume instead of counter_volume is 
not working either.

Alex

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: venerdì 12 luglio 2013 11:34
To: Alessandro Barabesi
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [Ceilometer] Problems with query fields in filters

On Fri, Jul 12 2013, Alessandro Barabesi wrote:

 I have the following problems with query fields in filters.

 1) Filtering by metadata.size in v2/meters/image apparently is not working. 
 The following request returns also samples with metadata.size=0.


 GET http://10.10.10.10:8777/v2/meters/image


 {
   q: [{
   field: project_id,
   op: eq,
   value: 77b461539c8542909f67b29939ec87dd
   },
   {
   field: timestamp,
   op: ge,
   value: 2013-07-11T13:36:00
   },
   {
   field: timestamp,
   op: lt,
   value: 2013-07-11T13:39:00
   },
   {
   field: metadata.size,
   op: gt,
   value: 0
   }]
   
 }

 I am probably doing something wrong but I can't figure out what.

That seems correct from the top of my head. If that really doesn't work, feel 
free to open a bug.

 2) Filtering by counter_volume returns the folloving error message:

 error_message={debuginfo: null, faultcode: Client, 
 faultstring: Unknown argument: \counter_volume\: unrecognized 
 query field}

 Is this a bug or filtering by counter-volume is not allowed?

Try `volume' instead of `counter_volume'. But I am not sure it's currently 
allowed -- in that case opening a bug can be good idea too.

--
Julien Danjou
// Free Software hacker / freelance consultant // http://julien.danjou.info
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Ceilometer] volume.exists events collected after volume is deleted

2013-07-12 Thread Alessandro Barabesi 
Hi everybody,

ceilometer collects samples for a volume even after the volume has been 
deleted, reporting event volume.exists (see below). 
Does it dependend on ceilometer or on cinder? Is there a way to stop this?


[{
counter_name: volume.size,
user_id: 0ac98027a16849339a31f4f1f1114df2,
resource_id: 44e2cf92-5f72-49c6-b0d7-4f8ec2c0bde9,
timestamp: 2013-07-11T16:24:02.239000,
resource_metadata: {
status: deleted,
display_name: Vol_02_Ale_Test_03,
event_type: volume.exists,
volume_type: None,
host: volume.grizzly,
size: 6
},
source: openstack,
counter_unit: B,
counter_volume: 6.0,
project_id: 77b461539c8542909f67b29939ec87dd,
message_id: 4c40cffc-ea46-11e2-9a49-00259075703e,
counter_type: gauge
},
{
counter_name: volume.size,
user_id: 0ac98027a16849339a31f4f1f1114df2,
resource_id: 6267f31c-293a-43ec-b691-b81742364c92,
timestamp: 2013-07-11T16:24:02.249000,
resource_metadata: {
status: in-use,
display_name: Vol_01_Ale_Test_03,
event_type: volume.exists,
volume_type: None,
host: volume.grizzly,
size: 3
},
source: openstack,
counter_unit: B,
counter_volume: 3.0,
project_id: 77b461539c8542909f67b29939ec87dd,
message_id: 4c425610-ea46-11e2-9a49-00259075703e,
counter_type: gauge
}]

Thanks 
Alex
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Ceilometer] Problems with query fields in filters

2013-07-12 Thread Alessandro Barabesi 
Hi Angus

without the metadata.size filter I get all samples, with sizeo and with size=0.
Same thing with the metadata.size filter using the following operators:

gt,lt,ne,le,ge

The most strange thing is that if I use the operator eq I get an empty 
response!

Thanks
Alex

-Original Message-
From: Angus Salkeld [mailto:asalk...@redhat.com] 
Sent: venerdì 12 luglio 2013 12:55
To: openstack@lists.launchpad.net
Cc: Alessandro Barabesi
Subject: Re: [Openstack] [Ceilometer] Problems with query fields in filters

On 12/07/13 11:33 +0200, Julien Danjou wrote:
On Fri, Jul 12 2013, Alessandro Barabesi wrote:

 I have the following problems with query fields in filters.

 1) Filtering by metadata.size in v2/meters/image apparently is not 
 working. The following request returns also samples with metadata.size=0.


 GET http://10.10.10.10:8777/v2/meters/image


 {
  q: [{
  field: project_id,
  op: eq,
  value: 77b461539c8542909f67b29939ec87dd
  },
  {
  field: timestamp,
  op: ge,
  value: 2013-07-11T13:36:00
  },
  {
  field: timestamp,
  op: lt,
  value: 2013-07-11T13:39:00
  },
  {
  field: metadata.size,
  op: gt,
  value: 0

I suspect the gt operator is not working (it's probably using eq
given what you are getting). But certainly a bug.
I'd just remove this last query and see what you get with the first 3 queries.

-Angus

  }]
  
 }

 I am probably doing something wrong but I can't figure out what.

That seems correct from the top of my head. If that really doesn't 
work, feel free to open a bug.

 2) Filtering by counter_volume returns the folloving error message:

 error_message={debuginfo: null, faultcode: Client, 
 faultstring: Unknown argument: \counter_volume\: unrecognized 
 query field}

 Is this a bug or filtering by counter-volume is not allowed?

Try `volume' instead of `counter_volume'. But I am not sure it's 
currently allowed -- in that case opening a bug can be good idea too.

--
Julien Danjou
// Free Software hacker / freelance consultant // 
http://julien.danjou.info



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp