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