Wednesday, 2014-07-09

*** fnaval has quit IRC00:18
*** flwang_ has joined #openstack-ceilometer00:35
*** flwang_ has quit IRC00:40
*** amalagon has quit IRC01:01
*** julim has quit IRC01:03
*** _cjones_ has quit IRC01:22
*** _cjones_ has joined #openstack-ceilometer01:22
*** _cjones_ has quit IRC01:27
*** nosnos has joined #openstack-ceilometer01:44
*** amalagon has joined #openstack-ceilometer01:51
*** Ruetobas has quit IRC02:03
*** Ruetobas has joined #openstack-ceilometer02:11
*** giroro_ has joined #openstack-ceilometer02:13
*** Ruetobas has quit IRC02:15
*** ccrouch has joined #openstack-ceilometer02:28
*** changbl has joined #openstack-ceilometer02:30
*** flwang_ has joined #openstack-ceilometer02:36
*** flwang_ has quit IRC02:41
*** shardy has quit IRC03:01
*** Alice911 has joined #openstack-ceilometer03:12
*** nosnos has quit IRC03:20
*** nati_ueno has quit IRC03:22
*** renatoarmani has joined #openstack-ceilometer03:43
*** renatoarmani has quit IRC03:44
*** flwang has joined #openstack-ceilometer04:03
flwangjd__: any lucky you there?04:04
*** ityaptin has quit IRC04:08
*** nosnos has joined #openstack-ceilometer04:13
*** nosnos has quit IRC04:24
*** r3pl4y has quit IRC04:43
*** yatin has joined #openstack-ceilometer04:54
*** underyx|off is now known as underyx04:58
*** ildikov has quit IRC05:02
*** underyx is now known as underyx|off05:13
*** underyx|off is now known as underyx05:17
openstackgerritNejc Saje proposed a change to openstack/ceilometer-specs: Arithmetic transformer spec  https://review.openstack.org/10546705:27
*** underyx is now known as underyx|off05:28
*** ildikov has joined #openstack-ceilometer05:42
*** inc0 has joined #openstack-ceilometer05:45
*** changbl has quit IRC05:51
*** nacim has quit IRC06:01
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/10497406:01
*** amalagon has quit IRC06:30
*** ajc_ has joined #openstack-ceilometer06:35
*** ajc_ has left #openstack-ceilometer06:35
*** ajc_ has joined #openstack-ceilometer06:35
openstackgerritStefano Zilli proposed a change to openstack/ceilometer: Parametrize table_prefix_separator in hbase  https://review.openstack.org/10082906:36
*** Longgeek has joined #openstack-ceilometer06:36
*** flwang_ has joined #openstack-ceilometer06:38
*** r3pl4y has joined #openstack-ceilometer06:39
*** idegtiarov has quit IRC06:42
*** flwang_ has quit IRC06:43
*** idegtiarov has joined #openstack-ceilometer06:46
*** amalagon has joined #openstack-ceilometer06:47
*** underyx|off is now known as underyx07:10
*** eglynn has joined #openstack-ceilometer07:16
*** eglynn has quit IRC07:20
*** eglynn has joined #openstack-ceilometer07:21
*** shardy has joined #openstack-ceilometer07:47
*** ildikov has quit IRC07:55
*** ildikov has joined #openstack-ceilometer07:56
*** safchain has joined #openstack-ceilometer07:58
*** eglynn_ has joined #openstack-ceilometer07:58
*** eglynn has quit IRC07:59
*** nacim has joined #openstack-ceilometer08:04
*** flwang_ has joined #openstack-ceilometer08:39
*** flwang_ has quit IRC08:43
*** flwang_ has joined #openstack-ceilometer08:49
flwang_eglynn_: piing09:04
eglynn_flwang_: 'sup?09:05
flwang_eglynn_: quick question, just wanna confirm, if I just add a new pollster or enhance an existed one, should I create a new spec?09:06
flwang_eglynn_: I think a small blueprint is deserved, but I'm not sure if a spec is needed09:06
eglynn_flwang_: grey area for the new case, probably not required to enhance pre-existing09:07
eglynn_flwang_: new BPs need a spec, so it's both or none really09:07
flwang_eglynn_: yep, grey area, that's why I ask09:08
flwang_my team are going to upsteam a cinder pollster we're using09:09
*** cdent has joined #openstack-ceilometer09:09
eglynn_flwang_: are there very similar existing pollsters? ==> in which case, spec probably not needed09:09
flwang_so is it ok without bp? just upsteam the patch?09:09
eglynn_flwang_: new pollsters polling an previously unused API? ==> in which case, spec probably needed09:09
flwang_yep, it's very similar with existed, just get the volume size09:09
flwang_for billing09:10
eglynn_flwang_: "just BP" isn't really an option anymore ... so BP+spec, or just a RFE-style bug09:10
eglynn_flwang_: sounds like an RFE bug will suffice in this case09:11
flwang_ok, got it09:11
flwang_RFE = ? I know I have asked this question :)09:12
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix SQL exception getting statitics with metaquery  https://review.openstack.org/10215009:12
eglynn_flwang_: RFE == "request for enhancement"09:13
eglynn_flwang_: ... i.e. a bug that asks for a small feature to be added09:13
flwang_awesome09:13
flwang_I really like the term :)09:13
* eglynn_ raps himself on knuckles for indiscriminate use of a TLA ... ;)09:14
flwang_eglynn_: cheers09:14
eglynn_np!09:14
cdenteglynn needs a bigger jar for his bizspeak sins09:14
eglynn_cdent: ... or start using paypal to pay into a virtual jar ;)09:18
*** yatin_ has joined #openstack-ceilometer09:20
flwang_eglynn_: and here is another topic, as for this https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py#L16109:21
flwang_eglynn_: i'm going to rename it as "traffic", since it's not a real bandwidth09:21
flwang_eglynn_: and i will do some tranfomation to get the average 'bandwidth' from the 'traffic', any concern?09:22
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix SQL exception getting statitics with metaquery  https://review.openstack.org/10215009:23
eglynn_flwang_: do you mean change the logic added here ...09:24
flwang_eglynn_: i have confirmed with the neutron guy, safchain who is the original author of neutron metering agent09:24
eglynn_https://github.com/openstack/ceilometer/commit/3636a044a6ec04eea4ace7cbb3b377d2f412598e#diff-26cb8f56ce7ad5b2acc90aaddd268e44R15409:24
*** yatin has quit IRC09:24
eglynn_so that meter name was added way back in the Havana timeframe, or?09:24
flwang_yes09:25
flwang_but the name is not correct, and we haven't release it in ceilometer measurements document09:25
flwang_so I'd like to correct it before release it09:25
eglynn_hmmm, not documented you say?09:26
flwang_yes09:26
eglynn_to what extent is "bandwidth" incorrect?09:26
eglynn_completely misleading?09:26
eglynn_or just personal terminology preference?09:26
flwang_I think so09:26
flwang_generally, the unit of bandwidth should be B/second09:27
*** Longgeek has quit IRC09:27
flwang_or I would say current name will confuse the user09:27
eglynn_a-ha, yes, I see that now ... unit='B'09:28
flwang_safchain: any lucky you around?09:28
eglynn_... is type=sample.TYPE_DELTA accurate in that case?09:28
eglynn_... i.e. the number of bytes since the last what?09:28
flwang_it's correct, because the volume/data is collected in the period, between two timestamps09:29
eglynn_do we capture that timestamp range?09:29
flwang_http://paste.openstack.org/show/85401/09:31
eglynn_one sec09:31
flwang_yes09:32
eglynn_flwang_: so for example in that paste ... 65353079.0 is accurately the number of bytes passed between 2013-12-23T09:44:43.592000 and 2013-12-23T09:39:14.232000?09:34
*** yatin__ has joined #openstack-ceilometer09:35
eglynn_flwang_: i.e. the notifications from neutron accurately count data since the *last* notification09:35
*** yatin__ is now known as yatin09:36
eglynn_flwang_: ... in that case, yep please go ahead and 1. change meter name 2. document this meter and 3. keep the delta type09:36
flwang_65353079.0 collected between 2013-12-23T09:34:13.668000 and 2013-12-23T09:39:14.23200009:37
*** yatin_ has quit IRC09:37
flwang_so yes, you're right09:37
flwang_awesome09:38
eglynn_flwang_: ... thank you sir!09:38
flwang_glad to see we can make progress, cheers09:38
flwang_btw, do you think we should provide an average bandwidth metric?09:39
flwang_like using 65353079.0 / 300 sec09:39
*** yatin has quit IRC09:40
flwang_just think aloud09:40
*** yatin has joined #openstack-ceilometer09:41
eglynn_flwang_: possibly, but preferable to do such derivation in a transformer09:43
eglynn_flwang_: ... as we do for cpu_util etc.09:44
flwang_eglynn_: yep, make sense09:44
eglynn_DinaBelova, Vadim: a heads-up on ... http://lists.openstack.org/pipermail/openstack-dev/2014-July/039709.html09:46
*** vrovachev has joined #openstack-ceilometer09:46
*** yatin has quit IRC09:46
*** yatin has joined #openstack-ceilometer09:47
*** yatin has quit IRC09:54
*** yatin has joined #openstack-ceilometer09:54
* cdent has bought popcorn09:56
*** ildikov has quit IRC09:57
*** Longgeek has joined #openstack-ceilometer09:58
*** underyx is now known as underyx|off10:02
*** yatin_ has joined #openstack-ceilometer10:02
*** _nadya_ has joined #openstack-ceilometer10:05
*** Longgeek has quit IRC10:05
*** yatin has quit IRC10:05
*** _nadya_ has quit IRC10:06
eglynn_nsaje: "Multi meter arithmetic transformer" ... catchy title, /me likee :)10:08
*** idegtiarov has quit IRC10:09
*** yatin_ has quit IRC10:13
*** ildikov has joined #openstack-ceilometer10:15
*** aignatov has joined #openstack-ceilometer10:19
nsajeeglynn_: well, looked like the only one that described the functionality to me :)10:21
*** flwang_ has quit IRC10:22
eglynn_nsaje: yep I'm copying'n'pasting that title directly into my Juno slide-deck :)10:22
cdentneeds another T to make a nicely balance acronym10:23
cdentmulti meter arithmetic transformer technology10:23
cdentyour friend MMATT10:23
nsajecdent: nice!10:23
*** flwang_ has joined #openstack-ceilometer10:27
*** underyx|off is now known as underyx10:30
openstackgerritZhai, Edwin proposed a change to openstack/ceilometer-specs: Add spec for IPMI support  https://review.openstack.org/10446010:31
*** alexpilotti has joined #openstack-ceilometer10:35
DinaBelovaeglynn_, /me reading10:40
DinaBelovaeglynn_, thanks for the meeting attending :D for me it's too late :D10:41
eglynn_DinaBelova: yeah that PTLs meeting is rediculously late for MSK, I'm sure SergeyL loves it ... NOT!10:42
DinaBelovaeglynn_, hehe, exactly :D10:42
*** Alice911 has quit IRC10:42
DinaBelovaeglynn_, sometimes I try to keep my eye on-line for them, but it's still too late to be always available there :D10:43
eglynn_... as the centre of gravity of the community moves away from the west coast US, we really should push for saner scheduling of those upstream meetings10:43
DinaBelovaeglynn_, +110:43
SergeyLukjanoveglynn_, yeah, it's a very nice meeting time10:56
*** yatin_ has joined #openstack-ceilometer10:59
* cdent must go socialize with a nephew briefly11:03
cdentbiab11:03
*** cdent has quit IRC11:03
*** yatin_ has left #openstack-ceilometer11:09
*** alexpilotti has quit IRC11:26
*** underyx is now known as underyx|off11:29
ekarlsomany moving from west coast ? :p11:29
*** underyx|off is now known as underyx11:30
*** alexpilotti has joined #openstack-ceilometer11:30
eglynn_ekarlso: not need for *individuals* to move11:31
eglynn_ekarlso: ... as we explicitly do not follow a BDFL model11:32
*** alexpilotti has quit IRC11:35
*** Longgeek has joined #openstack-ceilometer11:38
*** cdent has joined #openstack-ceilometer11:41
*** promulo has quit IRC11:46
*** giroro_ has quit IRC12:01
*** flwang_ has quit IRC12:02
*** Ruetobas has joined #openstack-ceilometer12:07
*** jdob has joined #openstack-ceilometer12:09
*** Ruetobas has quit IRC12:11
*** idegtiarov has joined #openstack-ceilometer12:14
*** cdent has quit IRC12:17
*** Ruetobas has joined #openstack-ceilometer12:17
*** cdent has joined #openstack-ceilometer12:31
*** cdent has quit IRC12:36
*** jdob has quit IRC12:37
*** jdob has joined #openstack-ceilometer12:38
*** prad has quit IRC12:40
*** cdent has joined #openstack-ceilometer12:42
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572712:43
*** _nadya_ has joined #openstack-ceilometer12:45
openstackgerritNejc Saje proposed a change to openstack/python-ceilometerclient: Check if the alarm has time constraints field before displaying  https://review.openstack.org/9571312:48
*** julim has joined #openstack-ceilometer12:48
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572712:51
*** eglynn_ has quit IRC12:51
*** ajc_ has quit IRC12:52
*** rbowen has joined #openstack-ceilometer12:53
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572712:53
*** _nadya_ has quit IRC12:54
*** _nadya_ has joined #openstack-ceilometer12:55
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572712:58
*** _nadya_ has quit IRC12:59
*** thomasem has joined #openstack-ceilometer13:00
*** d0ugal has joined #openstack-ceilometer13:04
*** joesavak has joined #openstack-ceilometer13:08
*** promulo has joined #openstack-ceilometer13:08
*** changbl has joined #openstack-ceilometer13:10
*** zul has quit IRC13:11
openstackgerritNejc Saje proposed a change to openstack/ceilometer-specs: Arithmetic transformer spec  https://review.openstack.org/10546713:11
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572713:11
*** ildikov has quit IRC13:14
*** nsaje is now known as nsaje-commute13:17
*** zul has joined #openstack-ceilometer13:18
*** eglynn_ has joined #openstack-ceilometer13:21
*** ityaptin has joined #openstack-ceilometer13:23
*** Longgeek has quit IRC13:25
*** _nadya_ has joined #openstack-ceilometer13:25
openstackgerritling-yun proposed a change to openstack/ceilometer-specs: Add log translation hints for ceilometer  https://review.openstack.org/10572713:33
*** Longgeek has joined #openstack-ceilometer13:35
*** nealph__ has joined #openstack-ceilometer13:40
*** eglynn-regus has joined #openstack-ceilometer13:41
*** inc0 has quit IRC13:41
*** shadower_ has joined #openstack-ceilometer13:43
*** ondergetekende_ has joined #openstack-ceilometer13:45
*** mitz- has joined #openstack-ceilometer13:47
*** tasdomas` has joined #openstack-ceilometer13:47
*** nealph_ has quit IRC13:48
*** gibi has quit IRC13:48
*** mitz has quit IRC13:48
*** nijaba has quit IRC13:48
*** greghaynes has quit IRC13:48
*** chrisf has quit IRC13:48
*** shadower has quit IRC13:48
*** tasdomas has quit IRC13:48
*** dragondm has quit IRC13:48
*** eglynn-offic-afk has quit IRC13:48
*** ondergetekende has quit IRC13:48
*** fc__ has quit IRC13:48
*** nijaba has joined #openstack-ceilometer13:56
*** nijaba has quit IRC13:56
*** nijaba has joined #openstack-ceilometer13:56
*** gibi has joined #openstack-ceilometer13:58
*** prad has joined #openstack-ceilometer13:59
*** dragondm has joined #openstack-ceilometer13:59
*** chrisf has joined #openstack-ceilometer14:01
*** flwang_ has joined #openstack-ceilometer14:03
*** flwang_ has quit IRC14:07
openstackgerritChris Dent proposed a change to openstack/ceilometer: Implement consuming ipmi notifications from Ironic  https://review.openstack.org/10548614:10
*** greghaynes has joined #openstack-ceilometer14:11
*** alexpilotti has joined #openstack-ceilometer14:14
rbowenA reminder - eglynn will be doing a Google Hangout in about 40 minutes on what's coming for Ceilometer for Juno :: https://plus.google.com/events/c6e8vjjn8klrf78ruhkr95j4tas14:19
*** idegtiarov has quit IRC14:22
*** idegtiarov has joined #openstack-ceilometer14:24
*** jaypipes has joined #openstack-ceilometer14:27
*** fnaval has joined #openstack-ceilometer14:42
*** r3pl4y has quit IRC14:44
*** fc__ has joined #openstack-ceilometer14:44
*** nacim has quit IRC14:46
*** cdent has quit IRC14:56
*** cdent has joined #openstack-ceilometer14:58
*** r3pl4y has joined #openstack-ceilometer15:01
*** idegtiarov has quit IRC15:02
*** _nadya_ has quit IRC15:10
*** Hao has joined #openstack-ceilometer15:11
*** jaypipes is now known as jay-house-hunter15:22
*** cdent_ has joined #openstack-ceilometer15:22
*** underyx is now known as underyx|off15:23
*** cdent_ has quit IRC15:23
*** cdent has quit IRC15:25
*** cdent has joined #openstack-ceilometer15:25
*** shadower_ is now known as shadower15:26
*** joesavak has quit IRC15:30
*** Longgeek has quit IRC15:36
*** Longgeek has joined #openstack-ceilometer15:37
*** Longgeek has quit IRC15:40
*** Longgeek has joined #openstack-ceilometer15:40
*** yjiang5_away is now known as yjiang515:45
*** alexpilotti has quit IRC15:45
*** _cjones_ has joined #openstack-ceilometer15:48
*** _nadya_ has joined #openstack-ceilometer15:50
*** safchain has quit IRC16:00
*** Ruetobas has quit IRC16:01
*** Ruetobas has joined #openstack-ceilometer16:03
*** flwang_ has joined #openstack-ceilometer16:04
*** jay-house-hunter has quit IRC16:05
rbowenFor those that missed eglynn_'s Ceilometer hangout, that video is at https://plus.google.com/events/c6e8vjjn8klrf78ruhkr95j4tas16:06
*** Ruetobas has quit IRC16:08
*** flwang_ has quit IRC16:08
*** vrovachev has quit IRC16:11
cdentnicely done eglynn16:12
*** Hao has quit IRC16:14
*** nati_ueno has joined #openstack-ceilometer16:19
*** Ruetobas has joined #openstack-ceilometer16:21
*** Ruetobas has quit IRC16:25
*** _nadya_ has quit IRC16:29
*** _nadya_ has joined #openstack-ceilometer16:30
*** Ruetobas has joined #openstack-ceilometer16:31
*** _nadya_ has quit IRC16:34
*** Hao has joined #openstack-ceilometer16:42
*** Hao has quit IRC17:59
*** ildikov has joined #openstack-ceilometer17:59
*** Longgeek has quit IRC18:01
*** eglynn_ has quit IRC18:03
*** flwang_ has joined #openstack-ceilometer18:05
*** flwang_ has quit IRC18:10
*** fnaval has quit IRC18:25
*** eglynn_ has joined #openstack-ceilometer18:35
*** prad has quit IRC18:53
*** prad has joined #openstack-ceilometer18:54
*** Hao has joined #openstack-ceilometer19:02
*** Hao has quit IRC19:11
*** Hao has joined #openstack-ceilometer19:23
*** promulo has quit IRC19:29
*** Hao has quit IRC19:30
*** r3pl4y has quit IRC19:33
*** fnaval has joined #openstack-ceilometer19:50
*** prad has quit IRC19:59
*** flwang_ has joined #openstack-ceilometer20:06
*** flwang_ has quit IRC20:10
*** jergerber has joined #openstack-ceilometer20:14
*** prad has joined #openstack-ceilometer20:14
*** jogo has joined #openstack-ceilometer20:16
jogoeglynn_: ping20:16
eglynn_jogo: hola20:16
jogoso the branchless tempest stuff20:17
eglynn_yep20:17
*** nati_uen_ has joined #openstack-ceilometer20:18
jogoI wanted to get some clarity on your response to Matt's email20:18
eglynn_yeah, I just going ask whether my response to Matt made sense20:18
jogowhen saying cross-serice communication should have an API contract that doesn't mean it has to be REST20:18
jogonotifcations can be a contractual API20:19
eglynn_sure, though sadly they haven't been treated like that in openstack (traditionally)20:19
jogothat is because we have no testing etc. around them20:20
jogoceilometer silently started consuming them without setting up ant contractual API that we enfoce20:20
*** nati_ueno has quit IRC20:20
jogoso from reading that thread I see several seperate questions:20:20
eglynn_ceilometer silently consuming notifications is kinda orthogonal, no?20:21
eglynn_I mean if not ceilo, something else would be consuming those notifications?20:22
jogo1) who is the target audience for ceilometer20:22
jogo2) how do I discover what my ceilometer supports20:22
jogo3) how can we safely evolve / not break notifications20:22
jogoso notifications sort of grew organically and never had a tested contractual public API around them.20:23
eglynn_the target audience ranges from cloud operators to admins to normal users of features such as heat autoscaling20:23
jogogreat, so that is the target audience that I expected20:23
jogoso that brings us to item 2. how do i dscover what my ceilometer supports20:24
eglynn_discovery via a capabilities API is possible for QoS provided by the storage driver20:24
*** ccrouch has quit IRC20:24
eglynn_(e.g. the type of aggregate functions, querying, pagination etc.)20:24
jogo?, how do I know that ceilometer will process a specific notification?20:25
eglynn_we could potentially extend that capabilities API model to include a declaration of the types of meters ceilo generates20:25
jogo++20:25
eglynn_jogo: as I meant to say in that email, there is no way of discovering that *currently* for notifications20:26
eglynn_(other than inferring from docco)20:26
jogoright20:26
jogowell lets first look at where we want to be20:26
eglynn_is there a way of discovering which notifications nova or cinder actually produce?20:26
cdentI think it would be a huge bummer if ceilometer were set up so that the default orientation is that it must know about the notifications it is supposed to consume. I think that is something the other services (and users) should get to decide _not_ ceilometer.20:27
*** Hao has joined #openstack-ceilometer20:27
cdent(by "were set up" I mean "continued to be")20:28
eglynn_AFAICS the notification mechanism has no discoverability on either the producer or consumer side, and no versioning20:28
*** flwang_ has joined #openstack-ceilometer20:28
jogousing Sean's taxonomy, I think we should move the specific failure you hit (ceilometer not processing a cinder notifcatoin) closer to category 2. something that is discoverable20:28
jogoeglynn_: right, so that is the third question  I have20:29
jogowe need full versioning/discoverability/contractual APIs/ around all cross service communication. we have this for REST APIs (mostly) but not for notifications20:30
jogocdent: ? can you elaborate20:30
eglynn_jogo: do I detect that you're coming from the PoV that the shortcomings in the notification system are due to ceilometer's usage of that mechanism?20:30
eglynn_"without setting up ant contractual API ..." etc.20:31
*** flwang_ has quit IRC20:31
jogoeglynn_: correct.20:31
cdentjogo: to me ceilometer is a service for gathering metrics and then being able to do things with those metrics. anything with the proper creds ought to be able to send out a notification which is to be treated as a metric and ceilometer should consume it20:31
*** Hao has quit IRC20:32
jogoeglynn_: but I think that is somewhat decoupled from item 2) no discoverabilty of what ceilometer can process20:32
jogocdent: so your saying ceilometer should be generic and not need to know bout the contents of notifications?20:32
eglynn_jogo: that seems like an odd viewpoint ... "here's a mechanism for being notified about stuff, but you should fix it before you use it" ;)20:33
eglynn_we're interleaving two separate conversations here, can we sequence the discussion?20:33
jogoeglynn_: yeah we are. lets go back to item #220:33
jogowe agree on item #120:33
cdentSorry, I brought this up because I think it pertains to the idea that a  contract of some form ought to be required.20:33
eglynn_#topic "how do I discover what my ceilometer supports"20:34
jogoeglynn_: yup. so as a user of the cloud I want an answer that is better then read the docs20:34
cdentme too20:34
eglynn_the capabilities API provides some scope possibly for doing this20:34
eglynn_http://docs.openstack.org/developer/ceilometer/webapi/v2.html#capabilities20:35
jogoon a related note, this is a much bigger issue accross all of OpenStack we do not have uniform ways of doing discovery20:35
eglynn_^^^ mostly focused on API features that are predicated on storage-driver-level capabilities20:35
eglynn_so say we extend that, to advertize the meters that we're capable of producing?20:36
jogoeglynn_: that should address the specific issue you hit right?20:36
eglynn_without necessarily saying *how* we produce those meters20:36
eglynn_i.e. without stating in capabilities ... "we consume volume.snapshot.create notifications" or whatever20:37
cdentwhen I first ran `ceilometer meter-list` the output I was expecting was "the meters we're capable of producing"20:37
eglynn_cdent: nope it just says ... "what meters I currently have data for"20:38
cdentyeah, I know that _now_20:38
*** prad has quit IRC20:38
cdentbut I think it supports the value of a being able to get such a list20:38
jogocdent eglynn_: sounds like both lists are needed20:38
eglynn_jogo: so such a mechanism would allow that test to be skipped against stable/icehouse ...20:39
eglynn_jogo: ... *if and only if* the extended capabilities mechanism was backported to icehouse20:39
jogoeglynn_: I am less concerend with fixing this *specific* bug  and more interested in solving it for the future20:40
jogobut yes.20:40
eglynn_well until we transition to Kepler, the future cases would also require backporting the mechanism to Icehouse, I think20:41
* eglynn_ is not letting "Kepler" go, reardless of the trademark search ;)20:42
cdent:)20:42
cdentinstead of backporting can't you instead declare some kind of requirement for _new_ tests?20:42
eglynn_cdent: but some of the new tests would be runnable against icehouse, no?20:43
*** ccrouch has joined #openstack-ceilometer20:43
eglynn_cdent: i.e. new tests for old features, as opposed to new tests for new features20:43
cdents/requirement/annotation/ ?20:44
jogoso I think the short term issue for icehouse has several possible solutions, that the tempest folks can better answer20:44
*** prad has joined #openstack-ceilometer20:45
eglynn_jogo: so continue that aspect of the discussion (short term solutions for icehouse) on the ML thread to get further input from the Tempest folks?20:46
eglynn_... but move on item #3 here on IRC?20:47
jogoeglynn_: sounds good. yes so #320:47
eglynn_k20:47
jogohave notification formats changed in the past breaking ceilometer?20:48
eglynn_well, I have anecdata to that effect, but can't recall chapter & verse of specific instances20:49
eglynn_... digging thru' the fossil record would find specific instances20:49
jogoso it sounds like its a real issue20:49
jogothis goes back to what you said earler about notifications intially were this strange thing20:50
jogothat evolved without a contractual (and tested) stable API20:50
jogothey are very haphazard20:51
jogoand with ceilometer (or really anything) consuming them that is not acceptable20:51
jogoif each project had some tests making sure the correct notifications are emitted at the right time, that would be a good first whack at this20:52
jogobut presumably we need full versioning and discoverablity at some point as well20:53
jogocdent: you had some thing to add about this?20:53
cdentwhen you say versioning do you mean of a specific notification from a specific service?20:53
eglynn_ok, so a basic problem here is that notifications pre-existed ceilo, are outside of the control of ceilo, and are also being consumed by things other than ceilo (e.g. stacktach)20:53
eglynn_so we can't simply wave a magic wand and make notifications discoverable and versioned20:53
jogoagree on all points20:54
eglynn_cdent: "versioning" == in a.b you can expect this payload, whereas in version c.d you can expect this other payload20:54
jogoso lets at least make sure projcts don't break there notifcations20:54
jogowithout knowing they are doing so20:54
cdenteglynn_: yes, but is that per notification or of any notification?20:54
cdentI think, if we try hard, we can imagine a future where people have migrated to a notification message format protocol.20:55
eglynn_cdent: per-notification, we do somethign similar already for RPC within the nova services for example20:55
jogoeglynn_: the issue here IHMO is ceilometer made some assumptions about notifcations that were never really true. without trying to fix notifcations themselves20:55
cdentand ceilometer and anything else can talk that protocol...20:55
jogoso I think item #3 is about how do we make notifcations stable contractual APIs in all of OpenStack20:56
jogoso we don't break ceilometer20:56
eglynn_jogo: the assumption in question being "here's a thing being emitted for other things to listen on, let's go use it"?20:56
jogoyes, I think that assumption is only partially correct. yes things were being emitted but they weren't a stable API they were quitly added without signficant testing for rax usage etc20:57
eglynn_TBH ceilo initially had minimal leverage with the other projects to force a fixing of the notification mechanism before actually using it20:58
jogoeglynn_: I don't fully agree with that statement, but its a moot point now. We need to lock down notifcations20:58
jogobecause if we emit them and say folks can use them (which we sort of do) they better be a stable contractual API)20:59
cdents/lock down/standardize/ ?20:59
eglynn_jogo: I'd love to see notifications fixed20:59
cdentthere's a big different between those two20:59
eglynn_jogo: so here's the least that needs to happen20:59
jogocdent: lock down: don't change quietly without backwards compat etc20:59
cdentstandardize: give people some rules they know they can follow, and if they follow them, they get to participate, if they don't, they don't21:00
eglynn_1. buy-in from the emitters of the notification stream (nova, glance, cinder, neutron etc.)21:00
*** jdob has quit IRC21:00
eglynn_2. acquisence from the "external" consumers such as stacktach21:01
eglynn_*acquiescence21:01
eglynn_i.e. we shouldn't, as good citizens, pull the rug out from under them21:01
jogowhats #3?21:02
eglynn_3. is implicit ... "internal" consumers such as ceilo also buy-in to the program21:02
jogocdent: so standardizing would be great but, I think thats a later step. once we have a way to evolve notifcations without breaking things21:02
jogoeglynn_: hmm I am not sure if we are currently talking about the same thing21:03
jogoI would like to see several things happen to make notifcations a real API21:03
eglynn_jogo: what are you talking about?21:03
cdentwell, we have notifications on the bus now, you can "shim" hearing those notifications and translate and republish them21:03
jogosteps to make notifications a stable API21:03
jogobrb, just got a package21:04
eglynn_jogo: sure, so am I (I think)21:04
jogoso I think the first step is to say that the current notifcations should not change unintentionally.21:06
eglynn_jogo: so I was assuming that the fall-out from making notifications a stable, versioned, contract-bound API would impact on *both* producers and consumers?21:06
jogothis means each project should have a suite of tests to validate notifications21:06
jogoeglynn_: in the long run yes21:06
*** prad has quit IRC21:06
jogobut I would first like to prevent nova from accidentally breaking a notifcation21:06
eglynn_OK so nova adds a bunch of tests to assert over notification payload21:07
eglynn_then nova wants to change that payload21:07
eglynn_which requires a version bump21:07
eglynn_which surely requires that the consumers are version-aware, no?21:08
jogoor drop/add a notification21:08
jogoso once we prevent projects from accidentally changing notifcations we can sort out howto properly version them / make 'em discoverable etc.21:08
jogoso I think we can fix this in two steps21:09
jogoadd tests to confirm what we have now. fix the future21:09
jogoeglynn_ cdent: thoughts?21:10
*** prad has joined #openstack-ceilometer21:10
* cdent thinks21:10
eglynn_well, ok, but that does sound a little like kicking the hard, frictionful problem down the road by concentrating on the frictionless problem first21:10
cdentyes, that's exactly what I was going to say21:10
jogothey can be done in parallel21:10
eglynn_OK, if there's buy-in from nova/glance/neutron to go add those tests, they would certainly have value21:11
jogoso speaking for nova I would push for buy in21:11
*** julim has quit IRC21:12
eglynn_another way of approaching this would be to do what russellbryant did for RPC versioning in nova, IIRC21:13
jogowe would need those tests even if we had perfect versioned/discoverable notifications etc21:13
jogoeglynn_: hrm, that may work for the versioning etc things. I like it21:14
eglynn_... i.e. ACK that the past was broken, get buy-in for the future, take the pain over a release cycle21:14
jogoyeah21:14
jogothe notication problem is similar to nova's RPC issue21:15
*** thomasem has quit IRC21:15
jogoso I think thats a good model to use21:15
jogoor at least start with21:16
eglynn_so we'd be talking about session(s) on the cross-project track in Paris in November?21:16
* eglynn_ is thinking time-horizon for this ...21:16
jogoyeah,21:16
jogoI do think we can get test in for the current RPC notifcations this cylce though21:17
*** chrisf has quit IRC21:17
eglynn_so that would be in-tree test in each of he services, as opposed to tempest-level tests?21:17
jogoI was thinking in tree21:17
jogofor example: nova would make sure that x notifcatoins with y contents are produced for a nova boot21:17
jogoor something like that21:18
eglynn_sounds good, but the proof would be the resourcing of this task in each project21:18
eglynn_jogo reckons nova would be on-board, but we'd still need glance/cinder/neutron to step up to the plate21:19
jogoyeah, and then we would need folks to do all the work21:19
jogoeglynn_: sounds like we are in agreement on most things, want to follow up to the ML thread with some of this?21:19
jogoto take this back to the larger table21:19
jogonova has similar tests right now for the API21:20
jogowe have basic API test that prevent us from changing the API without knowing about it21:20
eglynn_yeah I can follow up on the ML with a summary of this discussion, but would be tmrw AM by the time I get to it21:21
* eglynn_ has the end of a world cup match to watch now :)21:21
* cdent squints21:23
*** chrisf has joined #openstack-ceilometer21:25
jogoworks for me21:25
eglynn_jogo: cool, thanks for the discussion & input21:25
jogoeglynn_: thanks, this has been very productive21:25
cdentThanks for putting up with my blue-skying...21:25
jogo^_^21:26
* cdent is still bewildered that notifications are RPC21:26
jogoyeah RPC isn't really the correct term21:28
*** Hao has joined #openstack-ceilometer21:29
cdentbut it is modelled that way: agent A calls a method on agent B via the bus21:29
cdent_sort of_21:29
cdentit all seems a bit hinky21:29
*** Hao has quit IRC21:34
*** fnaval has quit IRC21:35
*** fnaval has joined #openstack-ceilometer21:42
*** thomasem has joined #openstack-ceilometer21:46
*** thomasem has quit IRC21:47
*** rbowen has quit IRC21:48
*** thomasem has joined #openstack-ceilometer21:52
*** thomasem has quit IRC21:54
*** thomasem has joined #openstack-ceilometer21:55
*** jay-house-hunter has joined #openstack-ceilometer22:03
*** fnaval has quit IRC22:11
*** nacim has joined #openstack-ceilometer22:15
openstackgerritFei Long Wang proposed a change to openstack/ceilometer: Rename bandwidth to network.traffic  https://review.openstack.org/10589622:16
*** cdent_ has joined #openstack-ceilometer22:20
*** cdent has quit IRC22:23
*** cdent_ is now known as cdent22:23
*** prad has quit IRC22:26
*** thomasem has quit IRC22:27
*** nacim has quit IRC22:28
*** Hao has joined #openstack-ceilometer22:30
*** flwang_ has joined #openstack-ceilometer22:32
*** Hao has quit IRC22:36
*** flwang_ has quit IRC22:36
*** boris-42 has quit IRC22:37
*** jay-house-hunter has quit IRC22:38
*** amalagon has quit IRC22:38
*** boris-42 has joined #openstack-ceilometer22:39
*** ryanpetrello has joined #openstack-ceilometer22:43
ryanpetrelloanybody aware of any issues that would cause ceilometer tests to hang in the gate queue?22:44
ryanpetrellohttps://jenkins01.openstack.org/job/gate-pecan-tox-ceilometer-tip/47/console22:44
ryanpetrellothis is the second time I’ve watched this test just sit and timeout and hang :\22:44
*** amalagon has joined #openstack-ceilometer23:00
*** eglynn_ has quit IRC23:03
*** jergerber has quit IRC23:08
*** Hao has joined #openstack-ceilometer23:32
*** Hao has quit IRC23:37
*** packet has joined #openstack-ceilometer23:40
*** ccrouch has quit IRC23:48

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