21:12:18 <flwang> #startmeeting zaqar
21:12:19 <openstack> Meeting started Mon Feb 15 21:12:18 2016 UTC and is due to finish in 60 minutes.  The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:12:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:12:24 <openstack> The meeting name has been set to 'zaqar'
21:12:25 <flwang> oh, it works
21:12:45 <flwang> #topic code review
21:13:11 <flwang> we did a great a great job for zaqar client, both coding and reviewing
21:13:42 <flwang> until now, we almost filled all the function gaps
21:13:48 <ryansb> I guess it does, neat
21:13:55 <flwang> ryansb: :)
21:14:22 <Eva-i> hello
21:14:32 <ryansb> #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7145
21:14:39 <ryansb> #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7096
21:14:55 <ryansb> #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7139
21:15:09 <ryansb> ^ all talks on zaqar for summit, for everbody's convenience
21:16:04 <flwang> awesome
21:16:16 <flwang> thanks ryansb collecting those links
21:16:28 <flwang> i even don't know 7145
21:16:45 <flwang> let's discuss them in next topic
21:16:53 <ryansb> yeah, the speaker tweeted at me the other day
21:17:04 <flwang> for zaqar server side, we do still have some patches need to be reviewed
21:17:28 <flwang> TTL subscription issue for mongoDB https://review.openstack.org/270464
21:17:30 <Eva-i> ryansb: thank you
21:17:43 <flwang> TTL subscription issue for redis https://review.openstack.org/276548
21:18:12 <flwang> for the redis, it's still WIP. i'm still trying to figure out a way to fix it
21:18:29 <flwang> and this one https://review.openstack.org/265723   more attributes for queue
21:18:51 <flwang> binary support for websocket https://review.openstack.org/256978
21:19:22 <flwang> BTW, you guys maybe noticed, we have 2 new contributors from Huawei
21:19:33 <flwang> wanghao and wxy
21:19:37 <Eva-i> flwang: redis one is hard one, I'll try to review it
21:19:45 <Eva-i> flwang: yes
21:19:57 <flwang> pls give them more care :)  thanks
21:20:38 <ryansb> yup, love having new faces about
21:21:03 <Eva-i> flwang: oki
21:21:12 <flwang> anything else for code review topic?
21:21:51 <Eva-i> not from me
21:22:29 <ryansb> nope - I haven't been writing zaqar code. Bad me.
21:23:11 <flwang> #topic zaqar UI
21:23:36 <flwang> with the big support from horizon team, we made a great progress on zaqar UI
21:23:57 <flwang> now with the queues panel, you can list all the queues and create queue
21:24:12 <Eva-i> flwang: I saw it, good job
21:24:14 <flwang> update, delete will come soon
21:24:30 <flwang> pls try it and let me know your feedback
21:24:55 <flwang> subscriptions panels is coming as well
21:25:02 <Eva-i> flwang: I can only try, I can't understand the code written for Zaqar UI
21:25:21 <flwang> #link https://review.openstack.org/#/q/project:openstack/zaqar-ui
21:25:43 <ryansb> \o/
21:25:49 <flwang> #link https://review.openstack.org/#/c/277257/ the subscriptions panel
21:26:15 <flwang> subscriptions panel is little bit tricky since zaqar needs the queue name to list subscriptions
21:26:22 <flwang> so we need some ideas on this one
21:26:27 <flwang> how to show them
21:26:44 <flwang> again, pool and flavor won't come until Newton
21:27:13 <flwang> in Mitaka, we will focus on the user part.   Sorry, operators
21:27:29 <openstackgerrit> Merged openstack/python-zaqarclient: Improve subscription listing  https://review.openstack.org/272909
21:28:11 <flwang> #topic puppet and ansible
21:28:58 <flwang> jasondotstar said he don't have much bandwidth on the puppet zaqar work
21:29:02 <flwang> dprice will take over
21:29:15 <flwang> i haven't sync with dprice, but will do
21:29:21 <ryansb> *dprince
21:29:43 <flwang> ryansb: sorry :(
21:29:47 <flwang> dprince
21:29:58 <ryansb> no worries
21:30:01 <flwang> ryansb: another redhater  IIRC
21:30:05 <ryansb> he is
21:30:19 <flwang> btw,  the ansible zaqar spec has been approved   https://review.openstack.org/#/c/269889/
21:30:44 <vkmc> sweeeet
21:30:44 <flwang> but i haven't got time to work on that, since i don't know much about ansible :(
21:31:01 <ryansb> oh, neato. I happen to write lots of ansible :)
21:31:13 <flwang> ryansb: kidding me?
21:31:21 <flwang> ryansb: would you like to take it?
21:31:36 <ryansb> I would :) I can't guarantee I'll get to it fast, but I'll try
21:31:47 <flwang> again, we(Catalyst IT) is very keen to deploy zaqar
21:31:59 <ryansb> heh, so ansible would be handy
21:32:00 <flwang> but unfortunately, now there is no way
21:32:17 <flwang> ryansb: i will give you some example project
21:32:27 <flwang> ironic and designate ansible
21:32:41 <flwang> ryansb: awesome awesome awesome
21:34:38 <ryansb> K, sounds good. Next topic then?
21:35:14 <Eva-i> I have an idea about subscription listing in Zaqar-UI, maybe we can discuss it after the meeting
21:35:57 <flwang> Eva-i: cool, sure
21:36:36 <flwang> i don't have much topics, TBH, unless you guys want to discuss the summit sessions and the design summit topics
21:36:43 <flwang> not sure if it's too early
21:37:19 <ryansb> Eva pasted a couple discussion items
21:37:25 <ryansb> http://paste.openstack.org/show/niT4ouOOEhedv2gCEWZO/
21:37:31 <ryansb> and http://paste.openstack.org/show/kYFFmShi2eiouoYnUz5B/
21:37:47 <Eva-i> ryansb: yes, thank you
21:38:25 <Eva-i> first paste about possible design summit topic/session
21:40:31 <flwang> reading...
21:41:01 <vkmc> regarding that one
21:41:08 <vkmc> we need to decouple wsgi transport from the API
21:41:17 <Eva-i> yes
21:41:32 <vkmc> right now websocket transport is independent from the API, but the wsgi transport is not
21:42:36 <ryansb> yeah, that's not great. I think the one parameter I'd want on any solution is it can't change any of the existing stuff we expose
21:43:16 <flwang> ryansb: +1
21:43:27 <vkmc> I see that coupling as a bug, and it's something I'd really like to change from our current code
21:43:41 <Eva-i> ryansb: what do you mean?
21:44:25 <ryansb> so the problem stated was that there's coupling between the WSGI & backends
21:45:04 <flwang> vkmc: Eva-i: so both of you're talking about a refactor, right?
21:45:09 <vkmc> flwang, yes
21:45:22 <Eva-i> flwang: right
21:45:39 <ryansb> and I was just saying that I don't have an incredibly strong opinion on how to break it apart, just that I don't want to change anything we expose as-is over the API (which is part of the definition of refactor)
21:46:11 <flwang> i see. then i would suggest register a blueprint to track it, personally, i would like to see a detailed plan
21:46:13 <Eva-i> ryansb: if we refactor things properly, the API change will be unnoticed by the user
21:46:27 <flwang> and what's the part we should improve
21:46:41 <ryansb> yup :) that's the idea. Anyways, I think a blueprint would be a good start, and we shouldn't dealy until summit
21:46:54 <ryansb> *delay
21:46:59 <Eva-i> I can write the blueprint
21:47:05 <flwang> Eva-i: cool. thanks
21:47:13 <ryansb> Eva-i++
21:47:17 <flwang> i have another interesting topics if you guys still have time
21:47:21 <Eva-i> thank you guys =)
21:47:25 <flwang> queue's metadata
21:47:58 <flwang> as you know, we were trying to remove queue's metadata in v1.1 since we would like to make queue as lazy
21:48:07 <flwang> however, finally, we decide to keep it
21:48:08 <vkmc> Eva-i++
21:48:24 <flwang> now, the problems are coming
21:48:47 <flwang> 1. there is no way to update queue's metadata since v1.1
21:49:04 <Eva-i> hm, I don't remember deciding to keep it
21:49:24 <Eva-i> but I'm a newbie
21:49:34 <flwang> Eva-i: i can't remember the details
21:49:39 <flwang> but that's the decision
21:49:43 <vkmc> flaper87, ^ can you relate to this?
21:49:50 <flwang> and as the code saying, we're keeping it
21:50:18 <flwang> we run into this issue when working on the zaqar UI
21:50:40 <flwang> now with the zaqar client v2, there is no way to create a queue with metadata
21:50:57 <flwang> and worse, no way to update metadata after the queue created
21:52:03 <Eva-i> flwang: even on API v1?
21:52:12 <flwang> Eva-i: no
21:52:27 <flwang> for v1, user can set the metadata
21:53:04 <vkmc> v1.1 and v2 are the problematics
21:53:07 <flwang> #link https://bugs.launchpad.net/python-zaqarclient/+bug/1543900
21:53:07 <openstack> Launchpad bug 1543900 in zaqar "Can't update metadata after create queue for v1.1 and v2" [High,New] - Assigned to Fei Long Wang (flwang)
21:53:56 <flwang> vkmc: ryansb: flaper87: i would like to know your comments if we should support metadata for v1.1 and v2 like v1
21:54:05 <flwang> given we're keeping it
21:54:15 <ryansb> yeah, I think we should keep update support
21:54:18 <flwang> and queue is very important for subscriptions
21:54:25 <ryansb> err, support for updating queue metadata
21:54:40 <ryansb> indeed it is
21:55:08 <vkmc> I think it's useful and we should have a way to change it
21:55:12 <vkmc> metadata I mean
21:55:17 <vkmc> I don't remember why we removed that
21:55:26 <flwang> in the future, we may split notification from the messaging/queuing, but for now, we still need queue
21:55:38 <flwang> vkmc: since the lazy queue
21:55:51 <flwang> and we did some research from rackspace
21:55:56 <vkmc> flwang, but why we didn't create queues with empty metadata and allowed update?
21:55:59 <vkmc> hmm
21:56:04 <flwang> seems there are not too much user using metadata
21:56:11 <vkmc> I see
21:56:33 <flwang> but finally, we got some feedback from operators (not sure), then we decide to keep metadata
21:56:47 <vkmc> I see
21:56:53 <ryansb> This may not be public info, but how many is "not many"
21:57:01 <Eva-i> https://blueprints.launchpad.net/zaqar/+spec/api-v1.1-remove-queue-metadata
21:57:07 <flwang> ryansb: i can't remember :(
21:57:20 <ryansb> because "not many" of all the rackspace users may still be lots
21:57:45 <flwang> Based on feedback at the summit, we decided as a team to leave metadata as-is. --kgriffs
21:57:57 <flwang> see the last line of the blueprint
21:58:10 <flwang> so, I would say let's fill the gaps
21:58:15 <ryansb> +1
21:58:16 <vkmc> hey guys, gotta rush
21:58:19 <vkmc> will read the backlog later
21:58:21 <vkmc> o/
21:58:24 <ryansb> kk, catch you later
21:58:29 <Eva-i> oki
21:58:31 <flwang> vkmc: ok, ttyl
21:59:14 <flwang> so personally, i would like to support the metadata actions for v1.1 and v2
21:59:16 <Eva-i> okay, we may support queue metadata in API v1.1 and API v2
21:59:30 <flwang> that means, we need to fix the metadata update bug on server side
21:59:43 <flwang> and provide the metadata support for client side
22:00:05 <flwang> ryansb: vkmc: flaper87: how do you think?
22:00:49 <ryansb> I think that's the way to go
22:01:08 <ryansb> IMO metadata is a useful thing to have, and doesn't mean queues can't be lazy
22:01:42 <Eva-i> ryansb: right
22:02:18 <Eva-i> ryansb: I also wanted to ask your opinion about queue lazyness in subscriptions
22:02:27 <ryansb> k, shoot
22:02:43 <flwang> ryansb: cool, thanks for the feedback
22:03:10 <flwang> Eva-i: what's the design? re queue lazyness in subscriptions
22:03:26 <Eva-i> ryansb: the problem is queues stop being lazy on operations with subscriptions
22:03:42 <flwang> IMHO, subscribe a non-existing object is weird
22:03:43 <Eva-i> ryansb: though in API v2 queues are considered to be lazy
22:04:57 <Eva-i> ryansb: maybe we should make it possible to subscribe to unexisting queue
22:05:37 <ryansb> hm. Good thought. Let's get into a user's mind first
22:05:49 <ryansb> so if you're a user, and you can send messages to queues that don't exist
22:05:57 <ryansb> without creating them first
22:06:24 <ryansb> then you, the user, would probably think you were also able to subscribe to a queue that doesn't yet exist
22:06:31 <ryansb> does that make sense to you?
22:07:08 <Eva-i> for me it makes sense
22:07:31 <flwang> ryansb: for that case, i would agree only if the queue is crated in background just like posting messages
22:07:53 <flwang> instead of created a subscription on a non-existing queue
22:08:13 <ryansb> yeah, for messages we're actually creating queues in the background
22:08:15 <Eva-i> queues are topics
22:08:17 <ryansb> so subs could be the same
22:08:27 <ryansb> flwang: That's what you mean, right?
22:08:31 <flwang> queue is not existing before creating the subscription, but after created the subscriptions, the queue should be created already
22:08:46 <flwang> ryansb: yes
22:08:51 <Eva-i> you can say to Zaqar: I would to listen about this topic. If there will be someting, please notify me.
22:08:58 <Eva-i> *would like to
22:09:08 <flwang> ryansb: but
22:09:24 <flwang> it's still a little bit weird for me, TBH
22:09:32 <flwang> some users may like it
22:09:40 <ryansb> hm, which users wouldn'
22:09:46 <ryansb> *wouldn't like it
22:09:51 <Eva-i> for me it's not weird
22:09:52 <flwang> ryansb: haha, me :)
22:10:13 <flwang> ryansb: because
22:10:19 <ryansb> well what *type* of user? flwang isn't a type ;)
22:10:38 <flwang> i maybe wrong
22:11:09 <flwang> as a user, i create a subscription with a non-existing queue name 'horizon'
22:11:24 <flwang> then there is another user in the same tenant
22:11:50 <flwang> he may post messages on 'horizon' before creating it
22:12:14 <flwang> i haven't think it very clearly
22:13:04 <flwang> but i'm just wondering if there is a case like above, user A may get messages from user B who don't want his message spread unintentionally
22:13:28 <flwang> even though they're in same tenant
22:13:59 <ryansb> if they want isolation, shouldn't they be in different tenants?
22:14:13 <ryansb> I mean, I feel like that's what tenants/projects are for
22:14:53 <flwang> ryansb: i see
22:15:00 <Eva-i> hm, I'll think about it.
22:15:19 <flwang> Eva-i: could you please register a bp and propose a spec?
22:15:30 <flwang> Eva-i: generally, i think it's a good idea
22:15:36 <flwang> but i just need some more thoughts
22:15:45 <Eva-i> flwang: okay, I can make it. I'll invite flaper87 to spec review =)
22:15:47 <flwang> maybe i'm too worry
22:16:06 <flwang> Eva-i: cool
22:16:11 <flwang> Eva-i: thanks
22:16:50 <Eva-i> flwang: thank you too =)
22:17:28 <flwang> ryansb: as for the summit sessions, how can i see the vote status?
22:17:42 <ryansb> I don't think we get to know until the end
22:18:14 <flwang> ryansb: ok, i see
22:18:41 <flwang> ryansb: i will spread them into China openstack chat groups
22:18:56 <ryansb> :) Thank you
22:19:37 <flwang> thank you!
22:20:05 <ryansb> I think that covers all our topics, yes?
22:20:43 <Eva-i> I don't have anything else to discuss now
22:21:38 <Eva-i> maybe just an idea for Zaqar-UI subscription listing
22:22:08 <flwang> ryansb: yep, thank you guys
22:22:16 <flwang> Eva-i: what's the idea?
22:22:30 <ryansb> flwang: remember to #endmeeting
22:22:40 <flwang> #endmeeting