Thursday, 2014-01-16

openstackgerritA change was merged to stackforge/pycadf: Python 3: update setup.cfg to advertise python 3 compatibility
*** flwang has quit IRC00:03
*** herndon has quit IRC00:05
*** flwang has joined #openstack-ceilometer00:19
*** xuhanp has quit IRC00:31
openstackgerritLuis A. Garcia proposed a change to openstack/ceilometer: Sync gettextutils from Oslo
openstackgerritLuis A. Garcia proposed a change to openstack/ceilometer: Re-enable lazy translation
*** gordc has joined #openstack-ceilometer01:01
*** boris-42 has quit IRC01:05
*** gordc has quit IRC01:09
*** gordc has joined #openstack-ceilometer01:10
openstackgerritliusheng proposed a change to openstack/python-ceilometerclient: return sample info when creating sample with CLI
openstackgerritliusheng proposed a change to openstack/python-ceilometerclient: return sample info when creating sample with CLI
*** xuhanp has joined #openstack-ceilometer01:37
*** gordc has quit IRC01:45
*** gordc has joined #openstack-ceilometer02:05
*** gordc has quit IRC02:05
*** prad has joined #openstack-ceilometer02:14
*** herndon has joined #openstack-ceilometer02:30
*** flwang has quit IRC03:04
openstackgerritLianhao Lu proposed a change to openstack/ceilometer: Add resource loader support
openstackgerritLianhao Lu proposed a change to openstack/ceilometer: Added hardware agent's inspector and snmp implementation
openstackgerritLianhao Lu proposed a change to openstack/ceilometer: Added hardware pollsters for the central agent
*** prad has quit IRC03:48
*** herndon has quit IRC04:19
*** boris-42 has joined #openstack-ceilometer04:30
*** SergeyLukjanov_ is now known as SergeyLukjanov04:59
*** asalkeld has quit IRC05:51
*** asalkeld has joined #openstack-ceilometer06:04
*** flwang has joined #openstack-ceilometer06:14
*** asalkeld has quit IRC06:15
openstackgerritJenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex
*** SergeyLukjanov is now known as SergeyLukjanov_06:22
*** chmouel has quit IRC06:24
*** chmouel has joined #openstack-ceilometer06:27
*** nadya_ has joined #openstack-ceilometer06:51
*** asalkeld_ has joined #openstack-ceilometer06:56
*** Alexei_987 has left #openstack-ceilometer07:06
*** asalkeld_ has quit IRC07:20
*** nadya_ has quit IRC07:30
*** asalkeld_ has joined #openstack-ceilometer07:33
*** boris-42 has quit IRC07:43
*** ildikov_ has quit IRC07:45
*** ildikov_ has joined #openstack-ceilometer08:05
*** asalkeld_ has quit IRC08:36
*** yfujioka has joined #openstack-ceilometer08:52
*** Alexei_987 has joined #openstack-ceilometer09:00
*** _ruhe is now known as ruhe09:03
nprivalovajd__, hi! last time you did some magic and make Yassine Lamgarchal available. could you please do it again :)?09:09
jd__nprivalova: it seems he's not arrived at his office yet, I've just mailed him so it join when he's ready :)09:10
nprivalovajd__, ok, thank you!09:11
*** yassine has joined #openstack-ceilometer09:18
*** ityaptin has joined #openstack-ceilometer09:44
*** RemyS has joined #openstack-ceilometer09:47
*** flwang has quit IRC09:58
*** ruhe is now known as ruhe_away09:59
*** boris-42 has joined #openstack-ceilometer10:03
*** ruhe_away is now known as _ruhe10:09
*** Alexei_987 has quit IRC10:11
*** Alexei_987 has joined #openstack-ceilometer10:12
*** sayali has joined #openstack-ceilometer10:15
*** sayali has quit IRC10:17
*** sayali has joined #openstack-ceilometer10:18
*** sayali_ has joined #openstack-ceilometer10:18
*** RemyS has quit IRC10:18
*** sayali has quit IRC10:19
Alexei_987sileht: ping10:22
silehtAlexei_987, pong10:23
Alexei_987sileht: do you have time to talk about this sqla bug?10:24
silehtAlexei_987, yes10:24
Alexei_987oslo.db bug*10:24
Alexei_987sileht: so how do you plan to fix it?10:24
Alexei_987sileht: we discussed this issue yesterday and we think that we should not apply fix in oslo10:25
*** SergeyLukjanov_ is now known as SergeyLukjanov10:25
Alexei_987sileht: and try to fix it locally10:25
silehtAlexei_987, I have started to split integration test to create on tox env per DB backend10:26
Alexei_987sileht: :( I think that's a bad approach10:26
Alexei_987sileht: it will cause tests to run much slower10:26
Alexei_987sileht: cause of env creation10:26
silehtAlexei_987, yes but some people want to add other real database testing for cassanda, hbase, etc...10:27
Alexei_987yes and we can do this cleanly with testscenarios10:27
silehtAlexei_987, and we cannot run all the databases at the same time in one VM10:27
Alexei_987why not?10:27
Alexei_987connection url doesn't have to point to the same VM10:27
Alexei_987and storage can be located elsewhere10:28
silehtAlexei_987, not for gate10:28
Alexei_987sileht: and how separate envs will help with that?10:29
silehtAlexei_987, if we start only one scenario in a VM we can that will reduce the resource usage of the VM10:30
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Update oslo
Alexei_987sileht: I'm afraid that resource usage will be even bigger cause of env setup :(10:31
Alexei_987env setup takes much more time than actual tests run10:32
silehtAlexei_987, for local testing that can be tweaked to have a common virtualenv10:34
silehtAlexei_987, but I agree for gate it will take more time :(10:34
Alexei_987sileht: so maybe we should try to find better approach?10:35
*** SergeyLukjanov is now known as SergeyLukjanov_10:35
Alexei_987sileht: do we have other problems except this oslo.db bug preventing us from using multiple backends inside of one process?10:36
silehtAlexei_987, the problem to run all scenarios in one VM, is that we must change the oslo.db singleton API to a better API10:36
Alexei_987sileht: this can be fixed I have a plan for a workaround10:36
silehtAlexei_987, how , I really interresting :)10:36
Alexei_987sileht: we could manage engine creation on our own10:37
Alexei_987sileht: basically we do it for nosql backends10:37
Alexei_987sileht: if we'll avoid this oslo.db get_session stuff we won't have any problems10:37
Alexei_987sileht: it should only require some changes in our impl_sqla10:38
Alexei_987I can make a draft patch for this if you are interested10:38
silehtAlexei_987, that will duplicate code for for engine/session configuration10:39
Alexei_987sileht: some of the code can be reused so I don't think that this will be a problem10:39
Alexei_987sileht: I don't plan to write a new sqla wrapper10:39
Alexei_987we could bypass oslo.db singleton by calling it's cleanup method10:40
Alexei_987so the plan is: 1) use oslo.db to create engine 2) save engine locally 3) delete ref in oslo.db (this is needed to prevent engine disconnect) 4) call oslo.db.cleanup()10:41
Alexei_987in such way we'll be able to have multiple connections at the same time10:41
Alexei_987sileht: ^ what do you think?10:42
silehtI'm not sure it works many parts of the oslo.db code use the CONF.database.connection, what happend if this one change at run time10:43
Alexei_987sileht: well I'll make a patch ready and we'll see10:45
Alexei_987in production env connection string should not change10:45
Alexei_987so it will only work for tests10:45
*** SergeyLukjanov_ is now known as SergeyLukjanov10:51
*** _ruhe is now known as ruhe10:52
openstackgerritMehdi Abaakouk proposed a change to openstack/ceilometer: Implement the /v2/samples/<sample-id> API
*** xuhanp has quit IRC11:03
*** yfujioka has quit IRC11:14
*** nsaje has quit IRC11:17
*** nsaje_ has joined #openstack-ceilometer11:17
*** asalkeld has joined #openstack-ceilometer11:22
nprivalovansaje_, hi! How are you? Yesterday we had a conversation about tempest+ceilometer stuff. We still have a chance to commit Will you have time to rewrite it using ?11:30
*** sayali_ has quit IRC12:03
*** kwhitney has left #openstack-ceilometer12:06
Alexei_987sileht: can I ask you a stupid question?12:23
openstackgerritDirk Mueller proposed a change to openstack/python-ceilometerclient: Remove dependencies on pep8, pyflakes and flake8
Alexei_987jd__: are you around?12:32
openstackgerritDirk Mueller proposed a change to openstack/ceilometer: Remove dependencies on pep8, pyflakes and flake8
*** ruhe is now known as ruhe_away12:53
*** ruhe_away is now known as ruhe12:54
*** sayali has joined #openstack-ceilometer12:55
*** sayali_ has joined #openstack-ceilometer12:55
*** prad has joined #openstack-ceilometer12:59
*** prad has quit IRC13:04
*** julienvey_ has joined #openstack-ceilometer13:06
*** flwang has joined #openstack-ceilometer13:15
jd__Alexei_987: more or less?13:25
*** prad has joined #openstack-ceilometer13:29
*** xuhanp has joined #openstack-ceilometer13:30
*** jdob has joined #openstack-ceilometer13:30
*** prad has quit IRC13:34
*** ruhe is now known as ruhe_away13:41
*** ruhe_away is now known as ruhe13:44
*** jaypipes has joined #openstack-ceilometer13:53
Alexei_987jd__: wanted to ask do you know why we use subratransactions in sqla ceilometer storage method "create_or_update"?13:59
jd__Alexei_987: no idea13:59
Alexei_987jd__: Ok thanks have to figure out this somehow13:59
*** ruhe is now known as ruhe_away13:59
*** eglynn has joined #openstack-ceilometer14:00
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Update oslo
openstackgerritEoghan Glynn proposed a change to openstack/ceilometer: Exclude weak datapoints from alarm threshold evaluation
eglynnjd__: quick question on the new notification agent?14:25
jd__eglynn: shoot14:25
eglynnjd__: so seems logical that each message on a topic is only delivered to a single ceilometer subscriber14:26
eglynn(otherwise we wouldn't be able to horizontally scale the ceilo notification agent)14:26
eglynnyep, so what if something outside ceilo also wanted visibility on these notifications?14:27
jd__"I'm glad you asked this"14:27
jd__in this case your notification sender must configure several notification topics14:27
jd__to publisher the messages to different queues14:27
eglynnthe sender in this case being the openstack services?14:28
jd__nova, glance, whatever14:28
jd__e.g. notification_topics=notifications,notification-for-somebody-else14:28
jd__as Ceilometer by default consumes for notifications.*14:29
jd__(well, .info only actually..)14:29
eglynna-ha, I see, so those config options are generally lists?14:29
jd__topicS :-)14:30
eglynnjd__: cool, thank you sir!14:31
jd__you're welcome :)14:31
eglynnjd__: one other quickie while I've got you ...14:32
eglynnjd__: ... possible to resurrect back into icehouse-2 d'ya think?14:32
jd__eglynn: is the a review yet? I'm still lagging a bit14:32
eglynnjd__: yep ...
eglynn(... just proposed a little while ago)14:33
jd__you're back on i214:33
eglynnjd__: ... and again, thank you sir!14:34
jd__np :)14:34
*** SergeyLukjanov is now known as SergeyLukjanov_a14:35
*** prad has joined #openstack-ceilometer14:42
nprivalovajd__, I cannot run tests on real mysql, right?14:46
jd__nprivalova: we have a patch for that but it's not working yet14:47
nprivalovajd__, maybe you help me then... I run "tox -epy27" where can I find sqlite file? (imagine that it will not be removed after test run)14:49
jd__nprivalova: it runs in memory actually14:52
jd__so you wan't find any file, sorry14:52
nprivalovajd__, thank you :) Hope I will find another way to check my aggregation. I wanted to see tables for sure. Will try just to read from new tables14:55
jd__nprivalova: yeah unfortunately it's kind of tricky to debug that way indeed14:56
jd__nprivalova: what you can try to do is to specify a sqlite:// URL with a file, run just ONE test and add a sleep(100000) to stop the test and have time to copy the SQL file :)14:57
jd__just a hackish way of getting what you want :)14:57
nprivalovajd__, I tried this scenario. but didn't find a file anyway14:58
jd__nprivalova: you need to change the sqlite:// url in ceilometer/tests/ to point to a file14:58
jd__as sqlite:// means memory14:58
nprivalovajd__, ye, I did everything you described. test contains the line database_connection = 'mysql://localhost', maybe I should remove it too?14:59
*** boris-42 has quit IRC15:00
*** julienvey_ has quit IRC15:00
*** SergeyLukjanov_a is now known as SergeyLukjanov15:02
*** sayali has quit IRC15:03
pradcould anyone tell me why jenkins is failing my patch on this error
pradthis is suppose to be a cherry pick from master so shouldn't be any different and master merged successfully15:05
nprivalovaprad, rebase on master15:05
pradah ok, will give that a try thx15:06
nprivalovaprad, it should be fixed by
pradnprivalova: just to make sure you're suggesting rebase my stable/havana with this in master?15:07
pradnprivalova: the failure is in stable/havana15:07
nprivalovaprad, hmm, please give a link on review15:08
pradnprivalova: this is just a back port from master15:09
pradthere is another stable/havana patch failing similarly as well
pradso i'm hoping its not just me15:10
openstackgerritBalazs Gibizer proposed a change to openstack/ceilometer: Implements "not" operator for complex query
nprivalovaprad, I see.  Looks like keystone-client was backported too. Some change there causing the problem. Let me find the commit15:11
pradnprivalova: thx15:12
*** kwhitney1 has quit IRC15:12
nprivalovaprad, check
nprivalovaprad, "Looks like it's due to updated python-keystoneclient. With python-keystoneclient 0.4.1 works just fine. Keystoneclient 0.4.2 introduces include_service_catalog option in commit a97b293501fa504dd154fc921809a40bc2a34049."15:12
*** kwhitney1 has joined #openstack-ceilometer15:12
pradnprivalova: ah i see15:13
nprivalovaprad, you need to be sure that  keystone client was not backported to stable/havana. if it is you need to backport too15:13
*** jmckind has joined #openstack-ceilometer15:15
ityaptinjd__ hi! I again want ask to have a look blueprint
ityaptinjd__, if you have any issues about it, tell me, please.15:17
jd__ildikov_: k, looks good to me, can you set the implementation status and possibly a milestone target?15:18
ildikov_jd__: does this "looks good to me " refer to my complex query implementation? ;)15:22
* jd__ runs15:24
ildikov_jd__: any +2 is welcomed :)15:24
jd__I know I really want to review code but they won't let me15:24
nprivalovawho? we may beat them15:26
ildikov_jd__: who should I force to let you?15:26
pradcan i get some eyes on and please :)15:26
gibiI guess we can form a team :)15:26
jd__ah, if I only knew who they are… ;-)15:27
ildikov_nprivalova: +115:27
*** gordc has joined #openstack-ceilometer15:34
*** herndon has joined #openstack-ceilometer15:36
pradnprivalova: would "instance name" be more apt? the data i see doesn't seem like description of the instance15:37
openstackgerritA change was merged to openstack/ceilometer: Fix use the fact that empty sequences are false
*** julienvey_ has joined #openstack-ceilometer15:41
nprivalovaprad, here should be a description what meter is about...  let me think15:41
pradnprivalova: ok i'm open to suggestions.. if description seems best fit i'm ok with it, but curious how it fits the instance:<type>  .. would we tell use its a instance description with type ?15:46
nprivalovaprad, as I understand instance:<type> is the same as instance but with explicit type. I may suggest to wait for more variants from team15:50
pradsure, np i'll wait for some more input15:51
*** boris-42 has joined #openstack-ceilometer15:59
*** sayali has joined #openstack-ceilometer16:03
*** ruhe_away is now known as ruhe16:04
*** sayali has quit IRC16:07
*** sayali has joined #openstack-ceilometer16:08
*** xuhanp has quit IRC16:09
openstackgerritA change was merged to openstack/ceilometer: tests: pass /dev/null as config for mongod
openstackgerritA change was merged to openstack/python-ceilometerclient: Remove unused imports
*** SergeyLukjanov is now known as SergeyLukjanov_16:24
jd__ildikov_: around?16:29
*** julienvey_ has quit IRC16:29
*** SergeyLukjanov_ is now known as SergeyLukjanov16:30
ildikov_jd__: yes16:31
jd__ildikov_: quick question, why jsonschema?16:31
*** julienvey_ has joined #openstack-ceilometer16:32
ildikov_jd__: it was mentioned by boris-4216:32
jd__ildikov_: ok16:32
ildikov_jd__: it makes the validation of the query much easier16:32
boris-42ildikov_ +116:32
jd__ildikov_: definitely16:33
ildikov_jd__: and also more generic as the tree traversal is not a hard coded mechanism anymore in case of the validation16:33
boris-42ildikov_ btw sorry didn't have time to look one more time on path..16:33
jd__my main issue is that we're trying to regroup schema validation around one library, and not jsonschema in particular that is16:33
ildikov_jd__: if you check the patch for field_name validation it shows well, that adding this functionality was a few lines16:34
jd__so I'm not sure both dhellmann and I are going to be totally happy about that particular choice, this is something we should discuss I guess16:34
jd__ildikov_: yeah you definitely want a validation library, it's just the lib choice that I might not be comfortable with16:34
boris-42jd__ imho16:35
boris-42jd__ we shouldn't make our own oslo.jsonschema16:35
boris-42jd__ this is well know and great lib16:35
jd__boris-42: we're not16:35
ildikov_jd__: which would be the lib?16:35
jd__boris-42: we also have other things than JSON to validate, so jsonschema does sounds like it's the best choice16:35
jd__ildikov_: Colander looks like a good candidate for now16:36
boris-42jd__ imho we should have only one format to valide16:36
jd__ildikov_: I'd love to hear your opinion if you have time to take a look since you used jsonschema already16:36
boris-42jd__ and it's JSON16:36
jd__boris-42: looks like your opinion and reality do not agree then :)16:36
boris-42jd__ idk why we should validate soothing else then json?16:37
boris-42jd__ why we can't remove support of XML and use only json16:37
boris-42jd__ ?16:37
jd__boris-42: because everything is not JSON?16:37
ildikov_jd__: I saw your Colander patch, I did not have time to have a deeper look into it, so I did not know that it will be suitable for us or no16:37
jd__boris-42: there are other places than API where we need to validate data16:37
boris-42jd__ why this data is not in JSON?16:37
boris-42jd__ probably it should be refactored?16:38
jd__ildikov_: yeah fair enough, it's just that if you have time to think about it and feed us with your opinion that would be valuable16:38
boris-42jd__ to switch to rally16:38
boris-42jd__ to json**16:38
jd__boris-42: in a database? :)16:38
boris-42jd__ use mongo+)16:38
jd__ /kick boris-4216:38
ildikov_jd__: I will have a deeper look, I saw that it seems to support our json format, but I cannot tell you now this for sure16:39
jd__ildikov_: thanks16:39
ildikov_jd__: I also wondering if Colander will be good also for field_name validation or it will check only the syntax of the incoming query16:41
ildikov_jd__: and we also had some issues to figure out how to implement the recursion into the json schema, I have to investigate this part in COlander also16:42
ildikov_jd__: what is the timing for Colander, is there any targeted release?16:42
jd__ildikov_: if you have time to check if there's any big problem with all that would definitely helps16:42
jd__ildikov_: there's no timing per se, we're just trying to stop the usage of millions of libs16:43
jd__rationalizing a bit16:43
ildikov_jd__: I would be happy if there wouldn't be a need for converting our incoming filter expressions to string just because wsme does not support complex structures in that way, as we would like to use it16:45
ildikov_jd__: of course we cannot change right now, but for the future that would be better16:45
jd__ildikov_: well that's part of my patch with Colander, I'd like to build a WSME/Colander layer too16:46
ildikov_jd__: we've found a bug report regarding to recursion in Colander, we will check the details and the mentioned workaround16:46
*** sayali has quit IRC16:46
jd__ildikov_: basically if we can leverage _one_ lib everywhere to validate data, it'd be a huge win16:46
ildikov_jd__: does this mean that the other projects, who's already using json schema will also change to the common way?16:47
openstackgerritJohn Herndon proposed a change to openstack/python-ceilometerclient: Update client to display data type of traits
openstackgerritEoghan Glynn proposed a change to openstack/ceilometer: Exclude weak datapoints from alarm threshold evaluation
herndoneglynn: ceilometer client review is posted:
eglynnherndon: cool, looking ...16:50
herndonit is dependent on this review from ceilometer:
jd__ildikov_: AFAIK the ones using it are doing so in the API part and should/were supposed to switch to WSME at some point16:51
ildikov_jd__: just to see it clearly, as at this point I may get lost a bit, the WSME/Colander layer you mentioned means something like the first layer of the API is WSME and the next layer downwards would be Colander?16:55
jd__ildikov_: I meant Pecan/Colander, sorry16:56
ildikov_jd__: ah, ok, np :)16:56
ildikov_jd__: how should we proceed now with our bp implementation for i-2?16:57
jd__ildikov_: wait16:58
jd__ildikov_: but I gave you some hints to keep you busy though ;-)16:58
ildikov_jd__: can leave the current implementation as is and trying Colander on a separate branch to see how it works for more complex structures and then we can discuss the outcome of our trial?16:58
jd__ildikov_: definiteively16:59
jd__or definitively16:59
jd__"good idea!"16:59
ildikov_jd__: LOL :)16:59
jd__ildikov_: I am definitely not asking you to rewrite everything from scratch with $OTHERLIB16:59
jd__we just need a bit of (your) time to see if our ultimate solution to use one lib (i.e. Colander) to do the same job over and over is viable17:00
jd__if you can help us with that and find out that you could, it would be awesome17:00
*** ruhe is now known as ruhe_away17:00
ildikov_jd__: well, our query expression is an excellent candidate for this trial17:01
jd__ildikov_: I think so too17:01
*** SergeyLukjanov is now known as SergeyLukjanov_17:01
ildikov_jd__: can our current bp implementation stay in the picture for i-2?17:02
jd__ildikov_: sure, though honestly the code looks big and complicated I'm not sure it'll be entirely reviewed by then17:03
ildikov_jd__: if we change only the validation part it will be invisible for outside, if the test are still green after changing to Colander :)17:03
jd__but I'll leave it planned for i2 anyway17:03
jd__ildikov_: I nod!17:03
ildikov_jd__: the patch sets are vaible one-by-one17:03
ildikov_jd__: I mean the first one is big because of the validation itself and it works for samples17:04
jd__ildikov_: yeah, you might get a few merged but not everything -- I don't know, I'm just don't want you to have too big expectations :)17:04
ildikov_jd_: the second one is reusing the whole common code for alarms, and third is also for alarm history17:04
ildikov_jd__: the forth is a small one, only for field_name validation17:05
ildikov_and the other can be retargeted for i-3 as the first 4 gives a quite well usabale functionality17:05
ildikov_jd__: s/other/others/17:06
ildikov_jd__: if the first 4 could be merged, we would happly test Colander ;)17:08
jd__ildikov_: well if you can test in the meantime that'd be even more awesome :) but I get your point17:08
jd__I can't promise anything, I'm just a reviewer :)17:09
openstackgerritJohn Herndon proposed a change to openstack/ceilometer: Return trait type from Event api
*** ruhe_away is now known as _ruhe17:10
ildikov_jd__: but maybe you can ask the other reviewers to have a look at, with expecting some good points ;)17:10
jd__ildikov_: or I could blackmail you… ;)17:11
openstackgerritJohn Herndon proposed a change to openstack/ceilometer: Return trait type from Event api
ildikov_jd__: should I be worried now? ;)17:13
jd__ildikov_: hehehehe ;)17:13
gibiildikov_: don't worry you are not alone agains jd__ :)17:14
ildikov_jd__: anyway, we will test Colander, as it looked good after the first quick look at the home page, and then we will see what's behind the nice website17:15
jd__ildikov_: thumbs up :)17:16
*** SergeyLukjanov_ is now known as SergeyLukjanov17:19
*** julienvey_ has quit IRC17:20
ildikov_jd__: I will inform you, if we have any results with the testing17:27
*** Alexei_987 has quit IRC17:29
*** SergeyLukjanov is now known as SergeyLukjanov_17:44
*** eglynn has quit IRC17:53
openstackgerritJohn Herndon proposed a change to openstack/ceilometer: Adds documentation for the Event API
openstackgerritJohn Herndon proposed a change to openstack/ceilometer: Update dev docs to include notification-agent
*** ildikov_ has quit IRC18:06
*** _ruhe is now known as ruhe18:25
*** gordc has quit IRC18:28
*** eglynn has joined #openstack-ceilometer18:28
*** yassine has quit IRC18:33
*** eglynn has quit IRC18:35
*** gordc has joined #openstack-ceilometer18:42
*** ruhe is now known as ruhe_away18:45
*** ruhe_away is now known as ruhe18:48
*** openstackgerrit has quit IRC18:52
*** openstackgerrit has joined #openstack-ceilometer18:52
*** tongli has joined #openstack-ceilometer18:55
*** SergeyLukjanov_ is now known as SergeyLukjanov19:03
*** ildikov_ has joined #openstack-ceilometer19:12
*** herndon has quit IRC19:15
*** Alexei_987 has joined #openstack-ceilometer19:28
*** xmltok has joined #openstack-ceilometer19:37
*** tongli has quit IRC21:41
*** asalkeld has quit IRC21:46
*** ildikov_ has quit IRC21:54
*** asalkeld has joined #openstack-ceilometer21:59
*** jdob has quit IRC22:05
*** ruhe is now known as _ruhe22:06
*** SergeyLukjanov is now known as SergeyLukjanov_a22:09
*** SergeyLukjanov_a is now known as SergeyLukjanov_22:10
*** prad has quit IRC22:12
*** jaypipes has quit IRC22:21
*** gordc has quit IRC22:52
*** adriant_ has joined #openstack-ceilometer23:07
adriant_Anyone here with a knowledge of pipelines+transformers able to help with some implementation questions?23:08
nijabaan interesting blog on using transformers
adriant_Thanks, interesting stuff, but not really what I need sadly.23:10
adriant_I've built my own transformer, that takes a gauge and make a cumulative.23:11
nijabashoot your question, someon will eventually read and answer23:11
nijabalots of europeans in this chan, so be patient23:11
*** julienvey_ has joined #openstack-ceilometer23:12
adriant_But the issue I've run into it is that ceilometer spins up two transformer objects, since the gauge meter I am transforming is both a notifier and a pollster. So the issue is the resulting cumulative meter has inconsistent entries due to the two different transformer objects publishing to it.23:13
*** julienvey_ has quit IRC23:14
adriant_nijaba: thanks, I'll be around all day so that's not a problem.23:14
nijabaadriant_: so publish the second one with a different name, or didn´t understand your question?23:15
adriant_I'm currently building a new metric that has a pollster, and a notification feeding it. That works just fine, and is a gauge.23:16
nijabaok, so you may have to wait for someone that knows about this better than I do :)23:17
adriant_But I want to build a pipeline+transformer that builds a cumulative value from that metric, but it seems that the transformer is being run on the data coming in from the pollster, as well as the notifier, but separately.23:17
adriant_Yeah, it's a weird issue, and depends heavily on how the hell the transformers work :P23:17
* nijaba goes afk. have a good night23:19
*** ok_delta has joined #openstack-ceilometer23:40

Generated by 2.14.0 by Marius Gedminas - find it at!