| *** reed has quit IRC | 00:30 | |
| *** reed has joined #openstack-zaqar | 01:03 | |
| *** flwang has joined #openstack-zaqar | 01:05 | |
| *** alcabrera|afk is now known as alcabrera | 01:17 | |
| *** vkmc has joined #openstack-zaqar | 01:31 | |
| *** jeffrey4l has joined #openstack-zaqar | 01:41 | |
| *** reed has quit IRC | 01:55 | |
| *** echevemaster has quit IRC | 02:17 | |
| *** vkmc has quit IRC | 02:59 | |
| *** openstackgerrit has quit IRC | 03:08 | |
| *** openstackgerrit has joined #openstack-zaqar | 03:10 | |
| *** openstackgerrit has quit IRC | 03:18 | |
| *** openstackgerrit has joined #openstack-zaqar | 03:18 | |
| *** alcabrera is now known as alcabrera|afk | 04:03 | |
| *** sgotliv has joined #openstack-zaqar | 04:27 | |
| *** flaper87|afk is now known as flaper87 | 06:14 | |
| *** sgotliv has quit IRC | 06:33 | |
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar: Add a pool_group to pools in v1.1 https://review.openstack.org/124079 | 06:37 |
|---|---|---|
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar: Add first reliability enforcement https://review.openstack.org/123750 | 06:37 |
| *** sgotliv has joined #openstack-zaqar | 07:59 | |
| *** flaper87 is now known as flaper87|afk | 08:25 | |
| *** flaper87|afk is now known as flaper87 | 08:59 | |
| *** jeffrey4l has quit IRC | 09:39 | |
| *** jeffrey4l has joined #openstack-zaqar | 09:51 | |
| *** prashanthr_ has joined #openstack-zaqar | 11:13 | |
| prashanthr_ | Hi flaper87: Sorry for the delay | 11:41 |
| prashanthr_ | Will add sentinel support very soon | 11:41 |
| flaper87 | prashanthr_: hey hey, no need to be sorry, really. I'm just doing PTL duties and unfortunately that means I gotta push some things back | 11:42 |
| flaper87 | but it's not your fault. Thanks for working on that | 11:42 |
| prashanthr_ | I have not been active at all. From today I will surely be more active and also write code faster :) | 11:42 |
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar: Add first reliability enforcement https://review.openstack.org/123750 | 11:47 |
| flaper87 | prashanthr_: did you get everything sorted for the summit? | 11:53 |
| flaper87 | see you in 1 month from today? | 11:53 |
| flaper87 | OMFG, I just realized the summit is 1 month away | 11:53 |
| *** sgotliv has quit IRC | 12:02 | |
| prashanthr_ | flaper87: Yes everything has been sorted :) | 12:16 |
| prashanthr_ | yeah just one month left | 12:16 |
| prashanthr_ | my visa processing is also underway | 12:16 |
| flaper87 | great | 12:16 |
| flaper87 | looking forward to meet you there | 12:16 |
| prashanthr_ | Same here :) | 12:17 |
| *** sgotliv has joined #openstack-zaqar | 12:17 | |
| *** vkmc has joined #openstack-zaqar | 12:18 | |
| *** vkmc has quit IRC | 12:18 | |
| *** vkmc has joined #openstack-zaqar | 12:18 | |
| *** prashanthr_ has left #openstack-zaqar | 12:23 | |
| flaper87 | vkmc: helllloooooooo | 12:23 |
| vkmc | flaper87, heeeeeeeey | 12:23 |
| flaper87 | vkmc: how are you doing? | 12:35 |
| flaper87 | Can I bother you with 2 review requests? | 12:35 |
| flaper87 | I'd like to get those patches merged before my 1x1 with ttx today | 12:35 |
| flaper87 | vkmc: https://review.openstack.org/#/c/123230/7 and https://review.openstack.org/#/c/124079/ | 12:36 |
| vkmc | flaper87, not a problem, I should review those yesterday | 12:36 |
| flaper87 | Kurt already +2'd the later, I just updated the docs so feel free to ninja-approve an say that the last PS just udpated docs | 12:36 |
| vkmc | flaper87, I'm doing ok! a bit tired, dunno what is going on with me this week | 12:37 |
| vkmc | flaper87, and you? | 12:37 |
| * flaper87 gives vkmc some gummy bears and coffee \_/? | 12:37 | |
| vkmc | nom nom nom | 12:37 |
| *** fifieldt has joined #openstack-zaqar | 12:37 | |
| * flaper87 hates pep8 | 12:37 | |
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar: Add first reliability enforcement https://review.openstack.org/123750 | 12:38 |
| *** vkmc has quit IRC | 12:51 | |
| *** vkmc has joined #openstack-zaqar | 12:52 | |
| *** sriram has joined #openstack-zaqar | 13:04 | |
| *** sgotliv has quit IRC | 13:05 | |
| *** mpanetta has joined #openstack-zaqar | 13:11 | |
| *** jchai has joined #openstack-zaqar | 13:14 | |
| vkmc | flaper87, are we cutting rc1 today? | 13:16 |
| flaper87 | vkmc: I'm hoping so, we need to get those 2 bugs fixed | 13:16 |
| flaper87 | meaning, land those patches I mentioned above | 13:16 |
| *** sgotliv has joined #openstack-zaqar | 13:18 | |
| vkmc | +1 | 13:20 |
| flaper87 | vkmc: lemme know when you're done with the reviews | 13:21 |
| vkmc | I'm a bit worried about the master-slave execution | 13:23 |
| vkmc | what happen if it fails on the slave? | 13:23 |
| vkmc | oh haha https://review.openstack.org/#/c/123230/3/zaqar/queues/storage/redis/claims.py | 13:23 |
| vkmc | forgot the link | 13:23 |
| flaper87 | well, in theory, it shouldn't fail because things are executed in the same order as in the master node | 13:24 |
| flaper87 | however, the slave can crash | 13:24 |
| flaper87 | in that case, when it comes up, it'll start from where it left | 13:24 |
| flaper87 | in a master-slave scenario, this shouldn't happen | 13:25 |
| flaper87 | BUT (wait for it): | 13:25 |
| vkmc | it could happen, if there is some issue we cannot control | 13:25 |
| flaper87 | "In theory, theory and practice are the same. In practice, they are not." (Albert Einstein) | 13:26 |
| *** mpanetta has quit IRC | 13:26 | |
| vkmc | haha wise words | 13:26 |
| flaper87 | ;) | 13:26 |
| *** mpanetta has joined #openstack-zaqar | 13:26 | |
| vkmc | well I think that is the best effort approach | 13:26 |
| flaper87 | I don't think best-effort would happen here: | 13:27 |
| flaper87 | think of this | 13:27 |
| flaper87 | Master gets these tasks: | 13:27 |
| flaper87 | 1. write A | 13:27 |
| flaper87 | 2. run script X | 13:27 |
| flaper87 | 3. delete C | 13:27 |
| * vkmc nods | 13:27 | |
| flaper87 | then it tells the slave: Hey, do these things in the exact same order: | 13:27 |
| flaper87 | 1. | 13:27 |
| flaper87 | 2. | 13:27 |
| flaper87 | 3. | 13:28 |
| flaper87 | Assuming they both have a consistent starting point - which is fair to assume/expect here - nothing bad should happen | 13:28 |
| flaper87 | unless it happens *outside* redis | 13:28 |
| flaper87 | which, as you said, we cannot control | 13:28 |
| vkmc | yeah my concern is | 13:28 |
| vkmc | what happens if in 2. the slave dies for some reason | 13:28 |
| vkmc | but you told me that it continues from the last point, I guess, 1. | 13:29 |
| flaper87 | yeah, all those operations are atomic | 13:30 |
| flaper87 | they either succeed or fail | 13:30 |
| flaper87 | if they fail they don't alter the state of the db | 13:30 |
| vkmc | that is what I wanted to hear | 13:30 |
| vkmc | :D | 13:30 |
| flaper87 | why didn't you ask that? | 13:30 |
| flaper87 | :P | 13:30 |
| vkmc | because I | 13:30 |
| * flaper87 is messing with vkmc's head | 13:30 | |
| vkmc | I'm slow sometimes | 13:30 |
| vkmc | ahahaha | 13:30 |
| vkmc | read sometimes as most of the times | 13:31 |
| mpanetta | Hey guys :) | 13:31 |
| mpanetta | I have a quick question. | 13:31 |
| vkmc | hey mpanetta :) | 13:31 |
| mpanetta | What storage backends does queues support these days? | 13:31 |
| vkmc | Redis and MongoDB | 13:31 |
| mpanetta | how ya doin vkmc? | 13:32 |
| mpanetta | Ok sweet | 13:32 |
| vkmc | mpanetta, good thx, and you? | 13:32 |
| mpanetta | Was rabbitmq on the table or no? | 13:32 |
| mpanetta | Busy! But good :) | 13:32 |
| flaper87 | mpanetta: it was more like *under* the table | 13:32 |
| vkmc | I hear ya >.> | 13:32 |
| flaper87 | :P | 13:32 |
| mpanetta | flaper87: haha | 13:32 |
| vkmc | yeah unfortunately that won't happen | 13:33 |
| *** malini1 has joined #openstack-zaqar | 13:33 | |
| mpanetta | Unfortunately? | 13:33 |
| vkmc | yeah, it was a cool idea | 13:33 |
| mpanetta | Why can't it happen? Not technically feasable? | 13:33 |
| vkmc | the good sir here present wrote a blog post about it http://blog.flaper87.com/post/marconi-amqp-see-you-later/ | 13:33 |
| mpanetta | Or just nobody to do it. | 13:34 |
| mpanetta | Ah! Thanks! | 13:34 |
| vkmc | not technically feasable | 13:34 |
| flaper87 | https://twitter.com/flaper87/status/517668830790057985 | 13:34 |
| mpanetta | lol | 13:34 |
| vkmc | lol | 13:34 |
| flaper87 | this channel is the best | 13:35 |
| mpanetta | I agree :) | 13:35 |
| flaper87 | we should tweet more often the great cool things we say here | 13:35 |
| flaper87 | and cool != smart | 13:35 |
| vkmc | it is | 13:35 |
| vkmc | we should set up a repository with some of the quotes in here | 13:35 |
| mpanetta | what, like bash.org? | 13:35 |
| vkmc | exactly | 13:35 |
| mpanetta | hahaha that would be awsome | 13:36 |
| * vkmc tried to make that looks as it was her idea | 13:36 | |
| vkmc | close enough | 13:36 |
| vkmc | hahaha | 13:36 |
| mpanetta | It wasn't? | 13:36 |
| mpanetta | :P | 13:36 |
| vkmc | maybe it was | 13:36 |
| vkmc | :p | 13:36 |
| vkmc | I was not stoling bash.org idea, not at all | 13:36 |
| *** mpanetta has quit IRC | 13:41 | |
| *** mpanetta has joined #openstack-zaqar | 13:41 | |
| mpanetta | GAH | 13:41 |
| mpanetta | stupid network | 13:41 |
| vkmc | flaper87, ninja approved your patch | 13:42 |
| flaper87 | vkmc: AWESOME, thanks! | 13:42 |
| vkmc | flaper87, thanks | 13:42 |
| vkmc | bbl | 13:43 |
| *** alcabrera|afk is now known as alcabrera | 13:55 | |
| openstackgerrit | A change was merged to openstack/zaqar: Move Redis driver's claim transaction to Lua https://review.openstack.org/123230 | 13:58 |
| openstackgerrit | A change was merged to openstack/zaqar: Improve efficiency of the redis driver when posting messages https://review.openstack.org/125175 | 13:58 |
| flaper87 | great, 1 patch left to merge | 13:58 |
| *** sgotliv has quit IRC | 14:10 | |
| openstackgerrit | A change was merged to openstack/python-zaqarclient: Add a read-only property for Queues https://review.openstack.org/121478 | 14:12 |
| openstackgerrit | A change was merged to openstack/zaqar: Add a pool_group to pools in v1.1 https://review.openstack.org/124079 | 14:15 |
| *** jeffrey4l has quit IRC | 14:15 | |
| flaper87 | ok, we're rc1-ready | 14:16 |
| flaper87 | vkmc: one more review request: https://review.openstack.org/#/c/123750/ | 14:17 |
| flaper87 | we should totally get that into juno | 14:17 |
| flaper87 | but not mandatory for rc1 | 14:17 |
| *** cpallares has joined #openstack-zaqar | 14:21 | |
| *** amitgandhinz has joined #openstack-zaqar | 14:21 | |
| *** sgotliv has joined #openstack-zaqar | 14:22 | |
| *** reed has joined #openstack-zaqar | 14:56 | |
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar-specs: Template for new storage driver's addition https://review.openstack.org/125658 | 14:58 |
| flaper87 | vkmc: kgriffs|afk ^ let me know what you thinkg | 14:59 |
| flaper87 | think* | 14:59 |
| *** kgriffs|afk is now known as kgriffs | 15:25 | |
| *** ametts has quit IRC | 15:27 | |
| * flaper87 lurks | 15:31 | |
| * kgriffs looking | 15:34 | |
| openstackgerrit | Flavio Percoco proposed a change to openstack/zaqar: Open Kilo development https://review.openstack.org/125681 | 15:37 |
| flaper87 | kgriffs: not urgent, whenever you have time | 15:39 |
| flaper87 | kgriffs: thanks and good morning, my friend. | 15:39 |
| kgriffs | sure thing | 15:39 |
| flaper87 | kgriffs: btw, redis patch landed... w00000t | 15:41 |
| kgriffs | oh good | 15:42 |
| kgriffs | shoot | 15:42 |
| kgriffs | I just noticed this one seems to have stalled | 15:42 |
| kgriffs | https://review.openstack.org/#/c/121474/ | 15:42 |
| kgriffs | it's essential for HA | 15:43 |
| kgriffs | anyone seen Prashanth around lately? | 15:43 |
| kgriffs | flaper87: perhaps I should just update the patch myself and we can merge it real quick for RC? | 15:43 |
| kgriffs | flaper87: or has RC1 already been cut? | 15:45 |
| flaper87 | kgriffs: RC1 is closed: https://review.openstack.org/#/c/125681/ | 15:48 |
| flaper87 | but we can have rc2 if needed | 15:48 |
| flaper87 | we can still get it in before the release | 15:48 |
| kgriffs | ok. so make a branch and backport after this merges? | 15:49 |
| flaper87 | I talked to prashanth earlier today, he said he's getting back to this patch this week | 15:49 |
| flaper87 | kgriffs: correct | 15:49 |
| kgriffs | oic | 15:49 |
| flaper87 | kgriffs: lets give him today and tomorrow | 15:49 |
| flaper87 | if he can't get back to it, we can restore it | 15:49 |
| flaper87 | I'd like to get this one in too: https://review.openstack.org/#/c/123750/ | 15:49 |
| flaper87 | hint hint, review ;) | 15:49 |
| flaper87 | :D | 15:50 |
| kgriffs | yep, I've started reviewing that | 15:50 |
| kgriffs | ok, so let's try to get those two into rc2 plus if we find anything critical during smoke testing that needs to be fixed. | 15:50 |
| *** jchai is now known as jchai_afk | 15:51 | |
| flaper87 | +1 | 15:51 |
| flaper87 | kgriffs: in addition to that, we need to document the "recomended" deployment for both redis and mongodb | 15:51 |
| flaper87 | we can do that later | 15:51 |
| kgriffs | oh, that is a good point | 15:51 |
| flaper87 | but I think it's important | 15:51 |
| kgriffs | i'm still tempted to add support for simple queue-level sharding across multiple redis instances without having to use a pool (as I've brought up before) but I am trying to resist the urge to add anything else to RC2 | 15:52 |
| flaper87 | kgriffs: did you see this? https://www.dropbox.com/s/w2ufh784co1m5pf/insert.jpg?dl=0 | 15:52 |
| flaper87 | kgriffs: I'd probably do that in Kilo, we need to discuss that better | 15:53 |
| flaper87 | I think | 15:53 |
| flaper87 | kgriffs: that link is a sharded mongodb deployment | 15:53 |
| kgriffs | regarding redis, yeah, another reason to resist the urge | 15:53 |
| flaper87 | it's the graph of how writes are distributed across shards | 15:53 |
| kgriffs | interesting | 15:54 |
| kgriffs | what's the shard key? | 15:54 |
| flaper87 | kgriffs: http://paste.openstack.org/show/117806/ | 15:55 |
| flaper87 | that one | 15:55 |
| flaper87 | the marker index inverted | 15:55 |
| flaper87 | which, btw, I think we're not actually using | 15:55 |
| kgriffs | i want to say that we are using it to enforce the unique constraint so we know when there was a collision | 15:56 |
| flaper87 | kgriffs: ah yeah, good point | 15:58 |
| flaper87 | I had forgotten about that | 15:58 |
| flaper87 | then yeah, we're using it | 15:58 |
| flaper87 | :D | 15:59 |
| flaper87 | this gives that index another use | 15:59 |
| kgriffs | are you using hash-based sharding vs. range-based? | 15:59 |
| flaper87 | range based | 16:00 |
| flaper87 | hashed indexes can't be used in compound indexes | 16:00 |
| kgriffs | oic | 16:01 |
| flaper87 | #sadpanda | 16:01 |
| kgriffs | I hadn't learned much about those yet since they are kinda sorta newish | 16:01 |
| * kgriffs is a just-in-time learner | 16:01 | |
| * flaper87 is a JIT learner too | 16:01 | |
| flaper87 | or should I say: WINI | 16:01 |
| flaper87 | whenever I need it | 16:01 |
| flaper87 | :P | 16:02 |
| flaper87 | which is basically JIT | 16:02 |
| kgriffs | if it is range-based, wouldn't that cause the distribution to be less even than your graphs show? I think I'm missing something. | 16:02 |
| flaper87 | so, the k gives enough cardinality to distribute data across shards and the p_j field keeps them all together | 16:02 |
| flaper87 | the reason I moved k as the first field is because otherwise all writes would go to the last shard | 16:03 |
| flaper87 | (since k is sequentially incremented) | 16:03 |
| flaper87 | with this, it hits the last shard of the group of shards used for p_j | 16:03 |
| flaper87 | but inserts are basically ordered by k first | 16:03 |
| flaper87 | does that make sense? | 16:04 |
| flaper87 | that's what I've been telling myself :P | 16:04 |
| flaper87 | kgriffs: http://paste.openstack.org/show/117814/ | 16:05 |
| flaper87 | that's the status | 16:05 |
| kgriffs | oic | 16:06 |
| kgriffs | so you will get ranges of messages for each queue colocated | 16:06 |
| flaper87 | right | 16:07 |
| kgriffs | seems like there is a small chance that a queue might bleed over to another shard? | 16:07 |
| flaper87 | yeah, I think there's a chance, we'll have to play with chunks sizes, I guess | 16:08 |
| kgriffs | and in that case a very small chance that someone listing messages (not claiming them) would miss one since that unique index constraint is not enforced across shards afaik | 16:08 |
| flaper87 | oh wait, isn't it? | 16:08 |
| flaper87 | I.... didn't know that | 16:08 |
| kgriffs | idk | 16:08 |
| flaper87 | ok, let me check that | 16:08 |
| kgriffs | something to check | 16:08 |
| flaper87 | I think it is but I'll check right away | 16:09 |
| kgriffs | kk | 16:09 |
| kgriffs | btw, here is a thought I just had that may or may not turn into something useful | 16:09 |
| kgriffs | I was thinking about how swift has decoupled containers from the data in the containers | 16:10 |
| kgriffs | like, the "list of things" in a container is held in sqlite iirc | 16:10 |
| kgriffs | but that is replicated separately from the actual "things" | 16:10 |
| kgriffs | I wonder if a similar notion might be useful for the Redis driver. You could track the message IDs that are in a queue in one place | 16:11 |
| kgriffs | but then the messages could be flung to the wind / replicated / etc. in a different way | 16:11 |
| flaper87 | "in one place" => "in redis but separate set/list" | 16:12 |
| flaper87 | ? | 16:12 |
| kgriffs | (like I said, this is a nascent thought, so not sure if it makes sense yet) | 16:12 |
| kgriffs | flaper87: yeah, well it is already sort of like that | 16:12 |
| kgriffs | there is a set that is used to index the message IDs | 16:13 |
| kgriffs | but why does it have to live on the same redis node? | 16:13 |
| kgriffs | also, consider that the index is actually what determines the ordering/rank of the messages | 16:13 |
| flaper87 | that reminds me our discussion of considering queues part of the "control" plane instead of the "data" plane | 16:14 |
| kgriffs | if it gives you enough info to go find those messages that are perhaps sharded across a hashring of nodes, then you can still bring them together and preserve the stateless marker semantics that are necessary to implement an RESTful message pub/sub feed | 16:15 |
| kgriffs | flaper87: good thought | 16:15 |
| *** sgotliv has quit IRC | 16:15 | |
| kgriffs | in any case, you still end up with a bottlneck but it is much lighter and should be easy to scale that to a level such that other things become bigger bottlenecks anyway | 16:16 |
| flaper87 | I don't think your idea is crazy. What if we have a "register_message" method or something like that in the queue_controller | 16:16 |
| flaper87 | that may/may not be implemented | 16:16 |
| flaper87 | depending on the driver | 16:16 |
| kgriffs | hmmm | 16:16 |
| kgriffs | so for each message post operation the driver would get two calls? | 16:17 |
| kgriffs | first, to "register_messages" | 16:17 |
| kgriffs | then, to "post_messages"? | 16:17 |
| kgriffs | the message IDs would have to be returned from the former and passed to the latter | 16:17 |
| kgriffs | consider it for mongodb | 16:19 |
| kgriffs | hmm | 16:19 |
| flaper87 | probably the other way around | 16:19 |
| flaper87 | what if post_messages calls register_messages | 16:19 |
| kgriffs | actually, it may be less performant | 16:20 |
| * kgriffs is thinking | 16:20 | |
| flaper87 | oh no wait, that sounds like a bad idea. I'd like to keep control plane and data planse separated | 16:20 |
| flaper87 | as much as possible | 16:20 |
| kgriffs | yeah | 16:20 |
| * flaper87 is making all this up | 16:20 | |
| kgriffs | LOL | 16:20 |
| kgriffs | well, what I was going to say about mongo was if you could use a hashed shard key to distribute the message payloads and then use range-based to lookup what messages belong in the queue from a different collection, you could evenly distribute messages around the cluster | 16:22 |
| * vkmc lurks and reads the backlog | 16:22 | |
| kgriffs | and you would be in much less danger of a "queue" bleeding over, since it would basically just be a list of some IDs and maybe a little bit of metadata | 16:23 |
| kgriffs | downside is that now I have to make two calls to get messages | 16:23 |
| kgriffs | the redis driver already has to do that, but it is offset a little bit since Redis is so fast | 16:24 |
| kgriffs | (it could be done in a single lua call, but then you just tightly coupled the queue IDs and the messages into the same DB) | 16:24 |
| flaper87 | not sure I understand why you need 2 calls to get messages | 16:24 |
| flaper87 | mongodb knows in which shard each record is | 16:24 |
| kgriffs | you would have a call to list the object IDs of the messages that belong to a queue | 16:25 |
| flaper87 | mmh, why? | 16:25 |
| kgriffs | the "queue_messages" collection would be sharded like you are doing now with the messages collections | 16:25 |
| flaper87 | I mean, all that information is already in mongodb | 16:26 |
| flaper87 | the config server contains all that metadata | 16:26 |
| flaper87 | it knows how chunks were split across shards | 16:26 |
| kgriffs | flaper87: what that does is create a sort of app-level index, like was done (out of necessity due to it's lack of higher-order operations) for the redis driver. | 16:26 |
| kgriffs | for each queue you have a list of message IDs (object IDs) | 16:27 |
| kgriffs | you list those in one call | 16:27 |
| kgriffs | then you go get those messages from a different collection | 16:27 |
| kgriffs | the advantage is you can choose to shard the two collections in different ways | 16:28 |
| kgriffs | the disadvantage is you have to jump through more hoops to get those messages | 16:28 |
| flaper87 | ah wait, you're explaining how your idea would be implemented in mongodb | 16:28 |
| kgriffs | yeah | 16:28 |
| *** alcabrera is now known as alcabrera|afk | 16:28 | |
| flaper87 | ah ok | 16:28 |
| flaper87 | sorry | 16:28 |
| kgriffs | just a thought experiment | 16:28 |
| flaper87 | now I get why you're saying the whole 2-step things | 16:29 |
| kgriffs | idk if the tradeoff is worth it, but it may be worth a POC | 16:29 |
| kgriffs | flaper87: heh, sorry. It makes more sense once you work with the Redis driver a bit, because it forces you to do things a different way. | 16:30 |
| kgriffs | so, really the idea is a result of cross-referencing swift's architecture with some concepts I noticed while reviewing the Redis driver | 16:31 |
| flaper87 | yeah, I don't think it's a terrible idea, it would be useful to have some sort of POC or at least to write it down. | 16:31 |
| flaper87 | so we can reason about it | 16:31 |
| flaper87 | design session ? | 16:31 |
| flaper87 | :D | 16:31 |
| kgriffs | definitely be easier to discuss in person | 16:31 |
| vkmc | just one doubt | 16:40 |
| vkmc | I remember that flaper87 suggested the idea of removing queues as they are right now | 16:40 |
| vkmc | are we still considering that? | 16:41 |
| kgriffs | well, even if we do that there will still be some notion of "tags" or "topics" | 16:41 |
| vkmc | of course | 16:41 |
| kgriffs | and that would be were the ID indexes would live | 16:41 |
| kgriffs | (i guess) | 16:41 |
| flaper87 | I think we can move one step closer to removing queues | 16:41 |
| flaper87 | for example, it'd be great if we would create queues *just* for those that are explicitly created | 16:42 |
| flaper87 | that basically means we need another way to list queues | 16:42 |
| vkmc | idk if it makes sense to do a queue level sharding if we are going to remove queues as they are | 16:42 |
| vkmc | that is why I'm asking | 16:43 |
| flaper87 | what we would remove is the concept of "queue" as a container | 16:43 |
| flaper87 | but we still need something (topic?) to group messages together | 16:43 |
| vkmc | yeah, we are going to have a queue attribute instead of a data structure | 16:43 |
| flaper87 | vkmc: we kinda already have that (p_q) | 16:44 |
| flaper87 | queues imply order, IMHO, which is why I think FIFO makes sense | 16:44 |
| vkmc | cool | 16:44 |
| flaper87 | but if we end up making FIFO optional, we probably could also change the term | 16:45 |
| kgriffs | wrt FIFO | 16:45 |
| vkmc | hmm yeah | 16:45 |
| vkmc | queues == FIFO | 16:46 |
| kgriffs | personally, I care less about the need for gauranteeing some sort of platonic ideal re FIFO and more about the practical concern of just not missing a message | 16:46 |
| kgriffs | that being said, a long-standing complaint of SQS was its lack of such guarantees | 16:47 |
| kgriffs | not saying we should try to do it better just to prove we can, but something to consider | 16:47 |
| kgriffs | but let me address the first point | 16:48 |
| kgriffs | if I am listing messages in a stateless, REST architecture, the client needs a marker | 16:48 |
| flaper87 | my tendency to prefer FIFO is that there are cases that require it and I believe it makes sense to support it if we can | 16:48 |
| kgriffs | if you don't keep messages in some kind of order, markers don't work | 16:48 |
| flaper87 | making it optional removes the burden of having to support it for every queue | 16:48 |
| kgriffs | there are three questions I think we need to answer | 16:49 |
| kgriffs | actually more than that | 16:49 |
| kgriffs | 1. what are the performance consequences of relaxing the FIFO constraint? | 16:50 |
| kgriffs | 2. what the scaling consequences? | 16:50 |
| kgriffs | 3. is it possible to list messages (not claim them) in a stateless manner (client keeps track of marker) without the FIFO constraint? | 16:51 |
| kgriffs | (and guarantee a message will never be missed) | 16:51 |
| kgriffs | 4. If not, should we also relax the guaranteed deliver constraint? | 16:51 |
| flaper87 | 3. is exactly what I think we shouldn't do. I mean, asking the client to do that is cheating, IMHO. | 16:51 |
| kgriffs | 5. And/Or should we make listing messages optional | 16:52 |
| kgriffs | 6. And/or should we split Zaqar into two different APIs and services | 16:52 |
| kgriffs | </end> | 16:52 |
| kgriffs | I don't think some people realize how much we have agonized over questions like these, careful weighing the tradeoffs to arrive where we are today. | 16:53 |
| flaper87 | mmh, I think resolving the FIFO thing is a matter of answering 1 and 2 | 16:53 |
| flaper87 | hehe, I was reading the ehterpad where we discussed FIFO | 16:53 |
| vkmc | 1. relaxing the FIFO constraing would retrievals very expensive | 16:53 |
| flaper87 | man, we put lots of thoughts on that | 16:53 |
| flaper87 | really | 16:53 |
| kgriffs | I'm not saying we are in a perfect place today, but I think everyone needs to realize this is very complex and there are lots of things we need to keep in mind as we continue to iterate on the project. | 16:54 |
| vkmc | and it would also have a negative impact in several use cases | 16:54 |
| kgriffs | not least of which, is what end users want/need | 16:54 |
| vkmc | +1 to that | 16:54 |
| flaper87 | I'm not sure it'd make retrievals expensive, if anything it'll make writes cheaper | 16:54 |
| *** jchai_afk is now known as jchai | 16:54 | |
| kgriffs | I think these questions could form the basis of a very good discussion at the summit. | 16:55 |
| flaper87 | I think we also need to ask ourselves how doing optional things will afect the drivers | 16:55 |
| kgriffs | I'm sure there are other questions you all would add as well | 16:55 |
| * kgriffs lives two seconds in the future | 16:55 | |
| flaper87 | :P | 16:56 |
| vkmc | flaper87, yeah, but it will be really expensive if we want to guarantee ordering | 16:56 |
| vkmc | it's a tradeoff | 16:56 |
| vkmc | as everything in computing >.> | 16:56 |
| flaper87 | something I'm trying to figure out now is how can we make the storage driver aware of the features enabled for a queue | 16:58 |
| flaper87 | we have flavors, great.... | 16:58 |
| flaper87 | but we don't have a way to tell the driver: "Hey, this queue is supposed to be ordered" | 16:58 |
| vkmc | hm | 17:01 |
| vkmc | good point | 17:01 |
| *** cpallares has quit IRC | 17:11 | |
| kgriffs | fwiw | 17:15 |
| kgriffs | https://etherpad.openstack.org/p/zaqar-design-constraints | 17:15 |
| kgriffs | There is a line in there that may be inflamatory so I will remove it | 17:15 |
| kgriffs | bbl (lunch) | 17:25 |
| *** kgriffs is now known as kgriffs|afk | 17:26 | |
| *** alcabrera|afk is now known as alcabrera | 17:40 | |
| *** kgriffs|afk is now known as kgriffs | 17:53 | |
| vkmc | alcabrera, hey :) happy birthdaaaaaaaaaaaaaaaaaay \o/ | 17:55 |
| alcabrera | vkmc: thank! <3 | 17:56 |
| alcabrera | *thanks | 17:56 |
| vkmc | :D | 17:56 |
| vkmc | hope you are having a great day | 17:56 |
| alcabrera | it's... not so great, but the weekend is near. :) | 17:57 |
| vkmc | ohh boo | 17:57 |
| vkmc | yeah that's good | 17:57 |
| *** alcabrera is now known as alcabrera|afk | 18:02 | |
| *** alcabrera|afk is now known as alcabrera | 18:16 | |
| *** jchai has quit IRC | 18:18 | |
| *** ametts has joined #openstack-zaqar | 18:22 | |
| vkmc | flaper87, the spec for storage drivers looks really good | 18:37 |
| *** sgotliv has joined #openstack-zaqar | 18:41 | |
| *** jchai has joined #openstack-zaqar | 19:12 | |
| *** mpanetta_ has joined #openstack-zaqar | 19:19 | |
| *** mpanetta has quit IRC | 19:21 | |
| *** jchai is now known as jchai_afk | 19:30 | |
| *** jchai_afk is now known as jchai | 19:34 | |
| *** alcabrera is now known as alcabrera|afk | 19:52 | |
| *** malini1 has quit IRC | 20:00 | |
| *** sgotliv has quit IRC | 20:02 | |
| *** jchai is now known as jchai_afk | 20:11 | |
| *** mpanetta_ is now known as mpanetta | 20:21 | |
| *** jchai_afk is now known as jchai | 20:37 | |
| *** flaper87 is now known as flaper87|afk | 21:11 | |
| *** sriram has quit IRC | 21:20 | |
| *** malini1 has joined #openstack-zaqar | 21:26 | |
| *** malini1 has quit IRC | 21:51 | |
| *** jchai has quit IRC | 21:52 | |
| *** mpanetta has quit IRC | 21:52 | |
| *** kgriffs is now known as kgriffs|afk | 22:06 | |
| *** amitgandhinz has quit IRC | 22:25 | |
| *** kgriffs|afk is now known as kgriffs | 22:35 | |
| *** cpallares has joined #openstack-zaqar | 22:39 | |
| *** kgriffs is now known as kgriffs|afk | 22:47 | |
| vkmc | hey guys, any ideas on why this is happening? http://paste.openstack.org/show/117903/ | 23:03 |
| *** echevemaster has joined #openstack-zaqar | 23:34 | |
| *** kgriffs|afk is now known as kgriffs | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
