20:59:06 #startmeeting zaqar 20:59:07 Meeting started Mon Jan 4 20:59:06 2016 UTC and is due to finish in 60 minutes. The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:59:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:59:11 The meeting name has been set to 'zaqar' 20:59:14 #topic roll call 20:59:15 o/ 20:59:48 o/ 21:00:02 hello 21:00:45 it's our first meeting in 2016, i wish all you guys had a good xmas & new year holiday 21:02:07 merry xmas and happy new year for you too! 21:02:23 \o 21:02:28 yeah, very merry 21:02:54 ok, i don't have much new topics just those old ones 21:03:19 client, UI, puppet and some new features 21:03:38 #topic zaqar client 21:04:03 i'm still working on the subscription patches and please review them asap 21:04:15 since they're blocking the integration with ceilometer :) 21:04:24 yep, ceilometer integration 21:05:13 a core reviewer of ceiloemter just pinged me about this, they want to use zaqar as notifier of alarm 21:05:34 but they can't do that since we're missing it in our client 21:07:19 can you link them? 21:07:20 the mitaka M-2 is Jan 16-22 21:07:24 or is there a topic? 21:07:28 flwang: I recently faced a problem when I was unable to use subscriptions, just because there were no defaul values for some settings related to subscriptions in zaqar.conf, hope ceilometer team know about this 21:07:43 #link https://review.openstack.org/249395 21:07:56 #link https://review.openstack.org/261280 21:08:05 #link https://review.openstack.org/261282 21:08:12 #link https://review.openstack.org/261303 21:08:15 flwang: we noticed it with vkmc and I filled a bug report https://bugs.launchpad.net/zaqar/+bug/1529912 21:08:16 Launchpad bug 1529912 in zaqar "No default values for pipelines in [storage] section in zaqar.conf" [Undecided,New] 21:09:26 thanks 21:09:28 Eva-i: thanks, it's a 'valid' bug :) 21:10:37 oki 21:10:50 anything else we should talk about the zaqar client ? 21:11:39 #topic UI 21:11:49 no progress from my side 21:12:19 no progress from me either 21:12:27 i'm stuck at this patch https://review.openstack.org/#/c/258474/ 21:12:44 Eva-i: wow, didn't know about lp#1529912 21:12:59 if there is anybody know angular JS well, pls help take a look and feel free upload a new patch set 21:13:09 * ryansb does not sorry 21:13:50 ryansb: no worries, i will bug horizon team to get some help 21:14:01 jasondotstar: are you around? 21:15:26 ok, seems we can skip the puppet topic 21:15:38 #topic new features 21:15:46 1. delayed queues/messageas 21:16:01 #link https://review.openstack.org/260859 21:16:13 i got some good comments from ryansb 21:17:16 in summary, the basic idea is creating a new delay field/attribute for message and queue, so that the messages in the queue can't be visible in the 'delay' seconds 21:17:47 oh angular :| 21:18:48 as for the delay queues in SQS, pls ref http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html 21:18:59 any questions? 21:20:02 flwang: no questions now, I need to investigate 21:21:44 ryansb: could you pls explain your comment? re "Adding arbitrary delays doesn't seem like a "core" use case, and it'll probably put more load on our storage backends than it appears." 21:23:47 yeah, so I meant two things. The latter is that having both visible (standard) and not-yet-visible (delayed) messages is likely to reduce the hit rate for paginated queries we use against our backends 21:24:00 esp ones with less advanced query capabilities (redis) 21:24:45 ryansb: yep, the paginated query is a trouble 21:24:50 and that'd be sort-of alright since it would only affect folks that use that feature, so my comment was intended to be "if we implement this, we have to make sure it doesn't affect the normal case" 21:25:25 technically, we won't impact the normal case 21:25:55 currrently, we're using the .exists() method to check if the queue is eixsting before query messages 21:26:06 and for the former (it not being a core use case) I was trying to get across that I've not really seen many use cases where this is needed, and I don't know how popular the SQS version of this feature is 21:26:43 but given that I've used SQS frequently but never encountered a need for delayed messages, I'm not sure how many others have 21:26:57 and we can replace it with .get() to get the metadata of queue to decide if it's a delay queue 21:27:15 none of this means I don't like the feature, I just want to make sure there's a clear use case before we go implementing the spec 21:27:15 and then we can decide if add the 'delay' query 21:27:25 yeah, that's sensible 21:27:55 but if we want to support delayed message in normal queues, then we may always add the query condition 21:27:56 (and was the type of solution I was hoping for when I said "don't affect the normal case") 21:28:19 yeah, I'm not much of a fan of interleaving delayed and nondelayed messages 21:28:54 if users need it, we can do it as long as we're aware of the tradeoff. 21:28:55 ryansb: no problem, we can discuss it more :) 21:29:06 ryansb: really appreciated for the valuable comments 21:29:17 ryansb: yep, cool 21:30:16 2. another spec is about adding more reserved attributes of queues, see https://review.openstack.org/#/c/257622/ 21:31:07 in summary, it will support 'ttl' and 'max msg size' in queue metadata so that we can have flexible queues which don't have to use the global settings defined in zaqar.conf 21:37:00 having the ttl and max_msg_size attributes sounds like a very good addition to me 21:37:07 we need to give better use of the metadata 21:37:09 as we have it right now 21:37:23 and the delay queue feature 21:37:30 it's something I see no harm in adding it as a flavor 21:38:17 +1 for more metadata on queues 21:38:26 awesome 21:38:36 this feature need to be implemented in a way that no users can abuse the system 21:38:36 ok, i have done all my topics 21:38:40 anything else? 21:39:15 flwang: maybe docs, but you wanted this meeting to be short 21:40:03 *needs to be implemented 21:41:12 flwang: okay, we can discuss it in a chat 21:41:59 no, go ahead 21:42:08 okay 21:42:10 Eva-i: we have 17 mins for sure 21:43:12 I posted a patch with Zaqar config-reference. https://review.openstack.org/#/c/263405/ 21:43:21 You can render it and see if it's normal. 21:43:57 As you can see one person doesn't like that Zaqar configuration tables can't be generated now, but let's wait for other reviewers 21:44:21 *autogenerated 21:44:52 personally, I think manual docs > no docs 21:45:29 * ryansb doesn't have a meeting topic 21:46:21 ryansb: thanks for your +1, I agree 21:48:22 Eva-i: did you see the -1 from aj? 21:48:52 flwang: that's what I'm saying now 21:49:03 flwang: of course 21:49:50 Eva-i: i think it would be nice if you can update the commit message to explain how it's generated 21:49:58 it's really 'manual' actually 21:50:12 it would be nice if we can add the reason 21:50:56 okay, I'll update the commit message and now will mark this patch as WIP, alright? 21:51:22 flwang: I'm gonna sleep after this meeting 21:51:56 Eva-i: you don't have to update it as WIP, i think :) 21:52:05 ok, we can discuss it later 21:52:26 #topic open discussion 21:52:34 anything else? 21:52:36 flwang: hm, okay, then I think I'll try to update commit message now 21:53:56 Eva-i: it's no rush, take your time 21:54:22 ok, if there is no more topic, let's close the meeting and back to our channel 21:54:38 thank you, guys 21:54:53 thanks folks :) 21:54:57 ty 21:56:10 #endmeeting