21:01:08 <flwang> #startmeeting zaqar 21:01:09 <openstack> Meeting started Mon Mar 7 21:01:08 2016 UTC and is due to finish in 60 minutes. The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:13 <openstack> The meeting name has been set to 'zaqar' 21:01:24 <flwang> #topic roll call 21:01:26 <flwang> o/ 21:01:35 <Eva-i> o/ 21:01:36 <flwang> raise your hand if you're around :) 21:02:04 <ryansb> \o 21:02:41 <flwang> yep, in China, when i was a young student, we're asked to raise the right hand instead of left :D 21:03:05 <flwang> where is vkmc? 21:03:10 <vkmc> HERE o/ 21:03:10 <vkmc> : 21:03:11 <vkmc> :) 21:03:22 <flwang> haha, awesome 21:03:40 <flwang> TBH, i don't have much topic today after a busy week 21:03:56 <flwang> #topic patches for RC1 21:03:56 <Eva-i> I think we should discuss our tech debt 21:04:21 <flwang> we need to figure out which patches we would like to get it in RC1 21:05:13 <flwang> not too much on the list 21:05:14 <Eva-i> It means not all patches which are currently merged to master will make their way to RC1? 21:05:34 <flwang> Eva-i: we may need to defer some of the patches into Newton 21:05:46 <Eva-i> Or we are discussing new unwritten patches? 21:05:56 <flwang> we don't want to introduce any regression issue 21:06:27 <flwang> Eva-i: we're discussing which patches/bug we want to merge/fix in RC1 21:06:48 <flwang> currently, what in my mind is: 21:07:14 <flwang> 1. PUT queue should update the metadata 21:07:28 <ryansb> you mean PATCH? 21:07:35 <flwang> ryansb: PUT 21:07:45 <flwang> we have fixed PATCH, no? ;) 21:07:58 <Eva-i> we have added patch 21:08:56 <flwang> ryansb: see https://review.openstack.org/#/c/280941/1 21:09:13 <Eva-i> So on PUT operation Zaqar should create queue and replace queue metadata? It's just like PATCH, but doesn't throw 404 error, right? 21:09:16 <flwang> ryansb: vkmc: Eva-i: we also need to decide if we would like to support queue metadata update for v1.1 21:09:24 <flwang> flaper87: if you're around, see above 21:09:40 <vkmc> hmm I'm not so sure about that approach 21:10:01 <vkmc> how is the behavior right now? if there is a queue "x" and you put a queue "x" 21:10:05 <vkmc> that queue gets overwritten? 21:10:14 <flwang> the queue won't be overwriten 21:10:28 <flwang> for example, you have queue A, with empty metadata 21:10:51 <flwang> and you PUT queue A with metadata {'_flavor': "fast_storage"} 21:10:54 <flwang> it won't work 21:10:57 <Eva-i> vkmc: zaqar just responds with 204 status code, old metadata stays, even if the user has PUT 'x' with metadata 21:11:20 <flwang> it just return 204 21:11:22 <vkmc> ok 21:11:30 <flwang> vkmc: see https://review.openstack.org/#/c/280941/1 21:12:36 <flwang> technically, it's breaking the idempotence of PUT 21:12:45 <ryansb> yes 21:13:11 <flwang> but i need to talk with flaper87 or kgriffs to know if there is any reason 21:15:29 <flwang> 2. https://review.openstack.org/279946 subscription update for redis 21:15:56 <Eva-i> our queue PUT method wasn't idempotent from the start 21:16:12 <flwang> as for "Show 'age' field in subscriptions", i'm hesitating to get it in Mitaka 21:16:15 <Eva-i> i'm not sure it's possible now to make it idempotent 21:16:18 <flwang> vkmc: ryansb: thoughts? 21:16:30 <ryansb> I wouldn't bother with that one for rc1 21:16:33 <ryansb> it'll wait 21:16:56 <flwang> ryansb: good to see we're on the same page :) 21:16:58 <flwang> vkmc: ^ 21:17:22 <Eva-i> I think I want subscriptions to show their age in mitaka 21:18:11 <flwang> Eva-i: for me, it's like a new feature, instead of a bug 21:18:42 <flwang> and i don't really want to merge a new feature for release candidate 21:18:51 <flwang> since i don't want to introduce any regression issue 21:18:52 <Eva-i> flwang: oki 21:19:03 <flwang> ryansb: does that make sense for you? 21:19:06 <flwang> vkmc: ^ 21:19:25 <ryansb> yeah, I'd rather wait on it 21:19:25 <vkmc> I agree with that, I don't want to merge a new feature for RC1 21:19:29 <vkmc> we cannot afford that 21:19:33 <vkmc> if we are aiming for stability in this cycle 21:20:09 <Eva-i> oki, let's not include it in RC1 21:20:42 <flwang> vkmc: for this one, https://review.openstack.org/#/c/286541/ when you say "Pushing this to RC1", i think you mean you don't want to merge it in RC1, right? 21:21:07 <vkmc> flwang, I meant we were going to review that in RC1 21:21:20 <vkmc> it's not a feature addition but a refactoring in the code 21:21:26 <vkmc> that kinda makes sense 21:21:56 <vkmc> unless you don't think so 21:22:15 <ryansb> -2 for that, wait until after mitaka 21:22:20 <ryansb> it's just a change to the tests 21:22:45 <flwang> vkmc: i can't see any benefit for Mitaka 21:22:59 <flwang> vkmc: personally, i would perfer to defer it to N 21:23:58 <Eva-i> so mostly any patches that I will make now will probably go to N? 21:24:06 <ryansb> yeah 21:24:17 <ryansb> the idea is to only do bugfixes in release candidates 21:24:17 <Eva-i> oki 21:24:18 <flwang> Eva-i: unless it a cirtical bug fix 21:24:31 <ryansb> other patches are appreciated, but won't be merged for Mitaka 21:25:05 <flwang> Eva-i: like which may breaking an existing function, IMHO 21:26:02 <Eva-i> so what we have decided about https://review.openstack.org/279946 subscription update for redis ? 21:26:06 <vkmc> flwang, ryansb sounds good to me 21:26:21 <Eva-i> ah, you decided not to include it in redis 21:26:26 <Eva-i> *in RC1 21:26:35 <flwang> see https://wiki.openstack.org/wiki/Release_Cycle#Release%20candidate%201 21:26:46 <Eva-i> but there is a problem with subscriptions now 21:27:32 <flwang> Eva-i: where i said the subscription update for redis patch won't be in RC1? 21:27:45 <flwang> Eva-i: that's the one we need to discuss 21:28:10 <Eva-i> flwang: yes, right, let's discuss it 21:29:17 <flwang> Eva-i: i would like to see it in RC1 21:29:35 <Eva-i> flwang: me too 21:29:46 <flwang> as for the queue metadata issue, i will talk with flaper87 to confirm something 21:31:57 <flwang> ryansb: vkmc: ^ re the subscription update for redis patch 21:32:00 <Eva-i> Because subscriptions expire now, the user can't renew subscription if he knows the subscription is going to expire soon. All he can do is recreate subscriptions. And in the moment between subscription expiration or deletion and new subscription creation, Zaqar don't send notifications, which is bad. 21:32:20 <ryansb> Indeed. 21:32:33 <ryansb> I haven't reviewed the latest one, will do though 21:32:53 <ryansb> it sounds like it should be in RC1 though, since it messes up the subscription extension semantics 21:33:07 <flwang> ryansb: cool, thanks for the feedback 21:33:14 <Eva-i> so wangxiyuan is fixing subscription renew in Redis, I'm going to fix it in MongoDB 21:33:19 <flwang> ryansb: btw, https://review.openstack.org/#/c/289179/ wangxiyuan is working on the client patch 21:33:25 <flwang> for queue metadata update cli 21:33:33 <ryansb> ah, great 21:33:43 <flwang> Eva-i: i don't think we have a bug for mongoDB 21:35:57 <flwang> ryansb: Eva-i: vkmc: pls do not merge the client patch https://review.openstack.org/#/c/289179/ unless we have an agreement if we would like to add the queue update support for v1.1, thanks 21:36:32 <ryansb> I think I was the only one against, and since everyone else was for it I'm fine with supporting v1.1 21:37:05 <ryansb> so I think the verdict is v1.1 support is ok 21:37:46 <flwang> ryansb: cool, but given we have at least about 2 weeks, so we can think about it carefully 21:38:36 <flwang> i will talk with flaper87, who is the opposition party of anything about queue :D 21:39:08 <Eva-i> flwang: I think we have a bug in mongoDB, so I opened this bug https://bugs.launchpad.net/zaqar/+bug/1552866 21:39:08 <openstack> Launchpad bug 1552866 in zaqar "Subscriptions in mongodb are not renewed on TTL UPDATE" [Undecided,New] - Assigned to Eva Balycheva (ubershy) 21:40:14 <flwang> Eva-i: ok, i can see your point now 21:40:30 <flwang> Eva-i: you mean update the 'expires' field, right? 21:40:41 <Eva-i> yeah 21:41:12 <flwang> Eva-i: cool, valid bug for me 21:41:28 <Eva-i> flwang: =) 21:41:35 <ryansb> yup, looks good to go into RC1 21:41:40 <Eva-i> take a look also to this bug https://bugs.launchpad.net/zaqar/+bug/1547131 21:41:40 <openstack> Launchpad bug 1547131 in zaqar "Subscription patching to duplicate in mongodb should return 409 response" [Undecided,New] - Assigned to Eva Balycheva (ubershy) 21:42:57 <flwang> Eva-i: at the first glance, bug/1547131 can't be in RC1 21:43:16 <Eva-i> if we will not fix it, our mongodb and redis backend will differ on update operation. 21:43:45 <flwang> Eva-i: you can fix it in 1552866 21:43:59 <flwang> it's a bit tricky though 21:44:40 <Eva-i> flwang: I prefer to make two patches for these bugs. I even recommended wangxiyuan to split his patch because of that 21:44:45 <flwang> ryansb: poking me if i'm giving a wrong suggestion :D 21:45:04 <flwang> Eva-i: no 21:45:19 <flwang> i will vote for no 21:45:28 <Eva-i> ryansb: vkmc: and what do you think? 21:45:31 <ryansb> I'm in favor of splitting them 21:45:52 <ryansb> also, I agree the spurious errors should be fixed for RC1 21:46:07 <ryansb> as an operator I hate when not-actually-error errors log at that level 21:47:16 <flwang> vkmc: ^ 21:47:30 <Eva-i> ryansb: what do you mean by spurious errors? Using LOG.exception instead of LOG.debug, when we need to use LOG.debug? 21:47:56 <ryansb> I mean in bug/1547131 where we use ERROR to log a conflict 21:48:08 <ryansb> when really it should be at debug or info 21:48:17 <ryansb> since the operator can't do much with that information 21:48:32 <ryansb> and it's not actually an error that puts the zaqar service in danger of failing 21:48:34 <Eva-i> ryansb: aha, oki 21:49:03 <Eva-i> ryansb: yes, that's synonymous of what I have asked. 21:49:22 <Eva-i> LOG.exception is logging at error level 21:49:33 <ryansb> then yup 21:50:16 <Eva-i> there are many places in Zaqar, when it logs by LOG.exception instead of logging by LOG.debug 21:51:26 <flwang> seems we lost vkmc 21:51:31 <flwang> and the vote result is 2:1? 21:53:05 <Eva-i> flwang: we can ask her later, if you want. 21:53:21 <flwang> it's fine, it's not a big deal 21:53:36 <flwang> you can keep it as two bugs 21:53:50 <flwang> ok, anything else we need to discuss? 21:53:55 <flwang> we have 7 mins 21:53:59 <Eva-i> Maybe we should make etherpad with our tech debts 21:54:39 <Eva-i> I mean with new patches to make/include in RC1 21:55:00 <Eva-i> flwang: can you do it? 21:55:01 <ryansb> yeah, that'd be good 21:55:39 <flwang> Eva-i: all the RC1 patches need to be tracked with bug and all the bug will be tagged with 'release-critical' 21:55:39 <Eva-i> it's hard to keep them all in memory or reread chat logs 21:55:48 <Eva-i> oh, I see 21:56:02 <Eva-i> what bug reports we're missing then? 21:56:37 <flwang> Eva-i: i will go through all the patches and ask for bug if there is no and tag them if there is 21:57:10 <flwang> https://launchpad.net/zaqar/+milestone/mitaka-rc1 21:57:15 <Eva-i> flwang: oki, perhaps, you can tag these bug reports now https://bugs.launchpad.net/zaqar/+bug/1552866 https://bugs.launchpad.net/zaqar/+bug/1547131 21:57:15 <openstack> Launchpad bug 1552866 in zaqar "Subscriptions in mongodb are not renewed on TTL UPDATE" [Undecided,New] - Assigned to Eva Balycheva (ubershy) 21:57:16 <openstack> Launchpad bug 1547131 in zaqar "Subscription patching to duplicate in mongodb should return 409 response" [Undecided,New] - Assigned to Eva Balycheva (ubershy) 21:57:47 <Eva-i> because they have no fixes now 21:57:54 <flwang> Eva-i: will do 21:58:01 <flwang> Eva-i: give me some seconds 21:59:20 <Eva-i> sure ;) 21:59:50 <flwang> ok, cool, thank you guys 21:59:58 <flwang> let's talk in zaqar channel 22:00:01 <flwang> #endmeeting