*** JAHoagie has quit IRC | 00:10 | |
*** kgriffs is now known as kgriffs|afk | 00:24 | |
*** nakul_cpani has joined #openstack-zaqar | 01:19 | |
*** nakul_cpani has left #openstack-zaqar | 01:19 | |
*** reed has quit IRC | 01:19 | |
*** reed has joined #openstack-zaqar | 01:22 | |
*** kgriffs|afk is now known as kgriffs | 01:24 | |
*** flwang1 has quit IRC | 01:26 | |
*** kgriffs is now known as kgriffs|afk | 01:33 | |
*** ametts has quit IRC | 01:39 | |
*** flwang1 has joined #openstack-zaqar | 01:39 | |
*** reed has quit IRC | 01:40 | |
*** flwang1 has quit IRC | 01:43 | |
*** amalagon has quit IRC | 02:05 | |
*** cpallares has quit IRC | 02:23 | |
*** nakul_cpani has joined #openstack-zaqar | 02:28 | |
*** nakul_cpani has left #openstack-zaqar | 02:30 | |
*** kgriffs|afk is now known as kgriffs | 03:12 | |
*** kgriffs is now known as kgriffs|afk | 03:22 | |
openstackgerrit | Jeffrey Zhang proposed openstack/zaqar: Version discovery for root URI https://review.openstack.org/130094 | 03:39 |
---|---|---|
*** jeffrey4l has joined #openstack-zaqar | 03:48 | |
*** kgriffs|afk is now known as kgriffs | 04:13 | |
*** kgriffs is now known as kgriffs|afk | 04:23 | |
openstackgerrit | Zhi Yan Liu proposed openstack/zaqar: Integrate OSprofiler with Zaqar https://review.openstack.org/141356 | 05:58 |
*** JAHoagie has joined #openstack-zaqar | 06:00 | |
*** kgriffs|afk is now known as kgriffs | 06:02 | |
*** nakul_cpani has joined #openstack-zaqar | 06:03 | |
*** nakul_cpani has left #openstack-zaqar | 06:03 | |
*** JAHoagie_ has joined #openstack-zaqar | 06:07 | |
*** JAHoagie has quit IRC | 06:07 | |
*** JAHoagie_ is now known as JAHoagie | 06:07 | |
*** kgriffs is now known as kgriffs|afk | 06:12 | |
*** JAHoagie has quit IRC | 06:52 | |
*** JAHoagie has joined #openstack-zaqar | 07:02 | |
*** exploreshai|afk has joined #openstack-zaqar | 07:37 | |
*** exploreshai|afk is now known as exploreshaifali | 07:38 | |
*** miqui_ has quit IRC | 07:50 | |
*** kgriffs|afk is now known as kgriffs | 07:51 | |
*** kgriffs is now known as kgriffs|afk | 08:00 | |
*** pcaruana|afk| is now known as pcaruana | 08:04 | |
*** jeffrey4l has quit IRC | 08:17 | |
*** jeffrey4l has joined #openstack-zaqar | 08:27 | |
*** dynarro has joined #openstack-zaqar | 08:34 | |
*** JAHoagie has quit IRC | 08:43 | |
*** pcaruana has quit IRC | 08:59 | |
*** dynarro_ has joined #openstack-zaqar | 09:10 | |
*** pcaruana has joined #openstack-zaqar | 09:12 | |
*** dynarro has quit IRC | 09:13 | |
*** jeffrey4l has quit IRC | 09:26 | |
*** kgriffs|afk is now known as kgriffs | 09:40 | |
*** jeffrey4l has joined #openstack-zaqar | 09:43 | |
*** kgriffs is now known as kgriffs|afk | 09:49 | |
*** dynarro_ has quit IRC | 09:51 | |
*** boris-42 has quit IRC | 09:53 | |
*** jeffrey4l has quit IRC | 10:47 | |
*** jeffrey4l has joined #openstack-zaqar | 11:00 | |
*** boris-42 has joined #openstack-zaqar | 11:06 | |
*** kgriffs|afk is now known as kgriffs | 11:29 | |
*** kgriffs is now known as kgriffs|afk | 11:38 | |
vkmc | morning o/ | 12:12 |
exploreshaifali | morning \o | 12:19 |
flaper87 | o/ | 12:24 |
exploreshaifali | woooooooow flaper87 is back :D | 12:33 |
exploreshaifali | vkmc: ^^ | 12:33 |
exploreshaifali | morning flaper87 :) | 12:34 |
kragniz | o/ | 12:34 |
vkmc | oh look at that | 12:34 |
vkmc | :) | 12:34 |
exploreshaifali | kragniz: \o/ | 12:34 |
flaper87 | exploreshaifali: gooooooooooooooooooooooooooooooood morning | 12:34 |
flaper87 | :) | 12:34 |
vkmc | kragniz, what's uuuup | 12:34 |
exploreshaifali | everyone has finished gummy bears packets..... :P while waiting for flaper87 | 12:35 |
kragniz | vkmc: a seagull which flapped rather aggressively at me on the walk to work | 12:35 |
kragniz | flaper87: you should call yourself seagull87 | 12:36 |
vkmc | kragniz, seagulls are evil | 12:36 |
*** miqui has quit IRC | 12:36 | |
*** jeffrey4l has quit IRC | 12:45 | |
exploreshaifali | vkmc: added stuff which we are doing right now.....I am moving towards 1st solution finally https://etherpad.openstack.org/p/exploreshaifali-opw-split-layers | 12:53 |
*** dynarro has joined #openstack-zaqar | 12:54 | |
exploreshaifali | just read the last section | 12:55 |
flaper87 | btw, The Imitation Game <- recommended | 13:01 |
kragniz | bah | 13:01 |
kragniz | flaper87: what did you think of the changing of the story? | 13:02 |
* kragniz hasn't seen it | 13:02 | |
*** jeffrey4l has joined #openstack-zaqar | 13:03 | |
*** exploreshaifali is now known as exploreshaifa|af | 13:09 | |
*** exploreshaifa|af is now known as exploreshaif|afk | 13:09 | |
*** jeffrey4l has quit IRC | 13:09 | |
openstackgerrit | Merged openstack/zaqar: Version discovery for root URI https://review.openstack.org/130094 | 13:12 |
flaper87 | kragniz: not big deal, really. | 13:15 |
*** kgriffs|afk is now known as kgriffs | 13:17 | |
*** kgriffs is now known as kgriffs|afk | 13:27 | |
*** jeffrey4l has joined #openstack-zaqar | 13:28 | |
*** jeffrey4l has quit IRC | 13:36 | |
vkmc | oh I wanted to watch that one | 13:38 |
vkmc | dynarro, heeeey there :) | 13:40 |
vkmc | dynarro, how are you doing? hacking a lot? | 13:41 |
dynarro | vkmc: hey! | 13:41 |
vkmc | exploreshaif|afk, I just checked the etherpad | 13:42 |
dynarro | yes, I'm doing a lot of applications and stuff like that to exercise | 13:42 |
vkmc | exploreshaif|afk, in the first approach, you are removing queue_controller from datadriverbase and putting it in controldriverbase? | 13:42 |
vkmc | dynarro, that's awesome | 13:43 |
dynarro | vkmc: :) | 13:43 |
dynarro | vkmc: and I also applied to a python course. So I'll do that as well =) | 13:45 |
vkmc | dynarro, cool, is it an online course or are you going to an academy in your home town? | 13:45 |
dynarro | it is an online course from MIT | 13:46 |
vkmc | neat! | 13:47 |
vkmc | I saw really interesting MIT courses | 13:47 |
dynarro | vkmc: yeah, the course I'll do seems really interesting. I'm really excited! | 13:50 |
kragniz | dynarro: what is it? | 13:50 |
dynarro | kragniz: is an introduction to computer science and programming with python | 13:52 |
kragniz | cool! | 13:52 |
dynarro | kragniz: yeah! it begins today! | 13:54 |
vkmc | w000t | 13:54 |
vkmc | :D | 13:54 |
vkmc | happy first day | 13:54 |
dynarro | vkmc: well I'll actually start it tomorrow because of the time slot | 13:55 |
vkmc | k, I'll wish you a happy first day tomorrow then | 13:56 |
dynarro | vkmc: thanks! and how are you doing? | 13:57 |
vkmc | dynarro, good good | 13:57 |
vkmc | trying to debug some stuff | 13:57 |
vkmc | I cannot make it work :@ | 13:57 |
dynarro | vkmc: oh dammit! well, good luck with that! | 13:58 |
vkmc | thx | 13:59 |
* dynarro gives some moral support to vkmc | 14:06 | |
* flaper87 knows how to fix vkmc's issue but he won't tell her | 14:07 | |
vkmc | flaper87, you would get gummybears | 14:09 |
flaper87 | vkmc: soooooooooooooooooooooooo, what's your problem again? | 14:11 |
*** jeffrey4l has joined #openstack-zaqar | 14:11 | |
* flaper87 wants to help, no special reason really... | 14:11 | |
flaper87 | it's nothing to do w/ gummybears | 14:11 |
vkmc | lol | 14:11 |
vkmc | I know, gummybears don't affect your behaviour at all | 14:12 |
*** sriram has joined #openstack-zaqar | 14:13 | |
vkmc | flaper87, https://bugs.launchpad.net/zaqar/+bug/1407786 | 14:14 |
vkmc | (I'm debugging something else, but now that you offered... :P) | 14:18 |
*** JAHoagie has joined #openstack-zaqar | 14:24 | |
*** JAHoagie has quit IRC | 14:32 | |
*** kgriffs|afk is now known as kgriffs | 14:33 | |
*** exploreshaifali has joined #openstack-zaqar | 14:35 | |
*** mpanetta has joined #openstack-zaqar | 14:37 | |
*** jeffrey4l has quit IRC | 14:37 | |
*** mpanetta_ has joined #openstack-zaqar | 14:39 | |
*** mpanetta has quit IRC | 14:39 | |
*** cpallares has joined #openstack-zaqar | 14:40 | |
*** kgriffs is now known as kgriffs|afk | 14:43 | |
*** ametts has joined #openstack-zaqar | 14:47 | |
*** mpanetta_ is now known as mpanetta | 14:54 | |
*** xyu_ has quit IRC | 14:56 | |
*** JAHoagie has joined #openstack-zaqar | 14:56 | |
*** amitgandhinz has joined #openstack-zaqar | 15:01 | |
*** nakul_cpani has joined #openstack-zaqar | 15:06 | |
*** exploreshaifali has quit IRC | 15:16 | |
*** amalagon has joined #openstack-zaqar | 15:22 | |
*** JAHoagie has quit IRC | 15:30 | |
*** kgriffs|afk is now known as kgriffs | 15:54 | |
*** bradjones has quit IRC | 16:01 | |
*** bradjones has joined #openstack-zaqar | 16:01 | |
*** bradjones has joined #openstack-zaqar | 16:01 | |
*** xyu_ has joined #openstack-zaqar | 16:03 | |
*** exploreshaifali has joined #openstack-zaqar | 16:05 | |
*** flwang has quit IRC | 16:06 | |
*** flwang has joined #openstack-zaqar | 16:18 | |
*** reed has joined #openstack-zaqar | 16:25 | |
*** dynarro has quit IRC | 16:37 | |
*** exploreshaif|afk has quit IRC | 16:42 | |
*** JAHoagie has joined #openstack-zaqar | 16:45 | |
*** amalagon has quit IRC | 16:46 | |
*** amalagon has joined #openstack-zaqar | 17:06 | |
* vkmc lurks | 17:38 | |
vkmc | what's up with this channel | 17:38 |
vkmc | so quiet | 17:38 |
kragniz | sssh | 17:38 |
* mpanetta falls asleep | 17:38 | |
kragniz | you'll wake everyone | 17:38 |
vkmc | oh its nap time | 17:38 |
vkmc | ok | 17:38 |
mpanetta | I wish :P | 17:56 |
mpanetta | Last 2 days ave been stressful | 17:57 |
cpallares | mpanetta: why is that? | 17:57 |
mpanetta | Product release | 17:57 |
vkmc | boo | 17:58 |
vkmc | nap under the desk! | 17:58 |
vkmc | now! | 17:58 |
mpanetta | hah | 17:58 |
cpallares | mpanetta: listen to vkmc | 18:03 |
mpanetta | cpallares: I try, but people keep asking me for help :P | 18:04 |
vkmc | mpanetta, put your hand and say to them 'talk to the hand' | 18:04 |
mpanetta | And I like helping, so... No naps for me! | 18:04 |
mpanetta | lol | 18:05 |
sriram | haha | 18:05 |
* flaper87 drumbs | 18:06 | |
vkmc | flaper87, don't mess with the nap | 18:09 |
cpallares | mpanetta: do a simple noise detection thingy that plays a recording of you saying "I don't know, let me think about it and get back to you" and do this http://bit.ly/1Kmi7Y0 | 18:10 |
*** jdaggett_ is now known as jdaggett | 18:10 | |
* flaper87 causes a terrible earthquake all around the world | 18:10 | |
mpanetta | LOL | 18:10 |
* flaper87 watches people suffering from his sweet spot in the moon | 18:10 | |
mpanetta | cpallares: That is hilarious | 18:10 |
flaper87 | cpallares: LOL | 18:10 |
*** nakul_cpani has left #openstack-zaqar | 18:11 | |
flaper87 | why do people people prefix python packages descriptions with "A python package that ..." | 18:11 |
flaper87 | ? | 18:12 |
flaper87 | I mean, it's a python package after all, why the extra worthy prefix? | 18:12 |
vkmc | captain obvious strikes again | 18:12 |
mpanetta | flaper87: Put a package in pypy that isn't python, and prefix it with what it is :P | 18:13 |
*** bradjones has quit IRC | 18:13 | |
flaper87 | mpanetta: that'd be hilarious | 18:13 |
*** bradjones has joined #openstack-zaqar | 18:19 | |
*** bradjones has quit IRC | 18:19 | |
*** bradjones has joined #openstack-zaqar | 18:19 | |
flaper87 | https://twitter.com/flaper87/status/552892857707925504 | 18:21 |
*** exploreshaifali has quit IRC | 19:10 | |
*** flwang1 has joined #openstack-zaqar | 19:50 | |
flwang | flaper87: ping | 19:59 |
flaper87 | flwang: pong | 19:59 |
flwang | flaper87: oh, man | 19:59 |
flaper87 | :D | 19:59 |
flwang | you have a long vacation | 19:59 |
flaper87 | weeeeeeeeeeeeeeeeeeeeelllllllll, tbh, I had a long silent, hidden, coding time | 20:00 |
flaper87 | :D | 20:00 |
flaper87 | flwang: how are you doing? | 20:00 |
*** JAHoagie has quit IRC | 20:01 | |
flwang | flaper87: good | 20:01 |
flwang | i had a long (11 days) vacation | 20:01 |
flwang | but most of the time I used to play with my son :) | 20:01 |
*** JAHoagie has joined #openstack-zaqar | 20:03 | |
flaper87 | flwang: that's good, very good! You're wiser than me | 20:05 |
flwang | I had tried to code, but the little hacker don't agree | 20:05 |
flwang | dpmdoesn't | 20:05 |
flwang | flaper87: do you have some time to discuss the notification? | 20:06 |
flaper87 | flwang: yes sir | 20:08 |
flaper87 | lets do it now before I get pulled into other stuff | 20:08 |
flwang | cool | 20:08 |
flwang | did you see the discussion between kgriffs and me | 20:09 |
flaper87 | ish, I read the backlog but I need to re-read it | 20:10 |
flaper87 | something I noticed is you were discussing about sharding the control plane | 20:10 |
flwang | right | 20:10 |
flaper87 | but please, feel free to refresh my mind or point me to links | 20:10 |
flwang | https://etherpad.openstack.org/p/zaqar-notification | 20:10 |
* vkmc jumps in | 20:11 | |
flwang | flaper87: the key point is if we should support sharding/pool for subscriptions | 20:11 |
vkmc | heeeeeeeey I want to be on the loop on this change | 20:11 |
flwang | vkmc: welcome :) | 20:11 |
flaper87 | vkmc: roger | 20:14 |
flaper87 | flwang: so, as of now, I don't think we need it. | 20:14 |
flwang | flaper87: okay | 20:14 |
flaper87 | but wait | 20:14 |
flaper87 | lets think out loud, I just got back from drunk land | 20:14 |
flaper87 | I mean, vacations | 20:14 |
flwang | flaper87: I just worry about the number of subscriptions | 20:15 |
flaper87 | flwang: do you expect there to be a need for pooling ? | 20:15 |
flwang | that means if we save all the subscriptions in single table/collections, the performance is a point we may need to concern, but it depends on the number of subscriptions | 20:16 |
flaper87 | one thing to remember is that zaqar-pools != mongodb-shards | 20:17 |
flaper87 | you can still shard the subscriptions database/collection and not having zaqar pools for it | 20:17 |
flaper87 | A zaqar pool *is* a different db connection URI | 20:17 |
flwang | flaper87: yep, i know | 20:17 |
flaper87 | ok | 20:18 |
flaper87 | we currently don't have pooling for the control plain, right? | 20:18 |
vkmc | but each zaqar pool is related to a queue | 20:18 |
flwang | vkmc: +1 | 20:18 |
flwang | our current pool design is tight coupling with 'queue' | 20:18 |
vkmc | so in the case of having n subscriptions and needing to search in the pools to get one | 20:18 |
vkmc | or delete one | 20:18 |
flwang | if we don't want support pool for subscriptions, it's fine | 20:19 |
flwang | if we do, the rest api of notifications will be impacted | 20:19 |
flaper87 | yup, that's really something we wanted, AFAICT | 20:19 |
vkmc | the complexity goes to hell | 20:19 |
flaper87 | I mean, pooling tight to queues | 20:19 |
flaper87 | although we made those considerations without thinking about subscriptions | 20:20 |
* flaper87 needs to dig into this code | 20:20 | |
flaper87 | one thing to clarify is whether we consider subscriptions data or control | 20:21 |
flaper87 | Since it's a user input, I'd tend to consider it as data | 20:21 |
flaper87 | and therefore it should be part of the data plane | 20:21 |
flwang | flaper87: yes | 20:21 |
vkmc | data++ | 20:21 |
flaper87 | but then we have a problem because of what you just mentioned | 20:22 |
flwang | my initial thought is control, but then I put it into data | 20:22 |
flaper87 | we'd need to make pooling not queue oriented | 20:22 |
flwang | so that's why I consider supporting 'pool' for it | 20:22 |
flwang | flaper87: why not 'project' oriented? | 20:22 |
vkmc | its the same reasoning that applies to queue | 20:23 |
flaper87 | flwang: it's way to high | 20:23 |
vkmc | now that we are moving it to the controlplane | 20:23 |
flaper87 | The more granular the sharding is done, the better | 20:23 |
flaper87 | queue pools are already way to broad and they prevent for scaling infinitedly (whatever that means) | 20:23 |
flwang | flaper87: ok, make sense | 20:23 |
* flaper87 thinking | 20:24 | |
flaper87 | (still thinking out loud) | 20:24 |
flaper87 | we can't make this based on queues because a subscription can be used for more than 1 queue, right ? | 20:24 |
vkmc | this problem could be eased if we keep the concept of queue | 20:24 |
flaper87 | (source) | 20:25 |
vkmc | queue/topic | 20:25 |
flaper87 | vkmc: TBH, I don't think queues are going anywhere on this cycle, not a high priority and not a big deal for now | 20:25 |
vkmc | how many benefits give us removing the queue/topic entity against keeping it? | 20:25 |
flaper87 | besides the resource-saving benefits I believe the biggest benefit is using the right semantics | 20:26 |
vkmc | ok then, having the queue/topic in the URL will keep searches efficient for subscriptions, is that correct flwang? | 20:26 |
flwang | flaper87: +1 | 20:26 |
vkmc | or am I missing something? | 20:26 |
flwang | vkmc: i think so, and it will keep the consistence with the other stuff, like messages, and claim | 20:27 |
flaper87 | vkmc: we don't have `queue` in the notification url | 20:27 |
flaper87 | IIRC | 20:27 |
flwang | flaper87: hold on | 20:27 |
vkmc | flaper87, we don't | 20:27 |
vkmc | but we could add it | 20:27 |
flwang | we don't want to to do that | 20:27 |
flaper87 | we don't want to add it | 20:27 |
flwang | but if we want to support pool | 20:27 |
flaper87 | AFAIR | 20:27 |
flwang | we have to do that | 20:27 |
flaper87 | :P | 20:27 |
vkmc | why we don't want to add it? | 20:28 |
flwang | personally, i don't like the url ' v2.0/queues/foo/subscriptions' | 20:29 |
vkmc | flaper87? | 20:29 |
vkmc | yeah I agree its long | 20:29 |
vkmc | but sometimes we have to sacrifice readability for usability | 20:30 |
flaper87 | we already have the queue in the notification body, don't we ? | 20:30 |
flaper87 | I'd vote for consistency | 20:30 |
flwang | flaper87: yep, we have the queue when create it | 20:31 |
flwang | but if we want to get/delete/update it, we don't have the 'queue' name, and it will make troubles to support pool | 20:31 |
flaper87 | ah, mmh, well... URL it is, I guess | 20:32 |
flwang | that's my point | 20:32 |
flwang | but if we want to keep 'queue' in the world | 20:32 |
flwang | and we don't mind using ' v2.0/queues/foo/subscriptions' | 20:33 |
flwang | then we're good to support pool for subscriptions | 20:33 |
flaper87 | flwang: go ahead and propose a patch to update the spec with the gist of this convo | 20:34 |
vkmc | +1 | 20:34 |
flaper87 | I'm good with it, if vkmc and kgriffs are good too, then we're all happy | 20:34 |
vkmc | in the case of messages the url is 'v1.1/queues/foo/messages' | 20:34 |
vkmc | so lets be verbose all the way | 20:34 |
flwang | but kgriffs's opinion is like we don't need pool for subscriptions | 20:34 |
flaper87 | I don't think we need it but if we're going to keep queues in the URL then we'll have it for free | 20:35 |
flwang | flaper87: yep, you got it | 20:36 |
vkmc | yup | 20:36 |
flwang | anyway | 20:36 |
vkmc | kgriffs said YAGNI | 20:36 |
vkmc | and I agree | 20:36 |
flwang | I will submit a patch and ask for you guys review it | 20:36 |
vkmc | but in this case it doesn't hurt to add it | 20:36 |
vkmc | and makes things consistent | 20:36 |
flwang | vkmc: yes | 20:36 |
flwang | and if we want to remove 'queue' in the future, then the subscription feature can be updated together | 20:37 |
flaper87 | flwang: agreed | 20:37 |
vkmc | exactly | 20:37 |
flaper87 | thanks for the heads up | 20:37 |
vkmc | +1 | 20:38 |
vkmc | thanks flwang | 20:38 |
flwang | thank you guys | 20:38 |
vkmc | if you have some more time, I'd to chat about the persistent transport change | 20:39 |
vkmc | a few design details | 20:39 |
vkmc | flaper87, flwang, kgriffs ^ | 20:39 |
vkmc | I'll give you cookies | 20:41 |
flwang | vkmc: I'm ok after 15 minutes | 20:41 |
flwang | I need to join a meeting in 2 mins | 20:41 |
vkmc | k | 20:42 |
*** exploreshaifali has joined #openstack-zaqar | 20:44 | |
flaper87 | vkmc: go go go | 20:45 |
vkmc | so... the first RFC is about the protocol | 20:46 |
vkmc | https://wiki.openstack.org/wiki/Zaqar/specs/Protocols/Wire_Transport | 20:46 |
vkmc | we have three fields: action, header and body | 20:47 |
* flaper87 reads carfully | 20:47 | |
flaper87 | what's up with that? | 20:47 |
vkmc | and for the Request class four fields were specified: operation == action, headers, params and content | 20:47 |
vkmc | so... I remember we considered that the body should contain the params | 20:48 |
vkmc | but it feels weird | 20:48 |
flaper87 | mmh, wait, isn't that what the body is for ? | 20:48 |
vkmc | and its harder to read/write | 20:48 |
flaper87 | what would go into params ? | 20:49 |
vkmc | so, the question is then... what is the content field in the Request class? | 20:49 |
vkmc | https://github.com/openstack/zaqar/blob/master/zaqar/common/api/request.py#L48 | 20:51 |
flaper87 | vkmc: that's probably a leftover from the copy/paste of the code that is in zaqarclient | 20:52 |
flaper87 | params are used to build the URL params in the client | 20:52 |
flaper87 | but I don't think they're needed in this protocol | 20:52 |
vkmc | oh I see | 20:52 |
vkmc | ok | 20:52 |
flaper87 | The request content contains everything that's required by the call | 20:52 |
flaper87 | get_queue requires a queue name | 20:52 |
vkmc | exactly yes | 20:52 |
flaper87 | so I expect there to be a name: queue_name in the body | 20:52 |
vkmc | here are some example requests https://review.openstack.org/#/c/144803/2/zaqar/transport/websocket/example.html | 20:53 |
vkmc | body is always empty | 20:53 |
vkmc | :p | 20:53 |
vkmc | so I'll put params in the body and fix the Request representation | 20:53 |
flaper87 | ah well, what's in params is actually body | 20:54 |
flaper87 | :P | 20:54 |
vkmc | cool | 20:55 |
vkmc | will fix that | 20:55 |
vkmc | second, we discussed about making the transport validate the content before creating the request and sending it to the api | 20:56 |
vkmc | I think we should consider doing the validations in the API | 20:56 |
vkmc | validations are tightly binded to the operation performed | 20:56 |
vkmc | and that is something that is known in the API | 20:56 |
vkmc | we can add it to the transport, but we will end adding a lot of code | 20:57 |
flaper87 | AFAIR, the validation code belongs to the API but it's called by the transport | 20:57 |
flaper87 | At least, that's how I was thinking about it | 20:57 |
vkmc | I see | 20:57 |
vkmc | well, in this case... maybe I'm thinking it the wrong way | 20:57 |
vkmc | the Request is created and sent to the API | 20:57 |
flaper87 | I think there's a validate method in the Api thing already | 20:57 |
vkmc | in that moment we don't know which operation is being performed | 20:58 |
flaper87 | So, the transport has an API instance, right ? | 20:58 |
vkmc | yup | 20:58 |
flaper87 | ok, in the transport, I thought we could do something like: | 20:58 |
flaper87 | api.validate(req) | 20:58 |
flaper87 | api.process(req) | 20:58 |
flaper87 | or just | 20:58 |
flaper87 | api.process(req) | 20:58 |
flaper87 | and let the Api call validate | 20:58 |
vkmc | but that validator doesn't validate some constrains we put in the requests | 20:58 |
flaper87 | does that make sense? | 20:58 |
vkmc | this is the validator you are thinking about https://github.com/openstack/zaqar/blob/master/zaqar/common/api/api.py | 20:59 |
vkmc | L52 precisely | 20:59 |
flaper87 | right, and then there are other validations done down the path | 20:59 |
vkmc | and this is the validator I'm thinking about https://github.com/openstack/zaqar/blob/master/zaqar/transport/validation.py | 20:59 |
flaper87 | in the API | 20:59 |
flaper87 | erm, I mean, in the transport | 20:59 |
flaper87 | yup, I'm following you there | 21:00 |
flaper87 | how did you imagine this would be implemented? | 21:00 |
vkmc | so, if I want to use the transport validator, I need to know which operation is the user performing | 21:00 |
vkmc | and that is something I know here https://review.openstack.org/#/c/141280/10/zaqar/api/v1_1/endpoints.py | 21:01 |
flaper87 | yup, but didn;t you add that validation there already? | 21:02 |
flaper87 | I swear I saw some updates to validation.py | 21:02 |
vkmc | nope because its in the transport | 21:02 |
vkmc | I put in the commit message as a reminder that I had to ask you guys about it | 21:02 |
flaper87 | I'm good with calling it from the Api | 21:02 |
vkmc | if I do perform the validation there we will be mixing the layers | 21:02 |
flaper87 | that makes sense to me | 21:02 |
flaper87 | I don't think it's mixing layers, you can actually move validations.py out of transport if you want | 21:03 |
flaper87 | it jus have common validation code to use | 21:03 |
vkmc | yep | 21:03 |
vkmc | we either access it from the api | 21:03 |
vkmc | or we move it | 21:03 |
vkmc | is the same | 21:03 |
vkmc | if we move it we have to refactor the wsgi transport | 21:03 |
flaper87 | you can even move it to api and then access it from transport | 21:03 |
flaper87 | right | 21:03 |
flaper87 | lets keep it there for now | 21:04 |
vkmc | k | 21:04 |
flaper87 | that's a minor change we can do later | 21:04 |
vkmc | cool | 21:04 |
vkmc | and finally | 21:04 |
vkmc | the ugly not-handled exceptions | 21:04 |
vkmc | in here https://review.openstack.org/#/c/141280/10/zaqar/api/v1_1/endpoints.py | 21:05 |
*** openstackgerrit has quit IRC | 21:05 | |
*** openstackgerrit has joined #openstack-zaqar | 21:06 | |
vkmc | given that those are there because its a cautious measurement | 21:06 |
vkmc | that is... the code should never reach that exception | 21:06 |
vkmc | in wsgi we would return an HTTP error code but in here we have to do something else | 21:06 |
vkmc | I was thinking we could, instead, return an common error Response | 21:06 |
vkmc | instead of making the server die | 21:07 |
vkmc | that way we don't have to rewrite a new set of exceptions that doesn't add much value | 21:07 |
vkmc | and we prevent the server for dying because the user made a wrong request | 21:07 |
vkmc | what do you guys think about it? | 21:08 |
flwang | vkmc: I agree | 21:11 |
flwang | is it possible to create a common base exception class for wsgi and the 'wire' protocol? | 21:12 |
vkmc | flwang, wired protocols and wsgi are managed in a different way... the cross transport api spec originally included wsgi, but making that change is not possible by design | 21:13 |
vkmc | so... wsgi will continue managing exceptions as it does now | 21:14 |
vkmc | and for wired transports, we can either have a common base exception class | 21:14 |
vkmc | (which I was trying to do) | 21:14 |
vkmc | or we create a common response for error cases, as I'm thinking it would be a better approach | 21:14 |
flwang | vkmc: ok, got it. does the 'common response' mean a common response class? | 21:17 |
vkmc | it means instantiating this class https://github.com/openstack/zaqar/blob/master/zaqar/common/api/response.py | 21:17 |
vkmc | with the corresponding error body | 21:18 |
flwang | vkmc: got | 21:20 |
flwang | make sense for me | 21:20 |
vkmc | +1 | 21:21 |
vkmc | if flaper87 and kgriffs agree | 21:21 |
vkmc | I'll make it happen | 21:21 |
*** bradjones has quit IRC | 21:40 | |
*** echevemaster has joined #openstack-zaqar | 21:42 | |
*** bradjones has joined #openstack-zaqar | 21:43 | |
*** bradjones has quit IRC | 21:43 | |
*** bradjones has joined #openstack-zaqar | 21:43 | |
*** echevemaster has quit IRC | 21:46 | |
flwang | flaper87: still around? | 21:55 |
*** sriram has quit IRC | 22:11 | |
kgriffs | just jumping in here without a lot of context, but would it make sense to have an exception handler that translates from errors to an instance of Response ? | 22:11 |
kgriffs | vkmc: you could have a base class for the exceptions you raise that knows how to serialize itself to create an error body (Response._content) | 22:14 |
*** mpanetta has quit IRC | 22:30 | |
*** echevemaster has joined #openstack-zaqar | 22:30 | |
vkmc | kgriffs, sounds good! | 23:02 |
*** amitgandhinz has quit IRC | 23:16 | |
exploreshaifali | flaper87, around? | 23:27 |
exploreshaifali | vkmc, there? | 23:29 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!