21:00:48 <flwang> #startmeeting zaqar
21:00:48 <openstack> Meeting started Mon Jan 25 21:00:48 2016 UTC and is due to finish in 60 minutes.  The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:51 <openstack> The meeting name has been set to 'zaqar'
21:00:59 <flwang> #topic roll call
21:01:02 <flwang> o/
21:01:12 <njohnston> o/
21:01:17 <Eva-i> hello everyone
21:01:19 <jasondotstar> o/
21:02:03 <flwang> Eva-i: hi there
21:02:11 <ryansb> \o zaqarians
21:03:04 <flwang> ok, let's start :)
21:03:20 <flwang> #topic zaqar client
21:03:30 <flwang> #topic zaqarclient
21:03:57 <vkmc_> o/
21:04:14 <flwang> for now, the only functional gap for our client, is the pre-signed url, IIRC
21:04:41 <flwang> oh, and the claim support for v2
21:04:48 <flwang> https://review.openstack.org/253731
21:04:54 <flwang> https://review.openstack.org/265663
21:05:11 <flwang> i will give it a try for the pre-signed url today
21:05:36 <flwang> guys, pls add them on your list :)
21:05:41 <Eva-i> I think the test "test_signed_url" in the client needs to be fixed
21:05:53 <Eva-i> I'll try
21:06:06 <ryansb> added
21:06:28 <flwang> Eva-i: cool, just add your comments
21:06:32 <flwang> on the patch ;)
21:06:52 <Eva-i> yes
21:06:59 <flwang> anything else we need to discuss for the client side?
21:07:35 <Eva-i> no
21:07:57 <ryansb> not from me
21:08:06 <flwang> we do have some other patches for client side, but i won't highlight them here, pls go through the list and review them, thanks
21:08:17 <flwang> #topic zaqar-ui
21:09:05 <flwang> we have merged two patches of zaqar ui to get a workable panel for queues
21:09:12 <flwang> now, you can list queues
21:09:14 <ryansb> \o/
21:09:24 <flwang> ryansb: yep :)
21:09:25 <Eva-i> I tried zaqar-ui, it doesn't work for me
21:09:42 <flwang> Eva-i: i can help you offline
21:09:52 <Eva-i> oki
21:10:04 <flwang> since it's plugin mode, so TBH, it's not easy to deploy
21:10:38 <Eva-i> flwang: one guy visited us today and here's the paste for you: http://paste.openstack.org/show/hbvsnhNNFTxfMDkZIJku/
21:10:39 <flwang> for more functions, like create, delete, update, we have a horizon core member who will help us to get some samples
21:10:51 <flwang> Eva-i: AJ? yep, i saw that
21:11:00 <Eva-i> oki, good
21:11:06 <flwang> Eva-i: i will ping him to get more details, thanks for the heads up
21:12:05 <flwang> personally, i would like to complete the client work asap and focus on the zaqar UI
21:12:26 <flwang> my goal is complete the queues and subscriptions work in Mitaka
21:12:44 <flwang> and leave the pool and flavor a while, maybe in Newton
21:13:08 <flwang> so remember, we have a new zaqar-ui repo now, don't miss it :)
21:13:11 <ryansb> ah, can we have https://review.openstack.org/270464 as a topic, btw?
21:13:25 <flwang> ryansb: definately
21:13:32 <flwang> ryansb: it's on my topic list
21:13:42 <ryansb> (cool, sorry to interject)
21:15:08 <flwang> ryansb: thanks for the reminder :)
21:15:14 <flwang> anything else?
21:15:30 <flwang> otherwise, let's move to the server side
21:15:31 <Eva-i> yes
21:15:38 <flwang> Eva-i: yes?
21:15:39 <Eva-i> let's move to the server side
21:15:53 <Eva-i> flwang: I mean no, go on
21:15:59 <flwang> #topic the TTL of subscription
21:16:16 <flwang> ryansb: i saw your comments
21:16:51 <Eva-i> I think permanent subscriptions are dangerous thing
21:17:08 <flwang> i don't mind removing the default permanent setting for subscription TTL, but i would like to support it
21:17:33 <flwang> ryansb:  i can see your point for the keystone token example
21:17:43 <flwang> but i think they're different scenarios
21:18:01 <flwang> 1. login/token is a very frequent action
21:18:16 <ryansb> so would subscribe, in cloud-y contexts
21:18:19 <flwang> that's why admin always run into the problem, have to clean up the token table
21:19:08 <flwang> topic/queue subscription is not a very frequent action, there shouldn't be too much records in db
21:19:31 <ryansb> I disagree - for things like worker pools & user-facing notifications it would be
21:19:44 <ryansb> say, for example, a web app opens a websocket to zaqar for updates
21:19:56 <ryansb> every new instance of that page would get a subscription
21:20:07 <flwang> ryansb:  why?
21:20:29 <flwang> why every new instance of the page will get a new subscription?
21:21:07 <ryansb> because websockets wouldn't be able to share one, would they? They'd have different client IDs
21:21:50 <ryansb> and even if they could, you wouldn't share a subscription between users
21:22:04 <vkmc> yeah, agree with ryansb there
21:22:14 <vkmc> websocket open a new connection on every refresh
21:22:26 <ryansb> what I'm saying isn't "the default can't be a long time," I'm saying "we can't honestly tell users that subscriptions last forever"
21:22:33 <ryansb> especially not by default
21:23:03 <vkmc> I don't see the point of having forever lived subscriptions
21:24:42 <flwang> vkmc: for wsgi(not websocket) case, i think most of the subscription is aim to forever/permanent
21:24:44 <flwang> for example
21:25:03 <flwang> the new integration of ceilometer/aodh
21:25:19 <flwang> when user create an alarm, and using zaqar as the notifier
21:25:27 <Eva-i> flwang: I think websocket subscriptions should live only during connection time.
21:25:43 <flwang> do you think the user would like to use a TTL for the alarm?
21:26:02 <Eva-i> ceilometer should update subscriptions then
21:26:19 <flwang> Eva-i: sorry?
21:26:21 <ryansb> I think subscriptions should have to be renewed
21:26:35 <flwang> ryansb: Eva-i: who?
21:26:45 <ryansb> flwang: for example, ceilometer would say "subscribe me for 3 days"
21:26:47 <flwang> let the user manually update the alarm again and again?
21:27:01 <ryansb> and then after 2 days, ceilo would say "Give me another 3 days"
21:27:03 <ryansb> and so on
21:27:13 <flwang> ryansb: that's really weird for me
21:27:48 <flwang> let's make the topic clear
21:27:51 <vkmc> perhaps we could get some feedback from ceilo guys about that
21:28:35 <flwang> i don't mind making an explicit TTL and removing the default permanent subscription
21:28:57 <flwang> the thing we're discussing is if we should support the permanent TTL
21:29:52 <flwang> vkmc: we could
21:30:35 <flwang> ok, let me ask, what's the bad thing if we have a permanent subscription support?
21:30:50 <flwang> and given it's not a default setting
21:33:14 <ryansb> I think it'd still be disingenuous, because nothing is really "forever"
21:33:44 <vkmc> so... I'd say it potentially leads to wasted resources
21:33:52 <flwang> ryansb: user can delete them if they want to
21:34:54 <flwang> ryansb: i can't follow, sorry
21:35:23 <ryansb> flwang: so when a user says "subscribe me forever"
21:35:34 <ryansb> we can't guarantee the thing they subscribe will never fail
21:35:37 <vkmc> I guess my concern could be solved with some sort of garbage collector
21:35:43 <vkmc> or we leave that to the clients
21:35:49 <ryansb> or that they will remember to unsubscribe
21:35:55 <flwang> ryansb: no, it's different concept
21:36:19 <ryansb> I'd be ok with something like "you can ask for "forever" but if you aren't around for a month we're deleting the subscription"
21:36:36 <ryansb> I really don't want to make a situation where dead subs can live forever easily
21:36:39 <flwang> subscription fail is different' from the concept subscription removal
21:36:56 <ryansb> I mean *subscriber* fail
21:37:12 <ryansb> so if my app subscribes "forever" then the machine dies, it will never unsubscribe
21:37:14 <ryansb> leaving cruft
21:37:27 <vkmc> let's think about newsletter subscriptions, as an example
21:37:34 <vkmc> when you subscribe you don't define a TTL
21:37:39 <vkmc> it's ... permanent, right?
21:37:49 <flwang> ryansb: did you see the TTL concept on SNS?
21:38:06 <vkmc> but there is a cron job that sends you a reminder everytime in a while
21:38:30 <vkmc> looking at it that way this kinda starts making sense to me
21:39:05 <flwang> vkmc: i would say yep
21:39:17 <Eva-i> flwang: maybe you're right
21:39:24 <flwang> cron job is a 'permanent'/forever job, isn't it?
21:39:43 <vkmc> it's a scheduled job
21:40:00 <flwang> vkmc: that's not wrong either
21:41:28 <vkmc> ok, I guess we need to discuss this a bit further and make sure we are clear on what this constitutes
21:41:52 <flwang> vkmc: okay
21:42:01 <vkmc> there are use cases in which makes sense, as you pointed out flwang
21:42:09 <flwang> I will have a talk with ceilometer team and the searchlight team
21:42:50 <flwang> vkmc: i can see your guys concern, but I'm trying to get some balance
21:43:00 <vkmc> flwang++ sounds good to me
21:43:24 <flwang> i think the key of the software is to make user happy :)
21:43:44 <ryansb> truth
21:43:48 <Eva-i> if there will be no pernanent subscriptions in Zaqar, ceilometer should update subscriptions for the user, it the user wants pernanent subscription, so no manual updating
21:44:46 <flwang> Eva-i: let ceilometer update it?
21:44:48 <flwang> how?
21:45:33 <Eva-i> by some kind of daemon
21:45:40 <Eva-i> it's just an assumption
21:45:52 <flwang> Eva-i: it's impossible unfortunately
21:45:59 <flwang> from the ceiloemter PoV
21:46:11 <ryansb> could they use trusts like heat?
21:46:39 <flwang> see http://paste.openstack.org/show/484932/
21:46:48 <flwang> just get the feedback from ceilometer team
21:47:13 <vkmc> that was quick!
21:47:41 <flwang> ryansb: can the trusts resolve the TTL update issue?
21:48:17 <ryansb> basically it would be a delegated token with the perms to update the subscription, which they would use to keep extending the TTL
21:49:24 <ryansb> that's an implementation detail
21:49:48 <ryansb> but it's how heat deals with the delegation problem (where heat needs to do things in a user's stead)
21:49:50 <flwang> ryansb: yep, my point is user has the requirement to get a permanent subscription
21:51:09 <flwang> no matter the implementation details
21:51:15 <ryansb> fair enough
21:51:32 <ryansb> could we have some kind of TTL for *unused* subscriptions?
21:51:33 <flwang> so if we could have a built-in support, why not?
21:51:50 <ryansb> e.g. if a client doesn't call in to get its messages for X days/months/whatever we delete the sub?
21:53:18 <flwang> ryansb: hmm... if there isn't messages for a queue for X days/months/whatever, should we delete the queue?
21:53:38 <vkmc> you cannot predict that the queue has not been used because it's really not being used
21:54:02 <ryansb> I don't know about autodeleting queues
21:54:02 <flwang> vkmc: same
21:54:08 <vkmc> if zaqar wipes it out and then the client needs to use it... the queue will be created but the subscription no
21:54:09 <Eva-i> Or for example, the subscriber is not listening for a long time on the specified port in subscription. Or subscription email is not existing.
21:54:33 <Eva-i> But it's dangerous too to do it, the behavior of Zaqar would be less predictable in this case.
21:54:41 <vkmc> yeap
21:55:05 <flwang> ok, we're running out of time
21:55:18 <flwang> let's discuss it offline
21:55:26 <flwang> #topic open discussion
21:55:43 <flwang> should we propose some topics for summit?
21:55:53 <vkmc> design session? or pres? :)
21:56:06 <flwang> pres, i think, the deadline is 1 Feb
21:57:01 <vkmc> I haven't implemented anything this cycle in order to give a presentation
21:57:11 <vkmc> but I'd like to help
21:57:20 <flwang> the horizon guys just ping me to have a joint pres for horizon plugin, but i'm not sure if i can make it
21:57:24 <Eva-i> have you already made a pres for Zaqar's subscriptions?
21:57:38 <flwang> if i can't, hopefully you guys can help deliver it
21:57:55 <vkmc> Eva-i, nope
21:58:00 <Eva-i> it's the coolest feature of Zaqar
21:58:01 <vkmc> not on the summits at least
21:58:31 <Eva-i> I see
21:58:45 <flwang> vkmc: i would like to see a pres like micro service + container + zaqar
21:59:03 <vkmc> let's take this offline
21:59:08 <vkmc> and work on those ideas
21:59:09 <flwang> ryansb: you're the heavy user of SQS/SNS, do you think that's reasonble?
21:59:24 <flwang> vkmc: ok, cool
21:59:36 <flwang> let's end this meeting and rock on zaqar channel
21:59:40 <ryansb> what is, the subscriptions preso?
21:59:40 <flwang> thank you, guys
21:59:47 <ryansb> yeah, move to zaqar
21:59:49 <ryansb> thanks!
21:59:50 <flwang> #endmeeting