15:00:30 #startmeeting ceilometer 15:00:32 Meeting started Thu Mar 19 15:00:30 2015 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:36 The meeting name has been set to 'ceilometer' 15:00:58 o/ 15:01:00 who's all around for the ceilo weekly? 15:01:02 hi 15:01:07 o/ 15:01:09 o/ 15:01:10 o/ 15:01:18 o/ 15:01:29 #topic kilo-3 15:01:30 o/ 15:01:38 kilo-3 is tagged and bagged :) 15:01:42 nice work folks! 15:01:42 <_nadya_> o/ 15:01:47 \o/ :) 15:01:55 https://launchpad.net/ceilometer/+milestone/kilo-3 15:02:01 o/ 15:02:12 o/ 15:02:14 that's a nice stack of bugs 15:02:18 thank you all 15:02:23 as agreed last week, we bumped fabiog's config-db BPs to liberty-1 15:02:29 o/ 15:02:41 so now, we enter the stabilization phase 15:03:00 since the config-db BPs were bumped to liberty, we will not be requesting at FFEs this time 15:03:12 so purely bug fixes between now and kilo-rc1 15:04:03 RCs will be cut between weeks commencing April 9th to April 23rd 15:04:20 final kilo tag planned for w/c April 30th 15:04:46 so if you've got any bug fixes that you feel should get into kilo, earlier the better! 15:05:18 once the RC1 tag is cut, the scrutiny on targeting bugs will go way up 15:05:36 i.e. harder to justify for RCn with n>1 15:05:52 anything else on kilo? 15:06:22 k, onwards and upwards :) 15:06:24 #topic gnocchi status 15:06:39 I beleive jd__ is cooking up a release today :) 15:06:57 o/ 15:07:00 I am 15:07:10 waiting for Jenkins to merge last patches, it's slow 15:07:21 but 1.0a1 should be out pretty soon otherwise 15:07:23 (it seems to have been more than usually slow lately) 15:07:56 I hoe it will be nicely flavored ;) 15:08:01 *hope 15:08:08 cdent: k-3 madness time. 15:08:09 jd__: released artifacts will be available from tarballs.openstack.org? 15:08:18 ... or pypi? 15:08:40 they should be on both 15:08:45 coolness :) 15:08:58 shoudl I add some words about it in OS Manuals or let's wait with that step a bit more? 15:09:24 I think you can wait a bit ildikov 15:09:38 then the idea is to do further 1.0aN releases with N>1 until kilo is finalized? 15:09:48 i.e. up to approx w/c April 30th 15:10:11 jd__: ok, tnx 15:10:35 eglynn: I've updated the milestones at launchpad.net/gnocchi 15:10:44 so I plan for a rc1 at some point and then 1.0 15:10:56 maybe further a2 a3… if needed or if I feel like it 15:11:02 excellent 15:12:05 likely a1 will have issue or tarballs will be missed or I don't know and I'll have to do more alphas 15:12:11 hmmm, that reminds me 15:12:13 that's one of the point, train us to release :p 15:12:22 dep freeze is also today 15:12:33 #link https://wiki.openstack.org/wiki/DepFreeze 15:12:54 so we'll need a dep-freeze exception for the tooz/redis bug cdent is working on 15:13:21 I have a dirty fix. 15:13:31 will push it up for review so we can figure out how to make it clean 15:13:41 #link https://bugs.launchpad.net/python-tooz/+bug/1434043 15:13:42 Launchpad bug 1434043 in tooz "ceilometer group partitioning coordination with tooz+redis+sentinel fails to failover to new master" [Medium,Triaged] 15:13:48 cdent: coolness, thanks! 15:14:05 I think depfreeze is about NEW deps, not existing ones 15:14:45 jd__: I was thinking we'd stick a lower bound on the tooz dependency version? 15:15:11 jd__: a-ha, you're right ... "you are no longer allowed to accept proposed changes containing *new* requirements" 15:15:24 yeah I think we can upgrade our requirement 15:15:33 coolness :) 15:15:35 anyway if we don't it'd be just "upgrade or it will work until it does not" 15:15:39 :D 15:15:48 LOL :) 15:16:38 jd__: cool, tooz has a stable/kilo already 15:16:56 though there is a general misunderstanding IMHO with requirements between "minimum version that works" and "minimum version that is recommended with no bug" – that last one is always the last version anyway 15:17:20 but that's a larger scope than Ceilometer and is subject to debate I guess 15:17:44 yeah, true that 15:17:51 cdent: will we need that tooz fix backported to stable/kilo also? 15:18:17 juno you mean eglynn ? yes 15:19:04 * cdent is somewhat confused 15:19:15 cdent: a-ha yeah ... /me is confused now why tooz has a stable/kilo branch before kilo is cut, but no stable/juno 15:19:45 jd__: ^^^ perhaps because tooz only moved into oslo from stackforge after juno? 15:20:53 cdent: yeah, forget stable/juno ... since the redis driver landed after juno anyway IIRC 15:21:59 and I'd imagince most juno-derived distros with roll forward to the latest tooz 15:22:50 anything else on gnocchi? 15:23:15 #topic open-discussion 15:23:49 anyone still waiting on a yeah/nay on a Vancouver conference proposal? 15:24:20 * gordc hasn't heard anything. 15:24:39 eglynn: did they already sent out the discount codes for contributors? 15:24:47 i don't think anyone i know has heard anything. 15:24:55 i've still not heard 15:25:01 I thought it will be announced next week 15:25:14 fabiog: I think I got the code already 15:25:16 fabiog: i got mine a while ago. 15:25:26 * jd__ waiting 15:25:38 yeap, last I heard, was supposed to be this week or very latest early next week 15:25:40 fabiog: yeah it was sent a while ago 15:25:53 ildikov: gordc: so then mine fall through the cracks ... 15:25:55 fabiog: yeap, that was quite a while ago 15:26:26 fabiog: we should be able to get you an ATC code from reed if you didn't get one in the first round 15:26:56 fabiog: I'm surprised at that though, since you had patches landed in kilo-1 IIRC 15:27:02 (i.e the RBAC stuff) 15:27:18 fabiog: like what eglynn says I would also think that you can still get it 15:28:26 fabiog: check your junk folder... if it hasn't cleared already. 15:28:53 fabiog: $subject == "Your discount code for OpenStack Summit in Vancouver" 15:29:08 from: communitymngr@openstack.org 15:29:47 eglynn: thanks! Looking 15:30:14 eglynn: today they will remove my hp email account so I need to find it now ;-) 15:30:26 fabiog: if you can't find it, reach out to reed (Stefano Maffulli) to get a fresh one 15:30:35 fabiog: if you need me to vouch, just shout 15:31:25 ok, if there's nothing else ... 15:31:27 ... shall we call it a wrap? 15:31:31 I have one 15:31:54 just a small regarding to how the post samples endpoint should work? 15:32:01 shoot 15:32:17 I mean is that the desired way that it is kind of limited by the pipeline.yaml file? 15:32:20 ildikov: I know about this one ;-) 15:32:55 ildikov: not sure what you mean by "limited" in that context 15:32:56 * ildikov listens :) 15:33:19 eglynn: https://review.openstack.org/#/c/164401/2 15:33:27 ildikov: to me if you return a 201 or 200 when you create a sample (and related meter) you should be able to query about it later on 15:33:52 ildikov: you mean all the posted samples should gone through pipeline? 15:33:57 i would think it shouldn't be... i don't think pipeline should exist... (or the post functionality for that matter.lol) 15:34:07 pipeline in api i mean 15:34:11 eglynn: basically if you POST a sample that generates a meter that is not listed in the pipeline.yaml, Ceilo will let you create it, but then you have no way of seeing it 15:34:13 ildikov: I think that was our original design 15:34:21 gordc: the post functionality is very handy for tests 15:34:22 so the samples are persisted through the pipeline 15:34:52 cdent: yeah, i figured that's the main/only use case. 15:35:05 therefore it the pipeline does not contain a wildcard, then the sample will not be persisted because they do not match any meters defined in pipeline.yaml 15:35:08 i made a spec about getting rid of the pipeline in the api a while ago, but then sort of lost interest: https://review.openstack.org/#/c/143103/ 15:35:16 cdent: if that's it, i don't know if we need pipeline. 15:35:25 cdent: oh yeah, right, the spec! 15:35:47 ildikov: but the client returns a success code like it did it. I think this is wrong, it should return a 409 conflict if the meter is not in the pipeline 15:35:52 it turned out that the pipeline being in the api was actually a useful way of controlling dispatch 15:35:58 and also testing the pipeline itself (via the api) 15:36:15 fabiog: I think we should persist the samples independently from the pipeline config 15:36:28 fabiog: agreed, at least we should have the HTTP return status consistent 15:36:34 fabiog: so there are multiple issues with it 15:36:52 ildikov: Ok. I see two options 15:36:59 fabiog: I mean lack of valid response and also failed functionality 15:37:20 Either we add the meter and then update the pipeline to reflect the new meter that has been added so then the user can retrieve that meter 15:37:36 cdent: i assume we just need to dispatch to db no? i wouldn't expect someone to post to api, and publish just to MQ 15:38:01 or we return a "conflict" state saying that the sample cannot be stored because the pipeline has no corresponding meter 15:38:14 so the user can update the pipeline and re-submit if they wish so 15:39:00 any thoughts? 15:39:25 jd__: wasn't there a specific reason for the POST samples API using a pipeline? 15:39:26 well, basically I think we should not send the samples through the pipeline if they are coming from the API endpoint, or at least it does not make much sense to me 15:39:50 my question wasn't about how to solve the bug that the patch is up for 15:39:59 but that what is the desired functionality? 15:40:12 * eglynn has a vague recollection of discussing this previously, and jd__ had a reason to keep the pipeline 15:40:12 because that is what is not clear to me currently 15:40:52 ildikov: agreed... the api is already directly connected to db, i don't see a case where they'd need to be transformed 15:41:13 I believe post is comparable to notification, so both should gone through pipeline for consistency? 15:41:51 eglynn: transformers and all? 15:41:57 what's the problem with having the pipeline in the API? 15:42:02 gordc: yeap, in the sense that if someone sends samples I guess it is in the form they need it and they don't want extra transformation 15:42:16 jd__: yeah, could have been that all right 15:43:00 likely all of that make less sense with Gnocchi now, but eh… 15:44:16 i guess we can track on bug? not sure we have consensus here. 15:45:15 jd__: the pipeline gives a limit regarding to posting samples via the API 15:45:32 i don't think we can pull it out tbh since i'm assuming someone will say "backward compat" 15:45:42 jd__: I mean you need a wildcard in pipeline.yaml or the new meter name in order to get the sample persisted 15:46:03 gordc: yeap sadly :( 15:46:30 so saw I POST a sequence of cpu samples, surely I'd expect the corresponding cpu_util to be derived for these? 15:46:37 jd__: if the pipeline is the limit we should enforce it even when we create the sample not only when we read the meter back 15:47:20 eglynn: yeah... i guess for me, it was mainly, why are people posting stuff to api to begin with (aside from testing) 15:47:24 eglynn: for that yes, but if you post bubu samples then I guess don't really have expectations, or? 15:47:58 because we expect people to be able to use Ceilometer with their own metrics/samples 15:47:58 fabiog: yeap, but should it be the limit? 15:48:06 ildikov: I guess your pipeline.yaml is already saying that you're explicitly not interested in bubu samples? 15:48:42 gordc: IIRC jd__ had a customer usecase for the POST samples API 15:48:53 eglynn: if I use the default, then I have a wildcard, I guess it solves my issue and I expect that 'bubu' samples will be persisted 15:48:55 eglynn: I think for now we can assume that the pipeline is the limit. I guess we can extend the configDB discussion around this too. 15:49:18 fabiog: snap, I wanted to mention the same :) 15:49:20 people building a PaaS on top of OpenStack using Nova VMS – so without having any access to the internal cloud 15:49:22 eglynn: if you have the ability to store the pipeline in the db it will be easy to programmatically add a new meter when a new sample is submitted 15:49:24 jd__: fair enough. not ideal but is what it is. 15:49:25 and using Ceilometer to meter 15:49:31 ildikov: so if the wildcard source is present, then the problem doesn't occur, or? 15:50:15 eglynn: I don't have a running env now, but according to the bug with wildcard it does not 15:50:15 eglynn: yeah, it's fine then. 15:50:21 eglynn: with * you can post all the meters you want 15:50:34 you just need to be aware that what your posting is going through pipeline 15:50:50 eglynn: but without * you can post the sample BUT not get the meter/sample back 15:51:08 gordc: it seems to me that I have some docco writing task again... :S :) 15:51:13 fabiog: because it's never persisted? 15:51:21 fabiog: why wouldn't you get it back? 15:51:33 i think the bug is that it doesn't tell you that it's been rejected. 15:51:42 gordc: exaclty 15:52:01 eglynn: so it is never persisted but you got a message that it has been 15:52:20 eglynn: and then you will never find it. We had QA going nuts on this :-) 15:52:27 fabiog: a-ha, k, so the problem is more that it silently fails? 15:52:34 as I understand the bug says that this only happens if you remove the wildcard and don't specify the name of the new meter 15:52:47 fabiog: i guess just fix the silent fail and update docs to tell you you're posting to pipeline. 15:52:55 eglynn: well not even silently the pyhton client returns like it was all dandy 15:53:08 yeap, wot gordc said 15:53:16 gordc: agreed, that's at least we could do now 15:53:19 gordc: that is what the patch is going to do 15:53:26 fabiog: cool cool 15:53:33 gordc: return a 409 saying that there is a conflict 15:53:35 fabiog: so you say that even with wildcard it will fail to persist? 15:53:38 k, I think we're all ad idem so :) 15:53:39 gordc: pipeline 15:53:56 ildikov: no with wildcard works 15:53:57 It's interesting to me how little we agree not just on how these things should work, but also how they _do_ work. 15:54:17 ildikov: IIUC, fails to persist only in the case without a wildcard 15:54:25 fabiog: ok, so we are on the same page, cool 15:54:28 ildikov: your small item took away 20+min.lol 15:54:49 gordc: the devil is in the details ;-) 15:54:51 I'm not sure 409 is better than 400 15:54:54 gordc: I had a feeling that it will TBH, but wasn't sure... :) 15:55:10 cdent: build a detailed pretty diagram for us to look at. i like pictures. 15:55:27 cdent: that is why I brought it up on the meeting as many of us is here now and it seemed to be a messy topic 15:55:30 gordc: you need to do it, you make them so good, except for the rotation 15:55:34 ildikov++ 15:55:34 zqfan: 400 is bad request. If the sample is specified correctly you are saying the client that his request is wrong where there is nothing wrong with it 15:55:36 lol 15:55:56 ok, let's take it to gerrit :) 15:56:23 zqfan: 409 is specifically say that there is a "conflict" within the app that prevents it to fulfill your request, but the request itself is fine 15:56:23 eglynn: yeap, now we can and I also know what to write into the docco, so I'm happy now :) 15:56:47 cdent: i'll make a gif, of all ways a datapoint can enter ceilometer services. 15:57:12 make sure you include a picture of an evil school marm wagging her finger shamefully 15:57:15 gordc: you are turning into a Graphic Artist :-) 15:57:30 LOL :) 15:57:54 lol 15:58:15 so thanks all for clarification :) 15:58:22 k folks, let's call it a wrap :) 15:58:29 thanks all for your time! 15:58:32 eglynn: +1 :) 15:58:32 laters! 15:58:35 ciao 15:58:39 laters 15:58:44 #endmeeting ceilometer