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