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