Thursday, 2013-09-12

*** zul has quit IRC00:17
*** fnaval_ has quit IRC00:18
*** zul has joined #openstack-metering00:26
*** flwang has quit IRC00:43
*** herndon has joined #openstack-metering00:47
*** fnaval_ has joined #openstack-metering00:48
*** llu has quit IRC01:04
*** nosnos has joined #openstack-metering01:22
*** flwang has joined #openstack-metering01:49
*** fandikurnia01 has joined #openstack-metering01:53
fandikurnia01hello all01:54
fandikurnia01i am install openstack using mirantis fuel01:54
fandikurnia01how to enable ceilometer service ?01:55
fandikurnia01on controller01:55
fandikurnia01thanks01:55
*** thomasm has joined #openstack-metering01:59
*** d34dh0r53 has joined #openstack-metering01:59
*** d34dh0r53 has quit IRC02:01
*** herndon has quit IRC02:01
*** herndon has joined #openstack-metering02:02
*** llu has joined #openstack-metering02:19
openstackgerritlitong01 proposed a change to openstack/ceilometer: refactor db2 get_meter_statistics method to support mongodb and db2  https://review.openstack.org/4617502:21
*** nati_ueno has quit IRC02:22
*** haomeng has joined #openstack-metering02:43
*** nosnos has quit IRC02:57
*** anteaya__ is now known as anteaya02:57
*** nosnos has joined #openstack-metering02:58
*** fnaval__ has joined #openstack-metering03:01
openstackgerritgordon chung proposed a change to openstack/ceilometer: Pecan assuming meter names are extensions  https://review.openstack.org/4614303:01
*** fnaval_ has quit IRC03:03
openstackgerritTerri Yu proposed a change to openstack/ceilometer: Add group by statistics examples in API v2 docs  https://review.openstack.org/4618103:06
*** fnaval__ has quit IRC03:27
*** fnaval_ has joined #openstack-metering03:27
*** anteaya has quit IRC03:33
*** shang has quit IRC03:37
openstackgerritA change was merged to openstack/ceilometer: validate counter_type when posting samples  https://review.openstack.org/4534403:53
*** SergeyLukjanov has joined #openstack-metering04:13
*** SergeyLukjanov has quit IRC04:14
*** SergeyLukjanov has joined #openstack-metering04:20
*** SergeyLukjanov has quit IRC04:30
*** SergeyLukjanov has joined #openstack-metering04:33
*** herndon has quit IRC04:38
*** SergeyLukjanov has quit IRC04:48
*** SergeyLukjanov has joined #openstack-metering04:57
*** SergeyLukjanov has quit IRC04:57
*** fnaval_ has quit IRC05:04
*** boris-42 has joined #openstack-metering05:22
openstackgerritLianhao Lu proposed a change to openstack/ceilometer: Use global openstack requirements  https://review.openstack.org/4618905:30
*** mmcardle has joined #openstack-metering05:41
*** SergeyLukjanov has joined #openstack-metering05:42
openstackgerritHaomeng,Wang proposed a change to openstack/ceilometer: Change resource.resource_metadata column to Text  https://review.openstack.org/4506405:50
openstackgerritJenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/4619406:02
*** nosnos has quit IRC06:17
*** mmcardle has quit IRC06:17
*** nosnos has joined #openstack-metering06:24
*** SergeyLukjanov has quit IRC06:43
openstackgerritLianhao Lu proposed a change to openstack/ceilometer: Correrctly output the sample content in file publisher  https://review.openstack.org/4620206:50
lsmolajd__, hello06:56
lsmolajd__, could you please look whether these are relevant bugs, or I am just missing something?06:57
lsmolajd__, https://bugs.launchpad.net/ceilometer/+bug/1223829 , https://bugs.launchpad.net/ceilometer/+bug/122429806:57
lsmolajd__, thank you very much06:58
silehtlsmola, bug/1224298 is relevant07:01
silehtI think bug/1223829 is not07:01
silehtthe project_id/owner_id at the root of the json, are the alarm owner, this isn't modifiable07:01
silehtbut If you want to set a alarm on the a particular project_id, you can:07:02
silehtuse matching_metadata : { 'project_id': '<UUID>' }07:02
silehtlsmola,  make sense ?07:02
silehtlsmola, but we are currenlty change a bit the alarm definition to make it more understandable07:03
lsmolasileht, ok07:03
lsmolasileht, so we should probably remove project_id and user_id from https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py#L4107:05
lsmolasileht, cool, are those matching_metadata documented somewhere?07:05
silehtlsmola, no because when a admin retrieve a alarm this is interesting to know the owner07:05
openstackgerritHarri Hämäläinen proposed a change to openstack/ceilometer: Catch exceptions from nova client in poll_and_publish.  https://review.openstack.org/4620307:05
lsmolasileht, cause i didn't notice there is some functionality connected to metadata07:06
silehtlsmola, I'm currently changing the matching_meta object by the Query object (already documented)07:06
silehtmatching_meta is a dict of key/value to match any sample field07:06
*** eglynn has quit IRC07:07
lsmolasileht, oh, interesting, I totally missed that07:07
lsmolasileht, thought for a while I can set alarms only for the whole project, cool, will try this out07:08
lsmolasileht, actually this is filter only from creation, right ? https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py#L4107:08
lsmolasileht, from/for07:08
silehtlsmola, no all sample fields07:09
lsmolasileht, it is not filtering what attributes the fetched object will have07:09
lsmolasileht, so I would remove that from the array, cause otherwise it is confusing, seem like it accepts user_id and project_id, but it is not07:12
silehtlsmola, on ceilometerclient you are right07:13
lsmolasileht, yes, I think I mention it in the bug also07:14
lsmolasileht, i will change it to that option then07:14
*** shardy_afk is now known as shardy07:15
lsmolasileht, hmm trying to find some description of matching_metadata, is there somewhere some more verbose docs? Could be maybe good to add more verbose description to V2 docs07:15
silehtlsmola, it will change to be Query object very soon07:15
lsmolasileht, maybe with some real example07:15
lsmolasileht, ok07:16
lsmolasileht, is there a bug or blueprint for this?07:16
lsmolasileht, I am obsessed with dependency tracking :-D07:16
silehtlsmola, I work on https://blueprints.launchpad.net/ceilometer/+spec/alarming-logical-combination07:17
silehtlsmola, the final v2 API alarm for havana https://wiki.openstack.org/wiki/Ceilometer/blueprints/alarm-api07:17
silehtlsmola, I just see, this is for horizon cool :)07:18
openstackgerritTerri Yu proposed a change to openstack/ceilometer: Add timestamp filtering cases in storage tests  https://review.openstack.org/4620607:19
lsmolasileht, oh yeah, I am already tracking those, cool07:20
lsmolasileht, I have changed the description of https://bugs.launchpad.net/ceilometer/+bug/1223829 , now it should be valid bug, right?07:22
openstackgerritA change was merged to openstack/ceilometer: Make the Swift-related doc more explicit  https://review.openstack.org/4583407:24
silehtlsmola,  perfect07:38
openstackgerritHarri Hämäläinen proposed a change to openstack/ceilometer: Catch exceptions from nova client in poll_and_publish  https://review.openstack.org/4620307:38
lsmolasileht, cool, thank you very much07:39
*** boris-42 has quit IRC07:55
*** Ruetobas has quit IRC08:04
*** SergeyLukjanov has joined #openstack-metering08:09
*** lexx has joined #openstack-metering08:26
*** mmcardle has joined #openstack-metering08:30
*** eglynn has joined #openstack-metering08:32
*** neumerance has joined #openstack-metering08:41
neumeranceI need some help08:41
neumeranceYoh Dhellman.08:42
*** taplax has joined #openstack-metering09:01
*** mmcardle has left #openstack-metering09:08
*** vvechkanov2 has quit IRC09:12
*** Joy has joined #openstack-metering09:21
*** boris-42 has joined #openstack-metering09:22
*** Joy has quit IRC09:23
*** Joy has joined #openstack-metering09:25
*** flwang has quit IRC09:51
*** lexx has quit IRC09:54
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: doc: fix storage backend features status  https://review.openstack.org/4445309:56
openstackgerritA change was merged to openstack/ceilometer: Update config generator  https://review.openstack.org/4588510:15
openstackgerritA change was merged to openstack/ceilometer: Include auth_token middleware in sample config  https://review.openstack.org/4588610:16
openstackgerritA change was merged to openstack/ceilometer: add tests for _query_to_kwargs func  https://review.openstack.org/4379610:21
openstackgerritA change was merged to openstack/ceilometer: Add docstrings to some methods  https://review.openstack.org/4614110:25
openstackgerritA change was merged to openstack/ceilometer: Fix handling of bad paths in Swift middleware  https://review.openstack.org/4598310:28
*** SergeyLukjanov has quit IRC10:36
*** SergeyLukjanov has joined #openstack-metering10:38
*** SergeyLukjanov has quit IRC10:54
*** flwang has joined #openstack-metering10:55
*** eglynn is now known as eglynn-lunch11:03
openstackgerritHarri Hämäläinen proposed a change to openstack/ceilometer: Catch exceptions from nova client in poll_and_publish  https://review.openstack.org/4620311:06
*** SergeyLukjanov has joined #openstack-metering11:07
*** shang has joined #openstack-metering11:09
*** neumerance has quit IRC11:20
openstackgerritA change was merged to openstack/ceilometer: Handle missing libvirt vnic targets!  https://review.openstack.org/4544411:20
*** fandikurnia01 has quit IRC11:28
openstackgerritCyril Roelandt proposed a change to openstack/python-ceilometerclient: Help messages: specify which options are required  https://review.openstack.org/4587011:32
*** chuckieb has joined #openstack-metering11:44
*** shang has quit IRC11:55
*** annegentle has quit IRC12:08
*** changbl has quit IRC12:27
*** shang has joined #openstack-metering12:30
*** fandikurnia01 has joined #openstack-metering12:40
*** fandikurnia01 has quit IRC12:49
*** herndon has joined #openstack-metering12:53
*** annegentle has joined #openstack-metering12:57
*** anteaya has joined #openstack-metering12:58
*** bpokorny has joined #openstack-metering12:58
*** annegentle is now known as annegentle_away13:02
*** sandywalsh has quit IRC13:08
*** gordc has joined #openstack-metering13:12
*** shang_ has joined #openstack-metering13:14
*** zul has quit IRC13:18
*** zul has joined #openstack-metering13:18
*** sandywalsh has joined #openstack-metering13:20
*** Ruetobas has joined #openstack-metering13:21
*** Ruetobas has quit IRC13:25
*** nosnos has quit IRC13:26
*** lnxnut has joined #openstack-metering13:29
*** Ruetobas has joined #openstack-metering13:32
thomasmHey all!13:33
*** eglynn-lunch is now known as eglynn13:35
*** Ruetobas has quit IRC13:36
*** changbl has joined #openstack-metering13:38
*** Ruetobas has joined #openstack-metering13:44
lnxnuthey13:44
*** shang_ has quit IRC13:48
lsmolaeglynn, hello, do you have a time for a quick question?13:49
eglynnlsmola: hi, sure!13:50
eglynnlsmola: shoot :)13:50
*** lnxnut has quit IRC13:50
lsmolaeglynn, I can't find alarm-history in ceilometer client, I guess it is not yet implemented right?13:51
eglynnlsmola: exactomundo!13:51
*** shang has quit IRC13:51
lsmolaeglynn, I have created a blueprint for that https://blueprints.launchpad.net/python-ceilometerclient/+spec/alarm-audit-client-api13:51
eglynnlsmola: (it's a pretty new feature, so the client hasn't caught up yet)13:51
*** shang has joined #openstack-metering13:51
eglynnlsmola: great, thanks!13:51
lsmolaeglynn, would you have time for that? or should I try to implement it?13:52
lsmolaeglynn, :-)13:52
openstackgerritDan Prince proposed a change to openstack/ceilometer: Handle inst not found exceptions in pollsters  https://review.openstack.org/4580213:52
eglynnlsmola: well it's on my list, but not at the top of the priority stack as yet ... so if you wanted to take a crack it, knock yourself out!13:52
eglynnlsmola: (otherwise I'll get to it eventually ... ;))13:53
lsmolaeglynn, ok cool, I am implementing the API on Horizon side, so once I get to it, I might do it :-)13:53
lsmolaeglynn, another question is about a query13:53
eglynnlsmola: great, thanks! (lemme know if you do start on it ...)13:53
eglynnlsmola: sure13:53
lsmolaeglynn, I do see that the type should serve for queries regarding state change, though I am not sure how this works13:54
eglynnlsmola: one sec13:55
lsmolaeglynn, can I for instance list all alarms, that were at least once in alarm state in e.g. last week?13:55
thomasmeglynn, Hey, what's the criteria for a bug fix to be backported to Grizzly as well? I think that resource metadata bug that just got into RC1 may also be present in Grizzly.13:55
thomasmbug fix that just got into RC1*13:55
thomasmAh, sorry. I'll ask again when y'all are done conversing. Don't want to confuse everyone.13:56
eglynnthomasm: do you mean what are appropriate fixes for backporting to stable/grizzly? https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes13:56
thomasmyeah13:57
thomasmOh, sweet. Thanks13:57
thomasmSo already a small bit of the fix is out, schema change in HBase13:59
openstackgerritgordon chung proposed a change to openstack/ceilometer: Pecan assuming meter names are extensions  https://review.openstack.org/4614314:03
thomasmeglynn, thanks - I'm not entirely sure it'd be a good idea with the pretty big get_resources query change and what-not.14:04
eglynnlsmola: sorry, back again ...14:05
eglynnlsmola: something like /v2/alarms/ALARM_ID/history?q.op=ge&q.op=le&q.op=eq&q.value=NOW&q.value=ONE_WEEK_AGO&q.value=state%20transition&q.field=timestamp&q.field=timestamp&q.field=type14:05
eglynnwill give you all the state transitions within the last week14:05
eglynnthen you'd have to filter on the details field for transitions into alarm (as opposed to transitions into OK or insufficient data)14:06
eglynnthomasm: normally the preference is for stable fixes to be self-contained and low-risk14:06
eglynnthomasm: ... but obviously that's the ideal, and the reality can be different14:07
eglynnthomasm: is the hbase change large and/or risky?14:07
thomasmeglynn, For sure. The bug is actually that the latest resource representation (from a sample) wasn't being returned from the resources API.14:07
thomasmeglynn, It's for all DB drivers14:07
eglynnthomasm: is the backport already proposed on gerrit, or something you're still actively working on?14:08
thomasmeglynn, I just tagged it as grizzly-backport-potential while I was making the fix for Havana-3. https://bugs.launchpad.net/ceilometer/+bug/120854714:09
* eglynn looking ...14:10
*** herndon has quit IRC14:10
eglynnthomasm: well at least it doesn't need a migration for sqlalchemy14:14
eglynnthomasm: (that would be a deal-breaker for stable, as we haven't pre-reserved any sa-migrate index slots for stable/grizzly)14:14
eglynnthomasm: however the backport may well be non-trivial as the storage driver code has had a fair bit of churn14:15
thomasmeglynn, That's what I was thinking14:15
thomasmeglynn, Like, it wasn't just a simple order by for SQLAlchemy, because there's undefined behavior when pulling non-aggregated values.14:15
thomasmMongoDB needed to be sorted on timestamp DESC, then it gave the latest14:16
eglynnthomasm: if you were interested in trying a cherry-pick onto stable, to see how messy it gets, that would be useful info14:16
thomasmeglynn, Yeah, I need to get my devstack set up with stable and give it a go.14:17
eglynnthomasm: cool14:17
lsmolaeglynn, ok meaning the grouping and filtering have to be done in python, ok I will try it14:17
thomasmeglynn, I would only be able to address the drivers I can actually get running, though. Heh? DB2 is out unless litong wants to help me out there.14:17
lsmolaeglynn, can I set you as the approver of the https://blueprints.launchpad.net/python-ceilometerclient/+spec/alarm-audit-client-api ?14:17
eglynnlsmola: done :)14:18
lsmolaeglynn, cool, thank you very much14:19
thomasmHBase is out because of schema changes anyway.14:19
gordcthomasm: db2 isn't in grizzly so no need to worry about that. :)14:19
thomasmgordc, Oh my? I don't know why I thought it was.14:19
eglynnlsmola: do you mean group by alarm ID? ... well the basic API structure requires that the history is queried per-alarm anyway14:19
thomasm<--- needs more coffee14:20
thomasmgordc, Thanks :P14:20
eglynnlsmola: ... whereas the filtering on target state being alarm being needed on the client side, yep14:20
gordcthomasm: that said, i'm not sure you'd be able to backport mongo either... your patch uses relies on aggregate and i'm pretty sure we didn't/couldn't use aggregate in grizzly.14:21
gordcthomasm: but yeah, have a look if you have time. i need some coffee too so i could be talking non-sense right now.14:22
lsmolaeglynn, I will get back all the alarm samples right? And I have to find the ones that had Alarm transitions14:23
eglynnlsmola: all the change events for a *particular* alarm that involve state transitions (as opposed to creation, deletion, or rule changes)14:24
*** annegentle_away is now known as annegentle14:24
lsmolaeglynn, oh I see, it is per alarm14:24
eglynnlsmola: /v2/alarms/ALARM_ID/history requests the change events for the alarm with ALARM_ID only14:25
*** fnaval_ has joined #openstack-metering14:25
eglynnlsmola: yep, exactly14:25
lsmolaeglynn, how hard would it be to make a query over multiple alarms?14:25
eglynn14:25
lsmolaeglynn, it is something similar as sample-api for samples14:25
eglynnlsmola: samples are serverd out per-meter, history events are per-alarm, that's just the way the API is constructed currently14:27
lsmolaeglynn, it will be very needed when i want to display e.g. health map of nova instances, wchich would obtain Alarms by several meter_names, group them by some metadata (nova instance id) and give me back number of Alarm transitions14:28
lsmolaeglynn, yeah jd__ is preparing sample-api, that will be query over multiple samples14:28
lsmolaeglynn, https://blueprints.launchpad.net/ceilometer/+spec/sample-api14:29
eglynnlsmola: well we would need to extend the alarm history API to be capable of querying over multiple alarms ... it's just not supported currently14:29
lsmolaeglynn, I guess alarm-history could use something similar14:29
eglynnlsmola: the other thing to note is that alarm rules can change over time14:29
lsmolaeglynn, yes, should i create a blueprint for this?14:29
eglynnlsmola: so for example I could have an alarm X that includes now includes matching metadata that identifies instance Y14:30
lsmolaeglynn, hmm, we could group alarms by more attributes then14:30
eglynnlsmola: it could undergo a state transition on that basis, but then be changed to refer to instance Z14:31
lsmolaeglynn, what information does the sample contain?14:31
eglynnlsmola: when you say sample, do you mean alarm history event?14:32
lsmolaeglynn, if it has only reference to the alarm, that could be a problem14:32
lsmolaeglynn, yes14:32
*** yanghy has joined #openstack-metering14:33
lsmolaeglynn, if the event actually store the metadata + the conditions, I could theoretically group by that14:33
eglynnlsmola: it currently just includes ... event_id, alarm_id, type, detail, user_id, project_id, on_behalf_of14:34
lsmolaeglynn, lets say it would be enough for me to know, how many alerts of some meters, did the instance have over some time14:34
eglynnlsmola: again that could be tricky, as the instance can be identified in multiple ways14:35
eglynnlsmola: e.g. an alarm could refer to it directly by resource_id14:35
lsmolaeglynn, the instance should be probably identified in matching_metadata, right?14:35
eglynnlsmola: or indirectly via some other metadata14:35
eglynnlsmola: for example, heat autoscaling alarms identify groups of instances on the basis of their user metadata14:36
lsmolaeglynn, hmm14:36
eglynnlsmola: so just knowing the instance ID is not enough to find all matching alarm14:36
eglynns14:37
lsmolaeglynn, though then the alarm is not tied directly to one resource right?14:37
eglynnlsmola: exactly14:37
lsmolaeglynn, I think it could be usable14:37
eglynnlsmola: for the "wide dimensioning" case, a single alarm may refer to statistics averaged over many instances14:38
eglynnlsmola: e.g. all instances booted from a certain image, all instances with certain user metadata set etc.14:38
lsmolaeglynn, if we want a health map chart showing resources, we must have alarms tied to resources14:38
lsmolaeglynn, then we could show health map on resource aggregate level, etc.14:38
eglynnlsmola: alarms are currently not neccessarily tied to individual resources14:39
lsmolaeglynn, yes, though I would filter only those that are, if I want to show chart with resources14:40
lsmolaeglynn, that could work right?14:40
eglynnlsmola: it would take some non-trivial cross-querying of nova and ceilometer APIs to figure out which instances certain alarms apply to14:41
lsmolaeglynn, it would be enough to look for alarms that have resource_id in their metadata, that would give alarm tied to that resource right?14:41
eglynnlsmola: yes, those map one-to-one to some individual resource14:41
eglynnlsmola: (which would be an instance where the target meter is instance-related)14:42
lsmolaeglynn, then I could have different charts for projects, resource_aggregates, etc.14:42
eglynnlsmola: (or could be some other type of resource, e.g. an image or a volume, for other meter types ...)14:42
*** SergeyLukjanov has quit IRC14:42
eglynnlsmola: what do you mean by resource_aggregates?14:43
lsmolaeglynn, yes, then I could just filter that by meter_names connected to nova, and I have nova instance health map, right?14:43
lsmolaeglynn, sorry host aggregates etc14:43
lsmolaeglynn, though host aggregates are not in ceilometer, so it degrades to list of resources,  right?14:44
eglynnlsmola: I'm not sure that ceilo currently preserves the metadata identifying the host aggregate14:45
lsmolaeglynn, no, I think not14:45
eglynnlsmola: yep, identifying alarms that refer one-to-one to instances should be possible14:45
lsmolaeglynn, there is only resource, user, project14:45
*** herndon has joined #openstack-metering14:46
lsmolaeglynn, ok should i write this into bp, or you will?14:46
eglynnlsmola: but non-trivial for alarms that refer to groups of instances14:46
eglynnlsmola: lets start with a discussion page on the wiki14:46
eglynnlsmola: can you capture your initial requirements there14:47
eglynnlsmola: then we can decide where we need to go from there, massage it into a BP etc.14:47
eglynnlsmola: make sense?14:49
lsmolaeglynn, yes, but that query would target the group directly, e.g. health map or projects or users14:50
lsmolaeglynn, well the horizon (and probably the tuskar) will probably need this14:51
eglynnlsmola: which query exactly do you mean there? ... "that query would target the group directly"14:51
lsmolaeglynn, it's the same reason as for the-sample api, the chart would have to do to many queries to ceilometer and it's too slow, it needs to happen in one query14:51
eglynnlsmola: sure, I understand that's the desire14:52
lsmolaeglynn, yeah like if the alarm is tied e.g. to user (and all of his resources) I could fetch those kind of alarms to show user based health map14:52
lsmolaeglynn, it would probably need to add also all ids of the resources of the user, but that would still be around two queries14:54
lsmolaeglynn, ok, wiki it is14:54
eglynnlsmola: yep, get your ideal requirements up on the wiki, then we can discuss what's acheivable14:55
lsmolaeglynn, now how do I create a new wiki page? :-D14:55
lsmolaeglynn, oh, it has separate sign in :-D14:56
eglynnlsmola: just point your broswer at https://wiki.openstack.org/wiki/Ceilometer/foobar14:56
eglynnlsmola: yeah, usual launchpad business to log in14:57
lsmolaeglynn, oh cool14:59
*** dhellmann_ is now known as dhellmann15:00
*** yanghy has quit IRC15:18
*** yanghy has joined #openstack-metering15:19
*** SergeyLukjanov has joined #openstack-metering15:21
openstackgerritA change was merged to openstack/ceilometer: Use global openstack requirements  https://review.openstack.org/4618915:37
lsmolaeglynn, I have filled some basic user stories https://wiki.openstack.org/wiki/Ceilometer/blueprints/alarm-audit-api-group-by#The_user_stories15:45
lsmolaeglynn, is it enough to talk just about user stories, or i should make a proper draft of API, and the database implementation?15:46
eglynnlsmola: user stories are a good starting point, I'll review it later on today and get back to you with comments15:47
lsmolaeglynn, ok cool, I will be going home in few minutes, I would think some more about the user stories tomorrow any feedback will be much appreciated15:51
lsmolaeglynn, that you for your help :-)15:52
lsmolaeglynn, that/thank :-D15:52
eglynnlsmola: cool ... BTW which TZ are you based in?15:52
eglynnlsmola: (I'm in GMT ...)15:52
nealphjd__: is there a utility to generate a message on the queue that the dispatchers will pick up? sandywalsh helped me find send-counter yesterday, but I believe it only pushes through the sample pipeline...15:53
lsmolaeglynn, I am UTC +1 or 215:53
lsmolaeglynn, Brno :-)15:53
eglynnlsmola: cool, that was my guess ;)15:53
sandywalshapmelton1: dragondm do we have any utils for stuffing notifications on the queue that nealph might be able to use?15:54
apmelton1sandywalsh: I never got around to cleaning this up, but it can be set up to throw notifications on rabbit15:55
apmelton1https://github.com/ramielrowe/notif-gen15:55
lsmolaeglynn, cool, thanks again for your help :-) see you tomorrow15:56
nealphsandywalsh: thanks! and btw, re: my question late yesterday on publisher output? see my bug https://bugs.launchpad.net/bugs/122419015:56
nealphapmelton1: sweet! thanks...I'll take a look.15:56
nealphsandywalsh: or rather, don't bother answering the question, because apparently it's a bug. :)15:57
sandywalshnealph: <reading>15:57
sandywalshnealph: yeah, definitely a bug. a str() missing :)16:00
sandywalshnealph: sent you a side channel msg16:00
*** Ruetobas has quit IRC16:01
*** boris-42_ has joined #openstack-metering16:02
*** Ruetobas has joined #openstack-metering16:04
*** boris-42_ has quit IRC16:04
*** yanghy has quit IRC16:05
*** boris-42 has quit IRC16:06
dragondmsandywalsh: not at the moment :P16:07
*** Ruetobas has quit IRC16:08
*** Ruetobas has joined #openstack-metering16:14
*** changbl has quit IRC16:14
*** eglynn has quit IRC16:30
openstackgerritlitong01 proposed a change to openstack/ceilometer: refactor db2 get_meter_statistics method to support mongodb and db2  https://review.openstack.org/4617516:39
*** ruhe has joined #openstack-metering16:58
*** Bada has joined #openstack-metering17:05
openstackgerritA change was merged to openstack/ceilometer: Update openstack.common.policy from oslo-incubator  https://review.openstack.org/4521017:07
*** nati_ueno has joined #openstack-metering17:07
openstackgerritA change was merged to openstack/ceilometer: Alarm history storage implementation for sqlalchemy  https://review.openstack.org/4524417:10
*** nati_ueno has quit IRC17:12
*** ruhe has quit IRC17:13
thomasmyay!17:41
*** SergeyLukjanov has quit IRC17:42
*** thomasm has quit IRC17:42
BadaHi guys,i'm following the Manual installation doc of ceilometer. Where is it written to create a ceilometer user ?17:42
*** Bada has quit IRC17:42
*** Bada has joined #openstack-metering17:43
*** SergeyLukjanov has joined #openstack-metering17:44
*** boris-42 has joined #openstack-metering17:53
*** nati_ueno has joined #openstack-metering18:00
*** eglynn has joined #openstack-metering18:00
*** thomasm has joined #openstack-metering18:04
*** herndon has quit IRC18:08
*** ruhe has joined #openstack-metering18:12
*** shaneduan has quit IRC18:29
*** shaneduan has joined #openstack-metering18:43
*** shaneduan is now known as Guest9176918:43
*** Bada has quit IRC18:44
*** Bada has joined #openstack-metering18:45
openstackgerritA change was merged to openstack/ceilometer: Add group by statistics examples in API v2 docs  https://review.openstack.org/4618118:46
openstackgerritA change was merged to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/4619418:48
*** jtran has joined #openstack-metering18:49
openstackgerritA change was merged to openstack/ceilometer: Catch exceptions from nova client in poll_and_publish  https://review.openstack.org/4620318:51
openstackgerritA change was merged to openstack/ceilometer: run-tests: fix MongoDB start wait  https://review.openstack.org/4564218:51
*** Guest91769 is now known as shaneduan18:56
*** lnxnut_ has joined #openstack-metering18:57
*** changbl has joined #openstack-metering19:05
*** herndon has joined #openstack-metering19:06
*** ruhe has quit IRC19:08
*** toddmck has joined #openstack-metering19:13
*** gordc has quit IRC19:32
*** zul has quit IRC19:45
*** SergeyLukjanov has quit IRC19:54
*** zul has joined #openstack-metering19:59
*** sandywalsh has quit IRC20:20
*** lnxnut_ has quit IRC20:30
openstackgerritA change was merged to openstack/ceilometer: Improve libvirt vnic parsing with missing mac!  https://review.openstack.org/4544620:38
*** Bada has quit IRC21:07
*** rrao is now known as rrao-away21:15
*** rrao-away is now known as rrao_away21:17
*** rrao_away is now known as zz_rrao21:18
*** zz_rrao is now known as rrao21:18
*** shang has quit IRC21:38
*** toddmck has left #openstack-metering21:49
*** eglynn has quit IRC21:49
*** d34dh0r53 has joined #openstack-metering21:49
*** d34dh0r53 has quit IRC21:51
*** thomasm has quit IRC21:53
*** boris-42 has quit IRC21:57
*** changbl has quit IRC22:00
*** bpokorny has quit IRC22:04
*** shang has joined #openstack-metering23:02
*** zaneb has joined #openstack-metering23:12
*** zbitter has quit IRC23:14
*** herndon has quit IRC23:22
openstackgerritNachi Ueno proposed a change to openstack/ceilometer: Add ElasticSearch Support for ceilometer  https://review.openstack.org/4638323:28
openstackgerritNachi Ueno proposed a change to openstack/ceilometer: Add ElasticSearch Support for ceilometer  https://review.openstack.org/4638323:35
*** shang has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!