15:00:09 <jd__> #startmeeting ceilometer 15:00:10 <openstack> Meeting started Thu Feb 20 15:00:09 2014 UTC and is due to finish in 60 minutes. The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:13 <openstack> The meeting name has been set to 'ceilometer' 15:00:21 <jd__> hi everyone 15:00:31 <nsaje_> hi! 15:00:38 <ildikov_> o/ 15:00:40 <jd__> #link https://wiki.openstack.org/wiki/Meetings/Ceilometer 15:00:42 <dhellmann> o/ 15:00:42 <nealph_> o/ 15:01:13 <llu-laptop> o/ 15:01:35 <nprivalova> o/ 15:01:43 <gordc> o/ 15:02:57 <eglynn> o/ 15:03:05 <jd__> #topic Milestone status icehouse-3 15:03:13 <jd__> #link https://launchpad.net/ceilometer/+milestone/icehouse-3 15:03:20 <ildikov_> kind reminder: link# https://review.openstack.org/#/q/status:open+project:openstack/ceilometer+branch:master+topic:bp/complex-filter-expressions-in-api-queries,n,z 15:03:32 <jd__> So I've already removed all unstarted blueprint this week 15:03:42 <ildikov_> we also started to implement the client part: link# https://review.openstack.org/#/c/74463/ 15:04:02 <jd__> now it's unlikely we'll complete in that list anyway, so if you know you won't finish patches by the end of this week it's better to say so now and remove the blueprint from the roadmap 15:04:23 <jd__> eglynn: likely I'd remove https://blueprints.launchpad.net/ceilometer/+spec/decoupled-source-sink-discoverable-resources no? 15:05:02 <eglynn> jd__: I'm making progress on it, proposed a WIP patch earlier https://review.openstack.org/#/c/75006/ 15:05:06 <jd__> sileht: what do you think about oslo.messaging portage? 15:05:28 <jd__> eglynn: are you confident the whole bp will be implemented for i3? 15:05:30 <eglynn> jd__: that just addresses the resource discovery, but will have another tmrw with the pipeline breakout 15:05:44 <eglynn> jd__: yep I am confident 15:05:48 <jd__> ok 15:05:48 <eglynn> jd__: I've just got 100% of my time ring-fenced off for i3-focus until March 6th 15:06:00 * ttx lurks 15:06:01 <eglynn> jd__: ... so should all be do-able without the distraction of productization work 15:06:07 <nsaje_> jd__, eg: sorry for missing out the last meeting, but https://blueprints.launchpad.net/ceilometer/+spec/time-constrained-alarms should be ready for review today, is it possible to re-add it for i3? 15:06:36 <jd__> nsaje_: ok but at least update the status 15:06:46 <eglynn> nsaje_: cool, thanks! 15:06:53 <nsaje_> jd__: will do 15:07:04 <jd__> eglynn: ok 15:07:19 <jd__> eglynn: let me know if anything won't make it, we already have too many blueprints 15:07:39 <eglynn> jd__: sure, I'll keep the status in launchpad current 15:07:47 <jd__> awesome thanks 15:08:41 <jd__> likely, whatever is not proposed by the end of the week or early next week will be postponed 15:09:07 <jd__> anythone else otherwise? 15:09:31 <jd__> #topic Tempest integration 15:09:38 <nprivalova> hi all! 15:09:39 <jd__> nprivalova: around? 15:09:42 <jd__> great :) 15:10:17 <nprivalova> Not too much to say actually. CRUDs fro alarms were merged 15:10:38 <nsaje_> nprivalova: great! 15:10:55 <nprivalova> and on this week we were trying to make notifications work but still in progress 15:10:56 <eglynn> nsaje_, nprivalova: nice work, kudos! 15:11:21 <jd__> cool 15:11:25 <nprivalova> sileht is fixing nova AFAIK 15:11:45 <sileht> o/ 15:11:46 <nprivalova> so I hope that he will make notifications work :) 15:12:14 <jd__> yeah 15:12:22 <jd__> nother good idea for having tests :) 15:12:34 <nprivalova> I think that we should merge notification tests in I-cycle (at least) 15:13:00 <nprivalova> because all of them are ready 15:13:06 <eglynn> sileht: that strange oslo-messaging issue with a circular ref in the scheduler run_instance RPC call? 15:13:12 <sileht> eglynn, yes 15:13:30 <eglynn> sileht: ... seemed to completely break nova scheduler in devstack for me earlier in the week 15:13:46 <nprivalova> I think that's all from my side 15:13:56 <eglynn> sileht: ... but then disappeared for no good reason after I did a git ftech/rebase in nova 15:14:00 <sileht> eglynn, I have enhanced the mock of the notifier into the unit to reproduce the issue 15:14:31 <eglynn> sileht: cool ... I couldn't understand why things worked after a rebase in nova as none of the commits looked relevant 15:14:39 <sileht> eglynn, from what I have seen it occur when an Exception is embedded into the notification payload 15:15:07 <sileht> eglynn, you need to have something else that fail to see the failure 15:15:13 * jd__ nods 15:15:14 <eglynn> sileht: a-ha, maybe just a restart of the nova scheduler was enough to avoid a NoValidHost exception occurring 15:15:22 <jd__> failing the failure, basically 15:15:30 <eglynn> yeap, got it 15:15:47 <jd__> #topic Release python-ceilometerclient? 15:15:53 <nprivalova> the problem that we have is 'environment repro'. We were trying to simulate env but got rebasing issue 15:15:57 <eglynn> no need AFAIK 15:16:14 <jd__> #topic Open discussion 15:16:21 <jd__> (feel free to continue :) 15:16:33 <sileht> I'm close to have my latest oslo.messaging patches needed for ceilometer merged ! 15:16:37 <ildikov_> dhellmann: have you seen my comment on the trailing slash bug? 15:16:45 <ildikov_> dhellmann: link# https://bugs.launchpad.net/ceilometer/+bug/1202744 15:16:48 <jd__> sileht: so are we likely to switch for i3? 15:16:51 <uvirtbot> Launchpad bug 1202744 in ceilometer "Final "/" when requesting meters: unexpected behaviour" [Undecided,In progress] 15:16:51 <dhellmann> ildikov_: looking now 15:16:55 <eglynn> a heads-up that voting has opened today for the Atlanta conference track 15:17:00 <eglynn> (... as opposed to the design sessions, that'll be later) 15:17:09 <eglynn> #link https://www.openstack.org/vote-atlanta/SearchForm 15:17:21 <dhellmann> ildikov_: the pecan release with the fix is out now, and the change to the global requirements list just landed 15:17:22 <eglynn> ^^^ search for ceilometer and you'll get about a dozen related abstracts 15:17:30 <sileht> jd__, how does many time remaining ? one week ? 15:17:45 <llu-laptop> eglynn: I assume https://review.openstack.org/#q,topic:bp/monitoring-physical-devices,n,z will have conflict/dependency on your decopule pipeline thing, right? 15:18:01 <jd__> sileht: 2 weeks before the release, but I'll likely postpone things before next week 15:18:13 <nprivalova> guys, I need your heads in HBase reviewing, I have 3 patches without review for a long time https://review.openstack.org/#/c/68583/ and 2 about alarming 15:18:32 <ildikov_> dhellmann: I was just wondering that it would be still better to remove the trailing slash from the doc 15:18:32 <eglynn> llu-laptop: yeap, the resource loader aspect will be replaced by the resource discovery logic 15:18:35 <jd__> I'll take a look nprivalova 15:18:48 <jd__> I'll try to spend the rest of the week reviewing code on Ceilo and Oslo 15:18:57 <sileht> jd__, if markmc is ok with my latest update this morning, it should be ok 15:19:05 <dhellmann> ildikov_: I need to look at the pull request again, to make sure it's not going to break cases where the slash should be present, but probably 15:19:06 <jd__> sileht: ok, great 15:19:09 <nprivalova> oh, sorry https://review.openstack.org/#/c/68641/7 have higher priority 15:19:21 <nprivalova> jd__, ^^ thanks! 15:19:30 <dhellmann> ildikov_: that may not happen for ~24 hrs 15:19:46 <jd__> ildikov_: dhellmann: I had this discussion with ryanpetrello already, and I think we all agree the doc should not have a final / 15:19:54 <llu-laptop> eglynn: but at least the snmp inspector patch https://review.openstack.org/43073 shouldn't dependend on that, I think 15:19:56 <dhellmann> jd__: ok, cool 15:20:01 <ildikov_> dhellmann: thanks for the pecan fix and release info 15:20:33 <eglynn> llu-laptop: agreed that should be independent 15:21:39 <ildikov_> jd__: thanks, sounds good, I have a fix for sphinxcontrib-pecanwsme already uploaded 15:22:24 <jd__> ildikov_: is there a review I can +2? 15:22:31 <ildikov_> dhellmann, jd__: I will close that Ceilo bug about trailing slash, if the doc question was solved 15:22:39 <dhellmann> jd__, ildikov_ : we should chat about the slash thing before taking any other action 15:22:48 <jd__> as you wish 15:22:49 <ildikov_> jd__: link# https://github.com/dreamhost/sphinxcontrib-pecanwsme/pull/12 15:23:07 <llu-laptop> ok, so i'm calling for more reviews on https://review.openstack.org/43073, it's been there for the whole I cycle 15:23:12 <llu-laptop> thanks 15:23:53 <ildikov_> dhellmann: fine with me, I linked the related chapter of the RFC in my comment on that bug about this 15:24:34 <ildikov_> dhellmann: if we can identify exceptions, then it can be handled in sphinxcontrib 15:24:45 <dhellmann> ildikov_: i just want to make sure an api doc change isnt seen as "breaking" 15:25:37 <ildikov_> dhellmann: sure, I totally agree 15:26:48 <ildikov_> dhellmann: in my opinion the only question is, when the webprefix is empty do we need a slash there or not 15:27:46 <dhellmann> ildikov_: I agree we don't need the slash, but changing the published API endpoints could be interpreted as a change to the API, so we want to be careful 15:29:17 <ildikov_> dhellmann: that pecan fix has changed the behavior of Ceilometer's API already 15:29:44 * dhellman_ is having irc issues 15:30:22 <ildikov_> dhellmann_: do you mean the change here that if we change the API doc, then it will describe another behavior than before? 15:31:47 * llu-laptop is afraid of the netsplit, which messed up the nova meeting 1 hour ago 15:31:51 <dhellman_> ildikov_: not a different behavior, but the URLs are (slightly) different -- does that count as an API change? perhaps not, since both versions of the API work 15:32:05 <dhellman_> llu-laptop: good, at least it isn't just me 15:33:22 <ildikov_> dhellman_: I think it is not an API change 15:34:08 <dhellmann> ildikov_: I am leaning toward agreeing, but I want to make sure -- I don't know how strict those rules are 15:34:09 <dhellmann> jd__? 15:34:11 <eglynn> so fixing previously incorrect/unintended behaviour is not really an API change surely? 15:34:27 <ildikov_> dhellman_: for me it seems a bigger API change that the v2/meters/ endpoint now behaves differently, than before the pecan fix, but it's just my point of view 15:34:39 <dhellmann> eglynn: both forms of the urls will still work 15:34:52 <dhellmann> ildikov_: ok, that is a surprise to me 15:34:54 <eglynn> dhellmann: aha, ok 15:35:05 <ryanpetrello> how does the v2/meters/ endpoint now work differently? 15:35:10 <dhellmann> the endpoint shouldn't behave differently? 15:35:19 <jd__> I don't think it's an API change since both will work 15:35:22 <ryanpetrello> what I did was I took the bug fix out of ceilometer and put it into pecan :) 15:35:22 <jd__> we just fix the doc 15:35:58 <ildikov_> dhellmann, ryanpetrello: now v2/meters/ returns the list of meters, before the bugfix, it returned the list of samples for all meters 15:35:58 <eglynn> ildikov_: what was the old behaviour that appears different to you now? 15:36:04 <jd__> the question is more likely: was it a good idea to put this fix in Pecan, and I'm not sure it was 15:36:16 <jd__> because the bug is in the doc generator originally, not in the code, to me 15:36:20 <dhellmann> ildikov_: what is v2/meters/ documented to return? 15:36:51 <ryanpetrello> so the *expected* behavior is that the same URL with a slash on the end returns different results? 15:36:57 <ildikov_> dhellmann: it was documented to return meters, so it works now correctly, but behaves differently 15:37:09 <eglynn> so the prior returning of all samples for all meters smells like unintended behaviour that a client shouldn't have relied on 15:37:23 <ryanpetrello> I see 15:37:23 <dhellmann> eglynn: certainly if that's not what we documented 15:37:36 <eglynn> ... i.e. it was bug, not an implicit part of the API contract IIUC 15:38:50 * jd__ nods 15:39:05 <ildikov_> it was a bug, that could be used as a feature 15:39:24 <dhellmann> does our python client use the "feature"? 15:40:03 <eglynn> #link https://wiki.openstack.org/wiki/APIChangeGuidelines 15:40:15 <jd__> dhellmann: I don't think so 15:40:15 <ildikov_> and as the trailing slash is not part of the URL, it was also a bug in the documentation 15:40:16 <eglynn> ^^^ doesn't really add an clarity 15:40:39 <eglynn> acceptable == "Fixing a bug so that a request which resulted in an error response before is now successful" 15:41:09 <dhellmann> that sounds somewhat applicable in this case 15:41:10 <eglynn> whereas we have "Fixing a bug so that a request which resulted in an unintended response before is now returnin the intended data" 15:41:37 <eglynn> dhellmann: yeah, following the spirit of the guideline I guess 15:43:17 <dhellmann> I think it's probably ok to update the doc tool, which will update the docs 15:44:08 <eglynn> yeap ... if a gun was put to my head, I would go down on the side this not being an API-breaking change, so just an doc update for clarity would be acceptable 15:44:30 * jd__ nods again 15:44:31 <dhellmann> ok 15:44:32 <ildikov_> dhellmann: according to what eglynn linked here, I think so too 15:45:13 <ildikov_> eglynn: +1 :) 15:45:31 <jd__> anything else? 15:45:59 <eglynn> nope, nowt from me ... let's get back to churning out the code for i3! 15:46:06 <eglynn> ... and the reviews! ;) 15:46:09 <dhellmann> +1 15:46:37 <ildikov_> +1 15:46:48 <jd__> ack! 15:46:50 <jd__> #endmeeting