Wednesday, 2015-01-07

*** JAHoagie has quit IRC00:10
*** kgriffs is now known as kgriffs|afk00:24
*** nakul_cpani has joined #openstack-zaqar01:19
*** nakul_cpani has left #openstack-zaqar01:19
*** reed has quit IRC01:19
*** reed has joined #openstack-zaqar01:22
*** kgriffs|afk is now known as kgriffs01:24
*** flwang1 has quit IRC01:26
*** kgriffs is now known as kgriffs|afk01:33
*** ametts has quit IRC01:39
*** flwang1 has joined #openstack-zaqar01:39
*** reed has quit IRC01:40
*** flwang1 has quit IRC01:43
*** amalagon has quit IRC02:05
*** cpallares has quit IRC02:23
*** nakul_cpani has joined #openstack-zaqar02:28
*** nakul_cpani has left #openstack-zaqar02:30
*** kgriffs|afk is now known as kgriffs03:12
*** kgriffs is now known as kgriffs|afk03:22
openstackgerritJeffrey Zhang proposed openstack/zaqar: Version discovery for root URI  https://review.openstack.org/13009403:39
*** jeffrey4l has joined #openstack-zaqar03:48
*** kgriffs|afk is now known as kgriffs04:13
*** kgriffs is now known as kgriffs|afk04:23
openstackgerritZhi Yan Liu proposed openstack/zaqar: Integrate OSprofiler with Zaqar  https://review.openstack.org/14135605:58
*** JAHoagie has joined #openstack-zaqar06:00
*** kgriffs|afk is now known as kgriffs06:02
*** nakul_cpani has joined #openstack-zaqar06:03
*** nakul_cpani has left #openstack-zaqar06:03
*** JAHoagie_ has joined #openstack-zaqar06:07
*** JAHoagie has quit IRC06:07
*** JAHoagie_ is now known as JAHoagie06:07
*** kgriffs is now known as kgriffs|afk06:12
*** JAHoagie has quit IRC06:52
*** JAHoagie has joined #openstack-zaqar07:02
*** exploreshai|afk has joined #openstack-zaqar07:37
*** exploreshai|afk is now known as exploreshaifali07:38
*** miqui_ has quit IRC07:50
*** kgriffs|afk is now known as kgriffs07:51
*** kgriffs is now known as kgriffs|afk08:00
*** pcaruana|afk| is now known as pcaruana08:04
*** jeffrey4l has quit IRC08:17
*** jeffrey4l has joined #openstack-zaqar08:27
*** dynarro has joined #openstack-zaqar08:34
*** JAHoagie has quit IRC08:43
*** pcaruana has quit IRC08:59
*** dynarro_ has joined #openstack-zaqar09:10
*** pcaruana has joined #openstack-zaqar09:12
*** dynarro has quit IRC09:13
*** jeffrey4l has quit IRC09:26
*** kgriffs|afk is now known as kgriffs09:40
*** jeffrey4l has joined #openstack-zaqar09:43
*** kgriffs is now known as kgriffs|afk09:49
*** dynarro_ has quit IRC09:51
*** boris-42 has quit IRC09:53
*** jeffrey4l has quit IRC10:47
*** jeffrey4l has joined #openstack-zaqar11:00
*** boris-42 has joined #openstack-zaqar11:06
*** kgriffs|afk is now known as kgriffs11:29
*** kgriffs is now known as kgriffs|afk11:38
vkmcmorning o/12:12
exploreshaifalimorning \o12:19
flaper87o/12:24
exploreshaifaliwoooooooow flaper87 is back :D12:33
exploreshaifalivkmc: ^^12:33
exploreshaifalimorning flaper87 :)12:34
kragnizo/12:34
vkmcoh look at that12:34
vkmc:)12:34
exploreshaifalikragniz: \o/12:34
flaper87exploreshaifali: gooooooooooooooooooooooooooooooood morning12:34
flaper87:)12:34
vkmckragniz, what's uuuup12:34
exploreshaifalieveryone has finished gummy bears packets..... :P while waiting for flaper8712:35
kragnizvkmc: a seagull which flapped rather aggressively at me on the walk to work12:35
kragnizflaper87: you should call yourself seagull8712:36
vkmckragniz, seagulls are evil12:36
*** miqui has quit IRC12:36
*** jeffrey4l has quit IRC12:45
exploreshaifalivkmc: added stuff which we are doing right now.....I am moving towards 1st solution finally https://etherpad.openstack.org/p/exploreshaifali-opw-split-layers12:53
*** dynarro has joined #openstack-zaqar12:54
exploreshaifalijust read the last section12:55
flaper87btw, The Imitation Game <- recommended13:01
kragnizbah13:01
kragnizflaper87: what did you think of the changing of the story?13:02
* kragniz hasn't seen it13:02
*** jeffrey4l has joined #openstack-zaqar13:03
*** exploreshaifali is now known as exploreshaifa|af13:09
*** exploreshaifa|af is now known as exploreshaif|afk13:09
*** jeffrey4l has quit IRC13:09
openstackgerritMerged openstack/zaqar: Version discovery for root URI  https://review.openstack.org/13009413:12
flaper87kragniz: not big deal, really.13:15
*** kgriffs|afk is now known as kgriffs13:17
*** kgriffs is now known as kgriffs|afk13:27
*** jeffrey4l has joined #openstack-zaqar13:28
*** jeffrey4l has quit IRC13:36
vkmcoh I wanted to watch that one13:38
vkmcdynarro, heeeey there :)13:40
vkmcdynarro, how are you doing? hacking a lot?13:41
dynarrovkmc: hey!13:41
vkmcexploreshaif|afk, I just checked the etherpad13:42
dynarroyes, I'm doing a lot of applications and stuff like that to exercise13:42
vkmcexploreshaif|afk, in the first approach, you are removing queue_controller from datadriverbase and putting it in controldriverbase?13:42
vkmcdynarro, that's awesome13:43
dynarrovkmc: :)13:43
dynarrovkmc: and I also applied to a python course. So I'll do that as well =)13:45
vkmcdynarro, cool, is it an online course or are you going to an academy in your home town?13:45
dynarroit is an online course from MIT13:46
vkmcneat!13:47
vkmcI saw really interesting MIT courses13:47
dynarrovkmc: yeah, the course I'll do seems really interesting. I'm really excited!13:50
kragnizdynarro: what is it?13:50
dynarrokragniz: is an introduction to computer science and programming with python13:52
kragnizcool!13:52
dynarrokragniz: yeah! it begins today!13:54
vkmcw000t13:54
vkmc:D13:54
vkmchappy first day13:54
dynarrovkmc:  well I'll actually  start  it tomorrow because of the time slot13:55
vkmck, I'll wish you a happy first day tomorrow then13:56
dynarrovkmc: thanks! and how are you doing?13:57
vkmcdynarro, good good13:57
vkmctrying to debug some stuff13:57
vkmcI cannot make it work :@13:57
dynarrovkmc:  oh dammit! well, good luck with that!13:58
vkmcthx13:59
* dynarro gives some moral support to vkmc14:06
* flaper87 knows how to fix vkmc's issue but he won't tell her14:07
vkmcflaper87, you would get gummybears14:09
flaper87vkmc: soooooooooooooooooooooooo, what's your problem again?14:11
*** jeffrey4l has joined #openstack-zaqar14:11
* flaper87 wants to help, no special reason really...14:11
flaper87it's nothing to do w/ gummybears14:11
vkmclol14:11
vkmcI know, gummybears don't affect your behaviour at all14:12
*** sriram has joined #openstack-zaqar14:13
vkmcflaper87, https://bugs.launchpad.net/zaqar/+bug/140778614:14
vkmc(I'm debugging something else, but now that you offered... :P)14:18
*** JAHoagie has joined #openstack-zaqar14:24
*** JAHoagie has quit IRC14:32
*** kgriffs|afk is now known as kgriffs14:33
*** exploreshaifali has joined #openstack-zaqar14:35
*** mpanetta has joined #openstack-zaqar14:37
*** jeffrey4l has quit IRC14:37
*** mpanetta_ has joined #openstack-zaqar14:39
*** mpanetta has quit IRC14:39
*** cpallares has joined #openstack-zaqar14:40
*** kgriffs is now known as kgriffs|afk14:43
*** ametts has joined #openstack-zaqar14:47
*** mpanetta_ is now known as mpanetta14:54
*** xyu_ has quit IRC14:56
*** JAHoagie has joined #openstack-zaqar14:56
*** amitgandhinz has joined #openstack-zaqar15:01
*** nakul_cpani has joined #openstack-zaqar15:06
*** exploreshaifali has quit IRC15:16
*** amalagon has joined #openstack-zaqar15:22
*** JAHoagie has quit IRC15:30
*** kgriffs|afk is now known as kgriffs15:54
*** bradjones has quit IRC16:01
*** bradjones has joined #openstack-zaqar16:01
*** bradjones has joined #openstack-zaqar16:01
*** xyu_ has joined #openstack-zaqar16:03
*** exploreshaifali has joined #openstack-zaqar16:05
*** flwang has quit IRC16:06
*** flwang has joined #openstack-zaqar16:18
*** reed has joined #openstack-zaqar16:25
*** dynarro has quit IRC16:37
*** exploreshaif|afk has quit IRC16:42
*** JAHoagie has joined #openstack-zaqar16:45
*** amalagon has quit IRC16:46
*** amalagon has joined #openstack-zaqar17:06
* vkmc lurks17:38
vkmcwhat's up with this channel17:38
vkmcso quiet17:38
kragnizsssh17:38
* mpanetta falls asleep17:38
kragnizyou'll wake everyone17:38
vkmcoh its nap time17:38
vkmcok17:38
mpanettaI wish :P17:56
mpanettaLast 2 days ave been stressful17:57
cpallaresmpanetta: why is that?17:57
mpanettaProduct release17:57
vkmcboo17:58
vkmcnap under the desk!17:58
vkmcnow!17:58
mpanettahah17:58
cpallaresmpanetta: listen to vkmc18:03
mpanettacpallares: I try, but people keep asking me for help :P18:04
vkmcmpanetta, put your hand and say to them 'talk to the hand'18:04
mpanettaAnd I like helping, so... No naps for me!18:04
mpanettalol18:05
sriramhaha18:05
* flaper87 drumbs18:06
vkmcflaper87, don't mess with the nap18:09
cpallaresmpanetta: 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/1Kmi7Y018:10
*** jdaggett_ is now known as jdaggett18:10
* flaper87 causes a terrible earthquake all around the world18:10
mpanettaLOL18:10
* flaper87 watches people suffering from his sweet spot in the moon18:10
mpanettacpallares: That is hilarious18:10
flaper87cpallares: LOL18:10
*** nakul_cpani has left #openstack-zaqar18:11
flaper87why do people people prefix python packages descriptions with "A python package that ..."18:11
flaper87?18:12
flaper87I mean, it's a python package after all, why the extra worthy prefix?18:12
vkmccaptain obvious strikes again18:12
mpanettaflaper87: Put a package in pypy that isn't python, and prefix it with what it is :P18:13
*** bradjones has quit IRC18:13
flaper87mpanetta: that'd be hilarious18:13
*** bradjones has joined #openstack-zaqar18:19
*** bradjones has quit IRC18:19
*** bradjones has joined #openstack-zaqar18:19
flaper87https://twitter.com/flaper87/status/55289285770792550418:21
*** exploreshaifali has quit IRC19:10
*** flwang1 has joined #openstack-zaqar19:50
flwangflaper87: ping19:59
flaper87flwang: pong19:59
flwangflaper87: oh, man19:59
flaper87:D19:59
flwangyou have a long vacation19:59
flaper87weeeeeeeeeeeeeeeeeeeeelllllllll, tbh, I had a long silent, hidden, coding time20:00
flaper87:D20:00
flaper87flwang: how are you doing?20:00
*** JAHoagie has quit IRC20:01
flwangflaper87: good20:01
flwangi had a long (11 days) vacation20:01
flwangbut most of the time I used to play with my son :)20:01
*** JAHoagie has joined #openstack-zaqar20:03
flaper87flwang: that's good, very good! You're wiser than me20:05
flwangI had tried to code, but the little hacker don't agree20:05
flwangdpmdoesn't20:05
flwangflaper87: do you have some time to discuss the notification?20:06
flaper87flwang: yes sir20:08
flaper87lets do it now before I get pulled into other stuff20:08
flwangcool20:08
flwangdid you see the discussion between kgriffs and me20:09
flaper87ish, I read the backlog but I need to re-read it20:10
flaper87something I noticed is you were discussing about sharding the control plane20:10
flwangright20:10
flaper87but please, feel free to refresh my mind or point me to links20:10
flwanghttps://etherpad.openstack.org/p/zaqar-notification20:10
* vkmc jumps in 20:11
flwangflaper87: the key point is if we should support sharding/pool for subscriptions20:11
vkmcheeeeeeeey I want to be on the loop on this change20:11
flwangvkmc: welcome :)20:11
flaper87vkmc: roger20:14
flaper87flwang: so, as of now, I don't think we need it.20:14
flwangflaper87: okay20:14
flaper87but wait20:14
flaper87lets think out loud, I just got back from drunk land20:14
flaper87I mean, vacations20:14
flwangflaper87: I just worry about the number of subscriptions20:15
flaper87flwang: do you expect there to be a need for pooling ?20:15
flwangthat 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 subscriptions20:16
flaper87one thing to remember is that zaqar-pools != mongodb-shards20:17
flaper87you can still shard the subscriptions database/collection and not having zaqar pools for it20:17
flaper87A zaqar pool *is* a different db connection URI20:17
flwangflaper87: yep, i know20:17
flaper87ok20:18
flaper87we currently don't have pooling for the control plain, right?20:18
vkmcbut each zaqar pool is related to a queue20:18
flwangvkmc: +120:18
flwangour current pool design is tight coupling with 'queue'20:18
vkmcso in the case of having n subscriptions and needing to search in the pools to get one20:18
vkmcor delete one20:18
flwangif we don't want support pool for subscriptions, it's fine20:19
flwangif we do, the rest api of notifications will be impacted20:19
flaper87yup, that's really something we wanted, AFAICT20:19
vkmcthe complexity goes to hell20:19
flaper87I mean, pooling tight to queues20:19
flaper87although we made those considerations without thinking about subscriptions20:20
* flaper87 needs to dig into this code20:20
flaper87one thing to clarify is whether we consider subscriptions data or control20:21
flaper87Since it's a user input, I'd tend to consider it as data20:21
flaper87and therefore it should be part of the data plane20:21
flwangflaper87: yes20:21
vkmcdata++20:21
flaper87but then we have a problem because of what you just mentioned20:22
flwangmy initial thought is control, but then I put it into data20:22
flaper87we'd need to make pooling not queue oriented20:22
flwangso that's why I consider supporting 'pool' for it20:22
flwangflaper87: why not 'project' oriented?20:22
vkmcits the same reasoning that applies to queue20:23
flaper87flwang: it's way to high20:23
vkmcnow that we are moving it to the controlplane20:23
flaper87The more granular the sharding is done, the better20:23
flaper87queue pools are already way to broad and they prevent for scaling infinitedly (whatever that means)20:23
flwangflaper87: ok, make sense20:23
* flaper87 thinking20:24
flaper87(still thinking out loud)20:24
flaper87we can't make this based on queues because a subscription can be used for more than 1 queue, right ?20:24
vkmcthis problem could be eased if we keep the concept of queue20:24
flaper87(source)20:25
vkmcqueue/topic20:25
flaper87vkmc: TBH, I don't think queues are going anywhere on this cycle, not a high priority and not a big deal for now20:25
vkmchow many benefits give us removing the queue/topic entity against keeping it?20:25
flaper87besides the resource-saving benefits I believe the biggest benefit is using the right semantics20:26
vkmcok then, having the queue/topic in the URL will keep searches efficient for subscriptions, is that correct flwang?20:26
flwangflaper87: +120:26
vkmcor am I missing something?20:26
flwangvkmc: i think so, and it will keep the consistence with the other stuff, like messages, and claim20:27
flaper87vkmc: we don't have `queue` in the notification url20:27
flaper87IIRC20:27
flwangflaper87: hold on20:27
vkmcflaper87, we don't20:27
vkmcbut we could add it20:27
flwangwe don't want to to do that20:27
flaper87we don't want to add it20:27
flwangbut if we want to support pool20:27
flaper87AFAIR20:27
flwangwe have to do that20:27
flaper87:P20:27
vkmcwhy we don't want to add it?20:28
flwangpersonally, i don't like the url ' v2.0/queues/foo/subscriptions'20:29
vkmcflaper87?20:29
vkmcyeah I agree its long20:29
vkmcbut sometimes we have to sacrifice readability for usability20:30
flaper87we already have the queue in the notification body, don't we ?20:30
flaper87I'd vote for consistency20:30
flwangflaper87: yep, we have the queue when create it20:31
flwangbut if we want to get/delete/update it, we don't have the 'queue' name, and it will make troubles to support pool20:31
flaper87ah, mmh, well... URL it is, I guess20:32
flwangthat's my point20:32
flwangbut if we want to keep 'queue' in the world20:32
flwangand we don't mind using  ' v2.0/queues/foo/subscriptions'20:33
flwangthen we're good to support pool for subscriptions20:33
flaper87flwang: go ahead and propose a patch to update the spec with the gist of this convo20:34
vkmc+120:34
flaper87I'm good with it, if vkmc and kgriffs are good too, then we're all happy20:34
vkmcin the case of messages the url is 'v1.1/queues/foo/messages'20:34
vkmcso lets be verbose all the way20:34
flwangbut kgriffs's opinion is like we don't need pool for subscriptions20:34
flaper87I don't think we need it but if we're going to keep queues in the URL then we'll have it for free20:35
flwangflaper87: yep, you got it20:36
vkmcyup20:36
flwanganyway20:36
vkmckgriffs said YAGNI20:36
vkmcand I agree20:36
flwangI will submit a patch and ask for you guys review it20:36
vkmcbut in this case it doesn't hurt to add it20:36
vkmcand makes things consistent20:36
flwangvkmc: yes20:36
flwangand if we want to remove 'queue' in the future, then the subscription feature can be updated together20:37
flaper87flwang: agreed20:37
vkmcexactly20:37
flaper87thanks for the heads up20:37
vkmc+120:38
vkmcthanks flwang20:38
flwangthank you guys20:38
vkmcif you have some more time, I'd to chat about the persistent transport change20:39
vkmca few design details20:39
vkmcflaper87, flwang, kgriffs ^20:39
vkmcI'll give you cookies20:41
flwangvkmc: I'm ok after 15 minutes20:41
flwangI need to join a meeting in 2 mins20:41
vkmck20:42
*** exploreshaifali has joined #openstack-zaqar20:44
flaper87vkmc: go go go20:45
vkmcso... the first RFC is about the protocol20:46
vkmchttps://wiki.openstack.org/wiki/Zaqar/specs/Protocols/Wire_Transport20:46
vkmcwe have three fields: action, header and body20:47
* flaper87 reads carfully20:47
flaper87what's up with that?20:47
vkmcand for the Request class four fields were specified: operation == action, headers, params and content20:47
vkmcso... I remember we considered that the body should contain the params20:48
vkmcbut it feels weird20:48
flaper87mmh, wait, isn't that what the body is for ?20:48
vkmcand its harder to read/write20:48
flaper87what would go into params ?20:49
vkmcso, the question is then... what is the content field in the Request class?20:49
vkmchttps://github.com/openstack/zaqar/blob/master/zaqar/common/api/request.py#L4820:51
flaper87vkmc: that's probably a leftover from the copy/paste of the code that is in zaqarclient20:52
flaper87params are used to build the URL params in the client20:52
flaper87but I don't think they're needed in this protocol20:52
vkmcoh I see20:52
vkmcok20:52
flaper87The request content contains everything that's required by the call20:52
flaper87get_queue requires a queue name20:52
vkmcexactly yes20:52
flaper87so I expect there to be a name: queue_name in the body20:52
vkmchere are some example requests https://review.openstack.org/#/c/144803/2/zaqar/transport/websocket/example.html20:53
vkmcbody is always empty20:53
vkmc:p20:53
vkmcso I'll put params in the body and fix the Request representation20:53
flaper87ah well, what's in params is actually body20:54
flaper87:P20:54
vkmccool20:55
vkmcwill fix that20:55
vkmcsecond, we discussed about making the transport validate the content before creating the request and sending it to the api20:56
vkmcI think we should consider doing the validations in the API20:56
vkmcvalidations are tightly binded to the operation performed20:56
vkmcand that is something that is known in the API20:56
vkmcwe can add it to the transport, but we will end adding a lot of code20:57
flaper87AFAIR, the validation code belongs to the API but it's called by the transport20:57
flaper87At least, that's how I was thinking about it20:57
vkmcI see20:57
vkmcwell, in this case... maybe I'm thinking it the wrong way20:57
vkmcthe Request is created and sent to the API20:57
flaper87I think there's a validate method in the Api thing already20:57
vkmcin that moment we don't know which operation is being performed20:58
flaper87So, the transport has an API instance, right ?20:58
vkmcyup20:58
flaper87ok, in the transport, I thought we could do something like:20:58
flaper87api.validate(req)20:58
flaper87api.process(req)20:58
flaper87or just20:58
flaper87api.process(req)20:58
flaper87and let the Api call validate20:58
vkmcbut that validator doesn't validate some constrains we put in the requests20:58
flaper87does that make sense?20:58
vkmcthis is the validator you are thinking about https://github.com/openstack/zaqar/blob/master/zaqar/common/api/api.py20:59
vkmcL52 precisely20:59
flaper87right, and then there are other validations done down the path20:59
vkmcand this is the validator I'm thinking about https://github.com/openstack/zaqar/blob/master/zaqar/transport/validation.py20:59
flaper87in the API20:59
flaper87erm, I mean, in the transport20:59
flaper87yup, I'm following you there21:00
flaper87how did you imagine this would be implemented?21:00
vkmcso, if I want to use the transport validator, I need to know which operation is the user performing21:00
vkmcand that is something I know here https://review.openstack.org/#/c/141280/10/zaqar/api/v1_1/endpoints.py21:01
flaper87yup, but didn;t you add that validation there already?21:02
flaper87I swear I saw some updates to validation.py21:02
vkmcnope because its in the transport21:02
vkmcI put in the commit message as a reminder that I had to ask you guys about it21:02
flaper87I'm good with calling it from the Api21:02
vkmcif I do perform the validation there we will be mixing the layers21:02
flaper87that makes sense to me21:02
flaper87I don't think it's mixing layers, you can actually move validations.py out of transport if you want21:03
flaper87it jus have common validation code to use21:03
vkmcyep21:03
vkmcwe either access it from the api21:03
vkmcor we move it21:03
vkmcis the same21:03
vkmcif we move it we have to refactor the wsgi transport21:03
flaper87you can even move it to api and then access it from transport21:03
flaper87right21:03
flaper87lets keep it there for now21:04
vkmck21:04
flaper87that's a minor change we can do later21:04
vkmccool21:04
vkmcand finally21:04
vkmcthe ugly not-handled exceptions21:04
vkmcin here https://review.openstack.org/#/c/141280/10/zaqar/api/v1_1/endpoints.py21:05
*** openstackgerrit has quit IRC21:05
*** openstackgerrit has joined #openstack-zaqar21:06
vkmcgiven that those are there because its a cautious measurement21:06
vkmcthat is... the code should never reach that exception21:06
vkmcin wsgi we would return an HTTP error code but in here we have to do something else21:06
vkmcI was thinking we could, instead, return an common error Response21:06
vkmcinstead of making the server die21:07
vkmcthat way we don't have to rewrite a new set of exceptions that doesn't add much value21:07
vkmcand we prevent the server for dying because the user made a wrong request21:07
vkmcwhat do you guys think about it?21:08
flwangvkmc: I agree21:11
flwangis it possible to create a common base exception class for wsgi and the 'wire' protocol?21:12
vkmcflwang, 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 design21:13
vkmcso... wsgi will continue managing exceptions as it does now21:14
vkmcand for wired transports, we can either have a common base exception class21:14
vkmc(which I was trying to do)21:14
vkmcor we create a common response for error cases, as I'm thinking it would be a better approach21:14
flwangvkmc: ok, got it. does the 'common response' mean a common response class?21:17
vkmcit means instantiating this class https://github.com/openstack/zaqar/blob/master/zaqar/common/api/response.py21:17
vkmcwith the corresponding error body21:18
flwangvkmc: got21:20
flwangmake sense for me21:20
vkmc+121:21
vkmcif flaper87 and kgriffs agree21:21
vkmcI'll make it happen21:21
*** bradjones has quit IRC21:40
*** echevemaster has joined #openstack-zaqar21:42
*** bradjones has joined #openstack-zaqar21:43
*** bradjones has quit IRC21:43
*** bradjones has joined #openstack-zaqar21:43
*** echevemaster has quit IRC21:46
flwangflaper87: still around?21:55
*** sriram has quit IRC22:11
kgriffsjust 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
kgriffsvkmc: 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 IRC22:30
*** echevemaster has joined #openstack-zaqar22:30
vkmckgriffs, sounds good!23:02
*** amitgandhinz has quit IRC23:16
exploreshaifaliflaper87, around?23:27
exploreshaifalivkmc, there?23:29

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!