Wednesday, 2014-01-29

*** yassine has quit IRC00:02
*** jmckind has quit IRC00:15
*** dperaza has quit IRC00:17
*** ryanpetrello has quit IRC00:33
*** _ruhe is now known as ruhe00:43
*** ryanpetrello has joined #openstack-ceilometer00:45
*** gordc has quit IRC00:46
*** ryanpetrello has quit IRC01:00
*** xianghui has joined #openstack-ceilometer01:07
*** ruhe is now known as _ruhe01:48
openstackgerritlitong01 proposed a change to openstack/python-ceilometerclient: add notification alarm  https://review.openstack.org/6947401:51
*** ryanpetrello has joined #openstack-ceilometer01:55
openstackgerritlitong01 proposed a change to openstack/ceilometer: add notification alarm  https://review.openstack.org/6947302:14
openstackgerritlitong01 proposed a change to openstack/ceilometer: add notification alarm  https://review.openstack.org/6947302:18
*** xianghui has quit IRC02:19
*** xmltok has quit IRC02:22
*** flwang has joined #openstack-ceilometer02:27
*** _ruhe is now known as ruhe02:28
*** ryanpetrello has quit IRC02:31
*** xianghui has joined #openstack-ceilometer02:32
*** ryanpetrello has joined #openstack-ceilometer02:32
*** gordc has joined #openstack-ceilometer02:39
*** ryanpetrello has quit IRC02:54
*** gordc has quit IRC03:23
*** sayali has quit IRC03:25
*** ok_delta has joined #openstack-ceilometer03:50
*** ok_delta__ has joined #openstack-ceilometer03:50
openstackgerritYuuichi Fujioka proposed a change to openstack/ceilometer: Implements monitoring-network  https://review.openstack.org/6047304:22
*** dperaza has joined #openstack-ceilometer04:53
*** sayali has joined #openstack-ceilometer05:05
*** sayali_ has joined #openstack-ceilometer05:05
*** sayali_ has quit IRC05:06
*** ryanpetrello has joined #openstack-ceilometer05:12
*** dperaza has quit IRC05:16
*** ok_delta__ has quit IRC05:18
*** ok_delta has quit IRC05:18
*** SergeyLukjanov_ is now known as SergeyLukjanov05:28
*** krast has quit IRC05:35
openstackgerritYuuichi Fujioka proposed a change to openstack/ceilometer: Implements monitoring-network-from-opendaylight  https://review.openstack.org/6389005:38
*** sayali has quit IRC05:42
*** xianghui has quit IRC05:57
*** AMike has quit IRC05:59
openstackgerritJenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/6280806:03
*** xianghui has joined #openstack-ceilometer06:04
*** ildikov_ has quit IRC06:10
*** AMike has joined #openstack-ceilometer06:20
*** AMike has joined #openstack-ceilometer06:21
*** ryanpetrello has quit IRC06:23
*** sayali has joined #openstack-ceilometer06:26
*** ildikov_ has joined #openstack-ceilometer06:46
*** sayali has quit IRC06:52
*** SergeyLukjanov is now known as SergeyLukjanov_06:58
*** sayali has joined #openstack-ceilometer06:59
*** nsaje has joined #openstack-ceilometer07:44
*** nsaje has quit IRC07:45
*** nsaje_ is now known as nsaje07:45
*** rwsu has quit IRC07:46
*** _nadya_ has joined #openstack-ceilometer07:48
*** xianghui has quit IRC07:49
*** rwsu has joined #openstack-ceilometer07:50
*** xianghui has joined #openstack-ceilometer08:00
*** _nadya_ has quit IRC08:03
*** sayali_ has joined #openstack-ceilometer08:12
*** _nadya_ has joined #openstack-ceilometer08:12
*** sayali has quit IRC08:15
*** _nadya_ has quit IRC08:21
*** yassine has joined #openstack-ceilometer08:50
*** urulama has joined #openstack-ceilometer08:54
*** SergeyLukjanov_ is now known as SergeyLukjanov08:56
*** eglynn has joined #openstack-ceilometer09:01
*** ildikov_ has quit IRC09:05
eglynnurulama, nsaje: good morning gentlemen!09:06
urulamaeglynn: morning :D09:06
eglynnurulama, nsaje: I see you guys are interested in time-constrained alarms09:06
eglynni.e. https://blueprints.launchpad.net/ceilometer/+spec/time-constrained-alarms09:07
nsajeeglynn: good morning eoghan!09:07
urulamaeglynn: yes09:07
urulamaif it ok with you09:07
eglynnthat's great, have at it!09:07
eglynnI'll review your etherpad09:07
eglynni.e. https://etherpad.openstack.org/p/alarm_with_time_constraints ... this morning and leave any feedback there09:07
urulamagreat09:08
urulamawe're doing some hpc stuff and these constraints will come handy ...09:08
*** ildikov_ has joined #openstack-ceilometer09:09
eglynncool ... you can just assign the BP to yourself in launchpad09:09
eglynn... and update the Implementation field to Started to relfect the fact that you're actively working on it09:09
eglynnurulama, nsaje: thank you sirs!09:09
urulamaeglynn: will be our pleasure (i hope) :D09:10
*** SergeyLukjanov is now known as SergeyLukjanov_09:25
silehteglynn, I haven't fully read this blueprint (alarm_with_time_constraints) but I think have made a similar proposition at the summit https://blueprints.launchpad.net/ceilometer/+spec/alarm-over-time09:26
silehthttps://wiki.openstack.org/wiki/Ceilometer/blueprints/alarm-over-time09:26
silehtThe approch differ in adding a new field 'time_contraints' or adding a new alarm type09:30
eglynnsileht: yeah, I think we ended up with two BPs for pretty much the same thing09:30
eglynnsileht: ... the one I filed came out of this session at summit https://etherpad.openstack.org/p/icehouse-summit-ceilometer-future-of-alarming09:30
eglynnsileht: ... but seems like there was a pre-existing BP already filed09:31
silehteglynn, In all case, I'm ok with both approch, and I have no time to code this now, so don't worry09:33
eglynnsileht: cool enough!09:33
nsajesileht, eglynn : They look different to me though, sileht's triggers an alarm based on time, while eglynn's still triggers it based on threshold/meta - the time is just a constraint, not the actual trigger09:34
* eglynn looks again09:34
silehtnsaje, sure but my plan is to use combination alarm to constraint the threshold alarm with the time alarm09:34
nsajesileht: ah, ok09:35
silehtbut having the time constraint in the base alarm json permit a more efficient evaluation I think09:36
silehteglynn, nsaje I have marked my BP supperseded by the Approved one09:36
eglynnsileht: thank you sir!09:36
*** SergeyLukjanov_ is now known as SergeyLukjanov09:41
eglynnjd__: good morning sir!09:45
jd__hi eglynn09:45
eglynnjd__: so I see https://blueprints.launchpad.net/ceilometer/+spec/central-agent-improvement was bumped to juno09:45
eglynn(due to unreadiness of Tooz)09:46
eglynnseems https://blueprints.launchpad.net/ceilometer/+spec/rebase-alarm-partition-coordination will also have to move out to juno09:46
* jd__ puppy eyes09:46
eglynn(given that it's got the same dependency on a generic oslo co-ordination service)09:46
jd__you're right09:46
jd__changed09:47
eglynnjd__: thanks!09:47
llujd__: ping09:51
jd__llu: ?09:51
llujd__: just saw your proposal about the resource loader thing. Are you suggesting that we add another item resource_loader into the pipeline, besides the 'resources'?09:52
jd__llu: yes09:52
jd__well feel free to have a counter proposal, it's just my wake-up's idea09:53
llui'm just wondering if there is a way to combine resources resources loader into a single pipeline item09:54
lluresources and resource loader09:54
jd__we can consider that if there's :// it's an url otherwise a loader I guess09:59
llujd__: well, what if we need to pass some additional params to the loader?10:01
lluhow about we choose a special type of url for loaders, for those URL using 'loader' as scheme, we treat it like a loader10:03
llue.g. loader://nova_vms, loader://ironic_api?param1=value1&param2=value210:03
llufor URL with other schemes, we just treat it like a final target endpoint10:04
* jd__ thinks10:07
jd__llu: why not10:07
llujd__: sorry for my poor english understanding. is it a yes or no to the 'loader://'? (why not? or why not something else?)10:10
jd__ah sorry, that's a yes10:12
jd__llu: http://idioms.thefreedictionary.com/why+not :)10:12
lluok. thanks for your input. need to go to middle school english class :(10:13
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: WIP: Add test for check sync models and migrations  https://review.openstack.org/6967410:15
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: WIP: Add test for check sync models and migrations  https://review.openstack.org/6967410:17
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: samples: fix test case status code check  https://review.openstack.org/6964810:26
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: storage: bases of a Cassandra driver  https://review.openstack.org/6277910:26
openstackgerritA change was merged to openstack/ceilometer: Remove unused db engine variable in api  https://review.openstack.org/6934010:28
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: storage: bases of a Cassandra driver  https://review.openstack.org/6277910:30
openstackgerritEugeniya Kudryashova proposed a change to openstack/python-ceilometerclient: Use HTTPClient from common Oslo code  https://review.openstack.org/6893910:50
eglynnurulama, nsaje: FYI I've put some initial feedback on https://etherpad.openstack.org/p/alarm_with_time_constraints10:58
urulamaeglynn: tnx, will look at it soon.11:01
urulamaeglynn: btw, i guess i don't have the rights to change the BP assignee ...11:02
eglynnurulama: np, now assigned to uros-jovanovic11:05
openstackgerritA change was merged to openstack/ceilometer: Update dev docs to include notification-agent  https://review.openstack.org/6725211:20
*** zul has quit IRC11:20
*** zul has joined #openstack-ceilometer11:24
*** ityaptin has joined #openstack-ceilometer11:32
*** xianghui has quit IRC12:31
* eglynn is about to pull the trigger on python-ceilometerclient 1.0.912:41
eglynn... with the following tag description http://fpaste.org/72701/90999234/raw/12:41
eglynn... if you want anything else included, speak now or forever hold your peace! ;)12:42
eglynn... going, going ...12:45
eglynn... gone!12:46
*** yassine has quit IRC12:47
*** yassine has joined #openstack-ceilometer12:48
*** yassine has quit IRC12:48
*** yassine has joined #openstack-ceilometer12:48
*** yassine has quit IRC12:48
*** yassine has joined #openstack-ceilometer12:49
eglynn1.0.9 tarball: http://tarballs.openstack.org/python-ceilometerclient/python-ceilometerclient-1.0.9.tar.gz12:49
eglynnalso up on pypi as always: https://pypi.python.org/pypi/python-ceilometerclient/1.0.912:49
*** prad has joined #openstack-ceilometer13:01
*** yassine has joined #openstack-ceilometer13:05
nsajeeglynn: would you please take a look at https://blueprints.launchpad.net/ceilometer/+spec/alarm-notification-details ?13:07
eglynnnsaje: will do13:07
*** jdob has joined #openstack-ceilometer13:08
openstackgerritPradeep Kilambi proposed a change to openstack/ceilometer: Fix measurement docs to correctly represent Existance meters  https://review.openstack.org/6967513:10
openstackgerritPradeep Kilambi proposed a change to openstack/ceilometer: Fix docs on what an instance meter represents  https://review.openstack.org/6674613:11
eglynnnsaje: yes, I think including reason_data in addition to the existing reason string in the alarm notification would be a good idea13:19
eglynn... so basically number samples outside threshold, most recent datapoint, that kind thing right?13:19
eglynn*kind of thing13:19
nsajeexactly13:19
nsajeI have a use case currently where I have to parse these things from the reason string :)13:20
eglynncool, knock yourself out!13:20
eglynnnsaje: ... obviously though the reason_data format would be different for combination alarms as opposed to threshold-oriented alarms13:20
nsajeeglynn: indeed, it is in the BP13:21
eglynnnsaje: cool, so it is!13:22
eglynnnsaje: ... I guess the list of alarms that fired is only strictly required in the OR case?13:23
eglynnnsaje: ... though yeah, you're right, probably best to include in all cases for consistency13:24
nsajeeglynn: the reason string currently contains all the alarms, not just the ones that fired13:25
nsajeeglynn: and it says "at least one of {alarms} fired"13:25
*** sayali_ has quit IRC13:25
*** kwhitney has joined #openstack-ceilometer13:25
eglynnnsaje: OK, so maybe an opportunity to improve that13:26
nsajeeglynn: but I think it would be good if only the one fired was listed13:26
nsajeeglynn: agreed!13:26
eglynnnsaje: ... as the only new info is which alarms actually fired in the OR case13:26
eglynnnsaje: cool13:26
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: WIP: Add test for check sync models and migrations  https://review.openstack.org/6967413:31
*** vrovachev has joined #openstack-ceilometer13:50
*** eglynn is now known as eglynn-lunch14:07
openstackgerritIlya Tyaptin proposed a change to openstack/ceilometer: Skip unit tests with mongo or db2 when environment variables aren't set  https://review.openstack.org/6964414:10
*** ryanpetrello has joined #openstack-ceilometer14:21
*** jmckind has joined #openstack-ceilometer14:36
*** tongli has joined #openstack-ceilometer14:37
*** eglynn-lunch is now known as eglynn14:43
*** SergeyLukjanov is now known as SergeyLukjanov_a14:46
*** SergeyLukjanov_a is now known as SergeyLukjanov_14:47
gibieglynn: hi!14:48
eglynngibi: hey14:48
gibieglynn: first of all thanks for the positive comment on the complex query patch.14:48
eglynngibi: np!14:48
* gibi trying to gather his thoughts about distinct...14:49
eglynngibi: ... you had some hold-overs from yesterday's discussion on multiple groupbys in a single query?14:49
eglynnk14:49
gibieglynn: jepp14:49
gibieglynn: actually we have some thoughts on the distinct itself14:49
eglynnk, shoot14:50
ildikov_eglynn: this was your API proposal: GET /v2/meters/instance/statistics?aggregate-by=distinct&aggregate-on=resource_id&period=p14:51
eglynnildikov_: roughly speaking yes14:51
ildikov_eglynn: and the mapping on db level: func.count(distinct(models.Meter.resource_id)).label('distinct')14:51
eglynn(modulo some tidy up on the query param names, e.g. s/aggregate-by/aggregateby/14:52
eglynnyes, for the sqlalchemy driver14:52
ildikov_eglynn: I just copied it from the log, it is not the main point :)14:52
*** SergeyLukjanov_ is now known as SergeyLukjanov14:53
eglynndifferent storage driver, different mapping ... extra logic in the reduce function for mongodb for ex.14:53
*** SergeyLukjanov is now known as SergeyLukjanov_a14:53
ildikov_the point here is, that this API and db mapping is applicable only for the data that is needed for the dashboards14:53
*** ruruj has joined #openstack-ceilometer14:54
eglynnare we sure no other client of ceilo would want to disctinct values?14:54
rurujhi14:54
ildikov_eglynn: I mean, this mapping is now limited to the count() aggregate and it is important there that we filter to resource_id and project_id14:54
ildikov_eglynn: it does not seem to be generic14:54
gibieglynn: as ildikov_ said this distinct query is quite special we havent found any other query where the distinct helps14:54
rurujregarding autoscaling...how can I evalutate only the ceilometer's data of those instances belonging to the stack instead of the data from all instances?14:54
eglynnildikov_: so the idea is that aggregate-on being parameterized makes it generic14:55
eglynnildikov_: one sec14:55
*** SergeyLukjanov_a is now known as SergeyLukjanov_14:55
ildikov_eglynn: do you have another query example for distinct?14:55
gibieglynn: if you make distinct on resource_id then we can only apply count on the result14:56
gibieglynn: at least max, min avg, does not have real meaning on resource_id14:56
gibieglynn: if you apply distinct on counter_volume then again avg, max and min does not give to valuable result14:57
gibis/to/too/14:57
eglynngibi: no the intention is that aggregate-on is a parameter *only* for the aggregate-by function14:58
eglynngibi: not for all functions14:58
eglynngibi: another example would be quantile computation14:58
eglynnsay GET /v2/meters/cpu_util/statistics?aggregate-by=quantile&aggregate-on=0.99&period=p14:58
eglynnthat would compute the 99th percentile for cpu_util in each period P14:59
*** SergeyLukjanov_ is now known as SergeyLukjanov14:59
eglynnbut not max(0.99) or sum(0.99) which obviously has no meaning14:59
eglynnthe idea is individually *parameterized* aggregate functions15:00
*** sayali has joined #openstack-ceilometer15:00
gibieglynn: I guess quantile needs two parameter 0.99 and a counter_volume15:00
* gibi is not good at math :)15:01
* ildikov_ neither :S15:01
eglynnmy thought was that for numeric aggregates (max, sum, avg, quantile, stddev), the counter_volume is implicit15:01
eglynnas it only ever makes sense the calculate say the standard deviation of the volumes15:01
eglynnnot the timestamps or the meter_name or the resource_metadata15:02
eglynnruruj: that's done on the basis of resource metadata identifying the instance as members of an autoscaling group15:02
gibieglynn: OK. Then in the the distinct example query the distinct function would get also two parameter the value of the aggregate_on field and the counter_volume. However it does not make too much sense as here we only need the aggregate_on15:03
eglynngibi: no, the counter-volme is not relevant to distinct15:03
ildikov_eglynn: it seems that distinct is odd here15:04
gibieglynn: yes, distinct is quite different from quantile15:04
eglynngibi: the idea is that *some* aggregate functions require *some* parameters to guide their actions15:04
eglynn(not that *all* aggregate functions need to be parameterized)15:04
ildikov_eglynn: I mean that mapping on the db level is one good solution for Horizon, but I do not see how it would be usabale in general15:04
ildikov_eglynn: as for the other aggregates you mentioned, I totally agree, those look good15:05
eglynnwhy not usable in general?15:05
*** boris-42 has quit IRC15:05
eglynndo you think that horizon is the only usecase for distinct counting?15:06
gibieglynn: distinct is not a numeric aggregate function, it can be applied on any type of fields. In the other hand when distinct is applyed then there is only count() meaningfull on the result15:06
gibieglynn: this makes distinct is so specific15:06
gibis/is//15:06
ildikov_eglynn: I do not see too many use cases right now for distinct counting, but I can be wrong here15:06
eglynnTBH distinct wasn't my main interest in adding parameterizable aggregates15:07
rurujeglynn, can I explicit differentiate the instances from the horizon web gui when launch a new stack?15:07
eglynnruruj: I can't remember if horizon displays resource metadata15:08
eglynnruruj: you may have to use the nova CLI15:08
eglynnruruj: ... isn't the stack name also embedded in the generated server names?15:08
gibieglynn: we dont have problems with your idea of parameterized aggregates. I like that proposal. But distinct does not fitt well in it.15:08
ildikov_eglynn: here comes my idea :)15:09
rurujeglynn, yes it is .. :|15:09
ildikov_eglynn: we were talking about meters yesterday for supporting the needs of Horizon15:09
ildikov_eglynn: I had a wild thought yesterday, that we could create a new meter for this need actually15:10
ildikov_eglynn: we could use the notifications about instances (create, delete) or have a pollster maybe15:10
eglynnildikov_: hmmm, seems like meter proliferation15:11
eglynnildikov_: I mean we already have the necessary data in the metering store15:11
rurujbut when I launch a new stack the total cpu utilization is calculated among all instances :|15:11
openstackgerritA change was merged to openstack/ceilometer: Use swift master  https://review.openstack.org/6815015:12
*** boris-42 has joined #openstack-ceilometer15:12
eglynnruruj: have you access to the ceilometer CLI?15:12
rurujeglynn, yes15:12
*** vrovachev has left #openstack-ceilometer15:12
eglynnruruj: can you run ceilometer alarm-list and ceilometer alarm-show -a $ALARM_ID for the high CPU alarm for your stack?15:13
eglynnfolks, I'm gonna have to drop for 10-15 mins for an internal huddle15:13
ildikov_eglynn: I was thinking about leaving the db out of the game, as it is an extra load to regenerate this in every iteration for Horizon15:13
eglynnildikov_: can you hold that thought for a few mins?15:14
*** eglynn is now known as eglynn-call15:14
ildikov_eglynn-call: sure :)15:15
rurujeglynn-call, alarm-list output: http://pastebin.com/eUgUhkW7 and alarm-show : http://pastebin.com/8AATbSZZ15:18
ityaptinsileht, hi! I want to implement hbase ttl from bp https://blueprints.launchpad.net/ceilometer/+spec/db-ttl which is assigned to you.15:19
silehtityaptin, this BP is already implemented and only cover mongodb and sqlalchemy15:20
silehtityaptin, you can create a new one for hbase15:20
silehtityaptin, I'm pretty sure jd__ will approved it15:20
silehtjd__, ?15:20
jd__sure15:21
ityaptinsileht, jd__, it's great)15:21
ityaptinjd__, bp for this - https://blueprints.launchpad.net/ceilometer/+spec/hbase-db-ttl15:26
jd__ityaptin: you're good15:26
*** _nadya_ has joined #openstack-ceilometer15:27
ityaptinjd__, thanks)15:27
rurujeglynn-call, and if it may be useful, this is my template http://pastebin.com/UissYAEk15:28
*** zul has quit IRC15:30
*** zul has joined #openstack-ceilometer15:30
*** gordc has joined #openstack-ceilometer15:35
eglynn-callruruj: you're missing something like "matching_metadata: {'metadata.user_metadata.server_group': 'ServerGroup'}" in the CPUAlarmHigh and CPUAlarmLow15:37
*** sayali has quit IRC15:37
*** sayali has joined #openstack-ceilometer15:37
*** eglynn-call is now known as eglynn15:37
rurujeglynn, uh...thank you!! I'll try to fix!15:38
*** sayali has quit IRC15:38
eglynnruruj: also you'll need ...15:38
eglynn  repeat_actions: True15:38
*** sayali has joined #openstack-ceilometer15:39
eglynnotherwise the lack of continuous notification will cuase the heat cooldown state machine to never progress to actual scaling15:39
eglynngibi, ildikov_: sorry 'bout that, back now15:39
rurujeglynn, repeat_actions...uhm..thanks15:40
ildikov_eglynn: np!15:40
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: POC: Sync models to actual PostgreSQL db state  https://review.openstack.org/6988315:40
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: POC: Add test for check sync models and migrations  https://review.openstack.org/6967415:40
eglynnildikov_: so the alternative proposal is a completely new meter, instances_per_tenant?15:40
ildikov_eglynn: kind of yes15:41
eglynnwhat happens if the horizon folks come back tomorrow and ask for instances_per_user instead? ;)15:41
gibieglynn: or instance_count:active, instance_count:stopped ... etc15:41
eglynni.e. it seems like a new meter is quite static15:42
eglynn(WRT changing requirements)15:42
eglynnwhereas a query could be reformulated15:42
eglynnin this case groupby=project_id could be replaced by groupby=user_id15:43
ildikov_eglynn: you have a point here, it seems to be a usable information, so I thought to reduce the number of periodic queries on the db15:45
eglynnildikov_: wouldn't we have to go to the DB anyway to retrieve the special-purpose meter?15:46
ildikov_eglynn: the distinct itself to be shown on the API also does not seem to be a completely valid solution in my opinion, so I was thinking about hiding it behind a meter15:46
eglynn(though, yeah, it would be a much cheaper periodic DB access to grab the counter value on a specific meter)15:46
openstackgerritRyan Petrello proposed a change to openstack/ceilometer: Correct a misuse of RestController in the Event API.  https://review.openstack.org/6988515:47
ildikov_eglynn: in my idea is to generate the value according to the incoming data (from notifications or pollster) and then the query would target a simple meter without the need of an aggregation15:48
openstackgerritRyan Petrello proposed a change to openstack/ceilometer: Correct a misuse of RestController in the Event API.  https://review.openstack.org/6988515:48
eglynnildikov_: the notifications are received per-instance, as opposed to per-tenant15:50
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: POC: Sync models to actual PostgreSQL db state  https://review.openstack.org/6988315:50
openstackgerritVictor Sergeyev proposed a change to openstack/ceilometer: POC: Add test for check sync models and migrations  https://review.openstack.org/6967415:50
eglynnildikov_: (so I'm not sure you could count the number of instances per-tenant in a notification handler)15:50
eglynnildikov_: so you'd be taking about a pollster that calls into the nova servers API with all_tenants=True and then calculates the total for each tenant?15:51
gibieglynn: yes, it should be a pollster15:52
ildikov_eglynn: yes, a pollster sounds reasonable here15:52
eglynngibi, ildikov_: a pollster shifting through a potentially large number of servers to calculate the per-tenant totals?15:53
ildikov_eglynn: sorry, yesterday the light was suddenly turned on in my head, so I do not have a deeply worked out solution, just the base idea, which I thought to validate here if it could work or not15:53
gibieglynn: actually yes, we should get all Server state from the nocva15:54
gibis/nocva/nova15:54
eglynngibi: well we could get these data from nova, but having a pollster doing the "slicing and dicing" on a potentially large dataset seems a bit wrong15:55
eglynn(... by "slicing and dicing" I mean the totalling up per-tenant or per-user or whatever)15:57
gibieglynn: I accept that it is a big no-no. :)15:58
ildikov_eglynn: yes it seems to be a wrong direction, I haven't calculated with the fact that we do not have the latest value of that meter on the pollster level15:58
ildikov_eglynn: s/pollster/notification/15:58
eglynnildikov_: a-ha, ok, I see what you mean ... yeah without that being directly available from nova, there's a bit of a burden on the pollster15:59
eglynnsorry folks, I'm running up against the shot-clock here16:00
eglynnas always ;)16:00
gibieglynn: thanks for your help16:00
*** _nadya_ has quit IRC16:00
gibieglynn: as always :)16:00
eglynnso to sum up ...16:01
eglynn1. maybe the special-purpose meter isn't a great idea from the PoV of the analytic burden placed on the pollster16:01
ildikov_eglynn: another option is to create a kind of aggregated meter to hide the distinct maybe, but continue it another time then :)16:01
eglynn2. but ildikov_ & gibi still not loving the idea of distinct as a paremeterizable aggregate function16:01
gibieglynn: yes, agree with your sum up16:02
eglynngibi, ildikov_: cool, let's ruminate on the options a bit and chat again later in the week16:02
gibieglynn: OK. Thank you again.16:02
ildikov_eglynn: that sounds good16:03
ildikov_eglynn: many-many thanks :)16:03
eglynnildikov_: np!16:03
*** yassine has quit IRC16:12
*** yassine has joined #openstack-ceilometer16:13
*** sayali_ has joined #openstack-ceilometer16:22
*** sayali has quit IRC16:25
openstackgerritEugeniya Kudryashova proposed a change to openstack/python-ceilometerclient: Use HTTPClient from common Oslo code  https://review.openstack.org/6893916:26
*** eglynn is now known as eglynn-afk16:27
*** SergeyLukjanov is now known as SergeyLukjanov_16:34
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Update oslo  https://review.openstack.org/6990316:43
openstackgerritJenkins proposed a change to openstack/ceilometer: Updated from global requirements  https://review.openstack.org/6990516:57
*** SergeyLukjanov_ is now known as SergeyLukjanov17:04
*** ildikov_ has quit IRC17:14
*** xmltok has joined #openstack-ceilometer17:25
*** SergeyLukjanov is now known as SergeyLukjanov_a17:29
*** SergeyLukjanov_a is now known as SergeyLukjanov_17:30
*** jaypipes_ has joined #openstack-ceilometer17:37
*** jaypipes_ has quit IRC17:37
*** SergeyLukjanov_ is now known as SergeyLukjanov17:38
*** ruruj has quit IRC17:51
*** ildikov has joined #openstack-ceilometer18:13
*** doug-fish has joined #openstack-ceilometer18:42
doug-fishHi Ceilometer people, I'm trying to advise translators on the meaning of "Duration of network" which is in http://docs.openstack.org/developer/ceilometer/measurements.html#network-neutron18:45
doug-fishDoes it mean the amount of time from when the network was started until now?18:46
gordcdoug-fish: you might not want to use 'Duration of xyz'18:54
gordcwe're fixing that note to something more accurate here: https://review.openstack.org/#/c/69675/318:54
openstackgerritRyan Petrello proposed a change to openstack/ceilometer: Correct a misuse of RestController in the Event API.  https://review.openstack.org/6988518:54
doug-fishgordc:  thanks!  I'll look at the update.18:55
gordcdoug-fish: np. not sure what term we'll finalise on but it definitely won't be 'Duration'18:56
openstackgerritRyan Petrello proposed a change to openstack/ceilometer: Correct a misuse of RestController in the Event API.  https://review.openstack.org/6988518:57
*** yassine has quit IRC19:02
*** yassine has joined #openstack-ceilometer19:03
*** yassine has quit IRC19:04
*** yassine has joined #openstack-ceilometer19:04
*** sayali_ has quit IRC19:07
*** yassine has quit IRC19:09
dhellmannis anyone else seeing intermittent errors running the unit tests?19:32
gordcdhellmann: off master?19:38
dhellmanngordc: yeah19:39
dhellmanngordc: I fixed the testtools dependency and downgraded tox, so these are just ceilometer's tests failing19:39
dhellmanntests.test_bin.BinSendCounterTestCase.test_send_counter_run19:39
dhellmanntests.test_utils.TestUtils.test_dict_to_kv19:39
dhellmannthey vary19:39
gordchmm. i'll give it a try. i just realised when i was cleaning up python packages i deleted tox so need to fix that before i can try.19:40
*** _nadya_ has joined #openstack-ceilometer19:41
dhellmanngordc: I wonder if these are somehow related to testing library changes19:48
*** DanD_ has joined #openstack-ceilometer19:48
*** jmckind has quit IRC19:49
dhellmanngordc: ah, I can reproduce a failure in test_bin.py reliably19:52
gordcdhellmann: i actually get quite a few failures... not sure if it's related to all the system changes i've been making though.19:55
dhellmanngordc: yeah, I just rebuilt my dev vm so I had similar questions19:56
gordcdhellmann: do you get errors relating to alarms?19:57
dhellmanngordc: yeah, I was seeing some of those, too19:57
dhellmannless frequently than some of the others19:58
dhellmanntests.test_bin.BinSendCounterTestCase.test_send_counter_run fails every time, with "ImportError: No module named ceilometer.openstack.common" from the script being run out of bin19:58
gordci guess it's a bad thing we both were playing around with our systems. feels like blind leading the blind.lol19:58
dhellmannheh20:00
gordcdhellmann: i don't have the test_bin error (maybe i just don't see it)20:01
gordcdhellmann: i did get less errors this second pass i ran... maybe related to new tox? i just noticed it got bumped to 1.7 (which i downloaded)20:01
dhellmanngordc: and now I'm not seeing the alarm errors20:01
dhellmannfantastic, this passes: tox -e py27 -- ceilometer/tests/test_bin.py20:03
dhellmannbut without the arg to run just the one test, that test fails20:03
gordchmm. i got more alarm errors the third time running tests.20:06
dhellmannI can't make testr show me any info, so I've resorted to writing a temporary file from within the test20:08
tongli@dhellmann, I did exactly the same. can anyone tell me how to show some varilables when run_tests.sh?20:11
dhellmanntongli: try setting OS_STDOUT_CAPTURE=120:13
dhellmannthat didn't work in my case, but maybe it will for you20:14
tongli@dhellmann, thanks, let me try that.20:14
*** jdob has quit IRC20:15
tongli@dhellmann, that did not work for me.20:21
dhellmanntongli: sorry :-(20:22
tongli@dhellmann, yeah, I did what you did, write to a file. so annoying.20:22
dhellmanntongli: I've been able to make it work sometimes20:23
tongli@dhellmann, without writing to a file?20:23
openstackgerritlitong01 proposed a change to openstack/python-ceilometerclient: add notification alarm  https://review.openstack.org/6947420:25
openstackgerritDoug Hellmann proposed a change to openstack/ceilometer: Force import path to be right in test_bin.py  https://review.openstack.org/6996320:28
dhellmanngordc: ^^20:28
gordcdhellmann: i've resorted to reverting back to a snapshot i took 4 months ago.  maybe starting from there will help me.20:29
gordcwill give a try once i get it back up to date20:30
*** _nadya_ has quit IRC20:30
dhellmanngordc: ok20:31
dhellmanngordc: I ran the tests several times without any failures after making that change20:31
dhellmannI have no idea why that might have made the alarm tests fail20:31
tongli@dhellmann, Doug, I run run_tests.sh without problem. I have latest code.20:34
dhellmanntongli: :-/20:34
tongli@dhellmann, I did not have your 69963 patch.20:35
tongli./run_tests.sh run ok, tox -e py27 ok as well.20:35
*** jmckind has joined #openstack-ceilometer20:42
openstackgerritRyan Petrello proposed a change to openstack/ceilometer: Correct a misuse of RestController in the Event API  https://review.openstack.org/6988520:46
ryanpetrellosubmitting a patch that passes Python tests, but realizing jenkins failed you because the commit message has a period at the end: http://i.imgur.com/IiMp5.gif20:48
*** _nadya_ has joined #openstack-ceilometer20:50
*** terriyu has joined #openstack-ceilometer20:52
*** _nadya_ has quit IRC20:52
*** nadya has joined #openstack-ceilometer20:58
*** nadya is now known as Guest8307620:58
*** Guest83076 is now known as _nadya_20:59
*** eglynn-afk is now known as eglynn21:04
*** _nadya__ has joined #openstack-ceilometer21:05
*** _nadya_ has quit IRC21:07
chmouelryanpetrello: i may use that on osreactions :)21:13
ryanpetrellodo it :)21:13
chmouelryanpetrello: do you have a twitter handle so i can give you credit for?21:13
ryanpetrello@ryanpetrello :)21:13
chmouelnice and easy cool21:13
*** _nadya__ has quit IRC21:13
chmouelryanpetrello:  on another note a lot of projects have removed that don't allow a period in title rule, i think ceilometer should do too21:15
jd__honestly we don't encounter that often :)21:27
*** lsmola has joined #openstack-ceilometer21:41
*** urulama has quit IRC21:47
*** Alexei_987 has quit IRC22:00
*** tongli has quit IRC22:00
*** SergeyLukjanov is now known as SergeyLukjanov_22:01
*** lsmola has quit IRC22:05
ryanpetrellojd__: yea, only dummies like me :)22:08
*** gordc has quit IRC22:18
*** jmckind has quit IRC22:21
*** ildikov has quit IRC22:34
*** ryanpetrello has quit IRC23:17
*** prad__ has joined #openstack-ceilometer23:25
*** prad has quit IRC23:27
*** prad__ is now known as prad23:27
*** terriyu has quit IRC23:35
*** prad has quit IRC23:43
*** doug-fish has quit IRC23:53

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