Thursday, 2014-10-23

*** amitgandhinz has quit IRC00:01
*** amitgandhinz has joined #openstack-zaqar00:09
*** amitgandhinz has quit IRC00:22
*** jeffrey4l has joined #openstack-zaqar00:36
wpfjeffrey4l:  morning01:08
jeffrey4lwpf, morning sir!01:08
wpfsome questions about your PS,  please check the review , -:)01:09
* jeffrey4l is checking.01:10
*** amitgandhinz has joined #openstack-zaqar01:12
jeffrey4lwpf, pls check my comments for your questions.01:21
flwangwpf: pengfei, do you know who from IBM will join the summit?01:23
wpfjeffrey4l:  xuhan, haiming , I thought01:28
wpfdo you know them?01:28
jeffrey4lwpf, u ping to wrong person..01:28
wpf-:)01:28
wpfflwang:  xuhan, haiming , I thought01:29
flwangwpf: ok, cool, thanks01:29
wpfflwang:  you also will be there ,right?01:29
flwangwpf: what's your focus now?01:29
flwangwpf: yep, hope it won't be cancelled again :D01:29
wpfstill hybrid , but not too much amazing features ..............01:30
wpf:P01:30
flwangwow01:31
*** bradjones has quit IRC01:50
*** bradjones has joined #openstack-zaqar01:50
openstackgerritJeffrey Zhang proposed a change to openstack/zaqar: Always include the project id in the logs  https://review.openstack.org/13013902:05
*** amitgandhinz has quit IRC03:06
*** exploreshaifali has joined #openstack-zaqar03:45
*** exploreshaifali has quit IRC04:23
*** flwang1 has quit IRC04:26
*** gmann has joined #openstack-zaqar04:33
gmannflaper87: hi04:35
gmannflaper87, flwang: 1 quick question - is delete queue operation is sync or async?04:42
gmannflaper87, flwang : Actually I was having a look on tempest tests where it is tested as sync.04:43
*** flwang1 has joined #openstack-zaqar05:06
*** sgotliv has joined #openstack-zaqar05:08
jeffrey4lgmann, it is sync. Why u have such a question?05:28
*** exploreshaifali has joined #openstack-zaqar05:33
gmannjeffrey4l: thx, actually tempest tests that operation as sync, so i wanted to confirm the same.05:33
jeffrey4lgot it05:34
*** flwang1 has quit IRC05:47
*** yfujioka has joined #openstack-zaqar05:57
*** openstack has joined #openstack-zaqar06:12
*** exploreshaifali has quit IRC06:15
*** prashanthr_ has joined #openstack-zaqar06:15
*** jeffrey4l has quit IRC06:40
*** openstack has quit IRC06:59
*** openstack has joined #openstack-zaqar14:18
*** openstackstatus has joined #openstack-zaqar14:19
*** ChanServ sets mode: +v openstackstatus14:19
*** mpanetta_ is now known as mpanetta14:19
flaper87vkmc: right, but as it is, it just has support for v1.0 and not v1.1 (I'm talking about the case where just 1 message is posted)14:43
flaper87vkmc: does that make sense?14:44
flaper87vkmc: for example: queue.post(dict(field1='test'))14:44
flaper87That fails for v1.114:45
flaper87because it won't wrap it in {'messages': [dict(field1='test')]}14:45
vkmcyeah, but that is on the client14:45
vkmcwe assume that if there is no 'messages' in the dict then we are talking about v114:46
vkmcI could check the client version and stop assuming14:46
vkmcand... it works for v1.1, when just 1 message is posted :)14:47
flaper87mmh, does it?14:47
flaper87I14:48
flaper87I must be missing something then14:48
flaper87let me check that again14:48
vkmcI added the tests14:48
vkmcmaybe I'm the one missing something!14:48
vkmccorrect me if I'm wrong14:48
*** amitgandhinz has joined #openstack-zaqar14:50
flaper87vkmc:  messages = {'messages': [{'ttl': 30, 'body': 'Post one!'}, ]} <- this is cheating14:52
flaper87:P14:52
flaper87The idea is to call post like this:14:53
flaper87queue.post(dict(ttl=..,body=""))14:53
flaper87or14:53
vkmcAH14:53
flaper87queue.post(dict(ttl=..,body=""), dict(...))14:53
vkmcbut we are doing it like that in the API14:55
vkmccheck L264 here https://review.openstack.org/#/c/108795/1/marconi/tests/queues/transport/wsgi/v1_1/test_messages.py14:55
flaper87vkmc: yup, but that's the server test. I mean, the API requires it to be wrapped but in the library, in order to have a simpler API, we just require the message to be passed to the post call14:57
flaper87at least in the higher-level API - the Queue instance, that is.14:57
vkmcmakes sense14:57
vkmcok, I'll fix it14:57
flaper87vkmc: ahem... cheater... ahem14:58
vkmcflaper87, its kgriffs fault14:58
flaper87vkmc: damn, I KNEW it was kgriffs|afk again!14:58
vkmcahá14:59
vkmcoh and, btw, you cannot call post like you mentioned15:02
vkmcfor several messages15:02
vkmcqueue.post([dict(ttl=..,body=""), dict(...)])15:03
flaper87it's without the list15:03
flaper87queue.post(*[dict(ttl=..,body=""), dict(...)])15:03
*** cpallares has joined #openstack-zaqar15:03
flaper87each message is a positional argument15:03
vkmccool15:04
*** openstackgerrit has quit IRC15:07
flaper87vkmc: can you review these doc patches? https://review.openstack.org/#/q/status:open+project:openstack/python-zaqarclient+branch:master+topic:docs,n,z15:09
vkmcflaper87, sure15:11
*** kgriffs|afk is now known as kgriffs15:20
kgriffsflaper87: it's not my fault. that was my evil twin.15:21
kgriffsflaper87, riveter: around?15:25
vkmcflaper87, https://review.openstack.org/#/c/129988/2 :D15:31
vkmcflaper87, just a nit here https://review.openstack.org/#/c/127182/516:00
*** openstack has joined #openstack-zaqar16:02
* flaper87 back16:03
flaper87kgriffs: I'm here16:04
flaper87:D16:04
kgriffso/16:04
kgriffsI was just wanting to through out some ideas re that patch16:04
kgriffsthrow16:05
flaper87sure thing16:05
* kgriffs wonders why he keeps swapping homophones lately16:06
kgriffsok, for reference: https://review.openstack.org/#/c/129109/16:06
flaper87vkmc: addressed all your comments16:07
flaper87vkmc: thanks :)16:07
flaper87kgriffs: shoot16:08
kgriffsI've been thinking about this and do agree after all that the approach is fairly ugly. We are running into some limitations of the Python language here.16:08
kgriffsso, I have a couple alternative proposals, let me know what you think16:08
kgriffsoption A: Revert to the previous code.16:09
flaper87(as in, don't merge that patch?)16:09
kgriffsright16:09
flaper87ok16:09
flaper87next ?16:09
* flaper87 is curious16:10
* flaper87 likes kgriffs ideas16:10
flaper87well, ....16:10
flaper87:D16:10
kgriffsoption B: same as above, but do remove __getattr__ and clean things up so we just implement the contract from the base class and don't forward anything else16:10
kgriffs(IMO the current design is confusing and inconsistent, and also does more than it should by forwarding EVERYTHING, not just the public interface contract)16:11
kgriffsone more16:11
kgriffsoption C: same as above, but also use macropy to DRY up the code (let me paste a gist example)16:11
* flaper87 doesn't know macropy16:12
kgriffshttps://gist.github.com/anonymous/71ba60f941446b6ae15416:12
kgriffsthat proxy decorator is actually a macro that is able to mess with the AST when the module is imported, before the code is compiled16:12
* flaper87 votes for B16:13
flaper87:P16:13
kgriffsbut yeah, that would mean having to get macropy in global-requirements and who knows if the gods will approve16:13
flaper87LOOOOOOOOOL16:13
flaper87yeah, the other thing is that reading: https://gist.github.com/anonymous/71ba60f941446b6ae154#file-gistfile1-py-L2-L416:14
kgriffs(yet another reason why global-requirements is a BAD IDEA)16:14
flaper87is not actually intuitive and people would have to learn about macropy and stuff16:14
kgriffstrue16:14
kgriffsyou could mitigate that a little16:14
kgriffslike say @macros.proxy16:14
kgriffsbut yeah, still a bit of a learning curve16:14
flaper87yeah, in this specific case, I don't really mind the extra code there16:15
kgriffsok, if you like option B then that is a precursor to C anyway if we ever decide to try it16:15
flaper87awesome16:15
flaper87that sounds good, we can have a proof patch for C after B lands16:15
kgriffsriveter: ^^^16:15
flaper87riveter: btw, thanks a lot for working on that and sorry for the confusion :)16:16
*** sgotliv has quit IRC16:37
*** exploreshaifali has joined #openstack-zaqar16:37
*** sgotliv has joined #openstack-zaqar16:43
*** kgriffs is now known as kgriffs|afk16:44
*** openstackgerrit has joined #openstack-zaqar16:49
*** sgotliv has quit IRC16:50
*** amitgandhinz has quit IRC16:51
*** amitgandhinz has joined #openstack-zaqar17:02
*** reed has quit IRC17:15
*** openstackgerrit has quit IRC17:48
*** openstackgerrit has joined #openstack-zaqar17:49
*** reed has joined #openstack-zaqar17:54
*** jchai is now known as jchai_afk18:09
*** AAzza has left #openstack-zaqar18:15
*** exploreshaifali has quit IRC18:44
*** cpallares has quit IRC18:54
*** flwang1 has joined #openstack-zaqar19:00
*** jchai_afk is now known as jchai19:07
*** flwang1 has quit IRC19:25
*** AAzza_afk has joined #openstack-zaqar19:32
*** AAzza_afk is now known as AAzza19:33
*** exploreshaifali has joined #openstack-zaqar19:36
*** kgriffs|afk is now known as kgriffs19:42
* vkmc lurks19:48
* flaper87 lurks19:49
vkmcmpanetta, ?19:50
vkmckgriffs, ?19:50
kgriffsyo yo19:51
vkmcy u no lurk?19:51
mpanettaHmm?19:51
* mpanetta lurks harder19:51
* flaper87 lurks mpanetta lurk while kgriffs and vkmc lurk19:51
vkmclol19:52
mpanettalurky lurky lurky19:52
* flaper87 wonders where's his F*$#$^%(#$*%^#$ ligther19:52
mpanettaLoose somethin flaper87?19:52
vkmcpipe time flaper87?19:53
flaper87vkmc: thaaat's right, girl!19:53
flaper87but I can't find my lighter, I must have lost it19:53
flaper87damnit19:53
flaper87well, I sure know how to make fire without a ligther19:54
vkmcuse a match...?19:54
vkmcor maybe your good old firetorch?19:54
flaper87vkmc: firetorch it is19:55
vkmcs/firetorch/flamethrower19:55
flaper87I ran out of matches because I have (had?) a lighter19:55
flaper87no no, firetorch this time19:55
flaper87the flamethrower may ruin my pipe19:55
vkmcgood, keeping things simply19:55
vkmchaha19:55
vkmcs/simply/simple19:56
mpanettaEep ruined pipes no good.19:57
*** exploreshaifali has quit IRC20:02
* flaper87 thinks: "Now we are talking"20:02
*** AAzza has left #openstack-zaqar20:03
* kgriffs lurks20:05
*** malini has quit IRC20:06
* flaper87 smokes20:09
*** flwang1 has joined #openstack-zaqar20:26
openstackgerritFlavio Percoco proposed a change to openstack/python-zaqarclient: Setup developer docs for zaqarclient  https://review.openstack.org/12717120:27
openstackgerritFlavio Percoco proposed a change to openstack/python-zaqarclient: Extend some docstrings with useful information  https://review.openstack.org/12722720:27
openstackgerritFlavio Percoco proposed a change to openstack/python-zaqarclient: Add docs for `Client` instances  https://review.openstack.org/12718220:27
openstackgerritFlavio Percoco proposed a change to openstack/python-zaqarclient: Add reference docs for latest recommended client  https://review.openstack.org/12721520:27
flaper87vkmc: ^ fixed the missing s20:28
* flaper87 hates typos20:28
vkmcthanks fla20:28
flaper87vkmc: thank, YOU!20:29
flaper87OMFG, the summit is almost 1 week way20:29
vkmclets got those sweet docs merged20:29
* flaper87 can't wait20:29
vkmcoh yeeeeeeeeeeeeeeees20:30
mpanettaY'all suck :P20:30
* mpanetta wants to go to france20:30
flaper87mpanetta: I was always talking about the week of really really hard work20:30
* flaper87 acts inocent20:30
vkmcbooo mpanetta, I thought you were coming too20:30
vkmcwho is going to lurk?20:30
vkmc:(20:31
mpanettaNot this time :(20:31
mpanettaflaper87: Which week? :P20:31
flaper87LOL20:34
* flaper87 always regrets the week-party when it ends20:35
flaper87I mean, the summit20:35
vkmcI couldn't attend Icehouse and Juno20:39
vkmcI've been waiting for Kilo :o I'll be too sad when it ends20:40
flwangflaper87: do you have another meeting to discuss the summit topics? or it's done already?20:42
vkmcwe haven't meet yet, right? we should do that20:43
flaper87flwang: vkmc we haven't had it, it's all my fault20:44
flaper87we can have it now if you guys can20:44
flaper87I'm available now20:44
flaper87vkmc: flwang kgriffs ?20:44
flaper87it shouldn't take long20:44
vkmcI can do that20:44
kgriffso/20:44
vkmcmalini|afk?20:44
kgriffs\o\20:44
kgriffs /o/20:44
kgriffs\o/20:44
flaper87kgriffs: are you skiing ?20:44
flaper87:P20:44
kgriffslistening to music20:45
flaper87oh ok ok :D20:45
flaper87flwang: kgriffs vkmc https://etherpad.openstack.org/p/kilo-zaqar-summit-topics20:45
flaper87Lets focus on the design sessions, we;ll organize the pod discussions later20:45
kgriffsok. which ones are we doing design sessions for?20:45
flaper87kgriffs: that we need to discuss now20:46
flaper87:P20:46
kgriffslol20:46
flaper87The first session listed there is v220:46
flaper87I'm a bit torn there since v2 is becoming more and more important but we still don't have any other feedback from the community20:46
flaper87.. on v120:46
flaper87Still, I think it'd be worth digging in what we think is wrong on v1.120:47
flaper87and what major changes we see for v220:47
flaper87regardless of whether it'll happen in Kilo or L20:47
kgriffsv2 is a tricky topic20:47
flaper87kgriffs: right, I think I would rather talk about FIFO than v2 as a whole20:48
kgriffsbecause it pulls in the discussions around message listing vs. simple SQS job queueing style semantics, AMQP, etc.20:48
kgriffsFIFO20:48
kgriffsetc.20:48
flaper87but talking about changing our FIFO story means we're considering v220:48
kgriffsjust take all the controversial things, put them in a bucket, and bring them to that session20:48
kgriffs:p20:48
flaper87kgriffs: can we pick them out of a bowl randomly?20:49
flaper87:P20:49
flaper87that makes it more interesting20:49
flaper87ok, v2 it is20:49
flaper87agreed?20:49
vkmclol20:49
flaper87kgriffs: we are suppose to be the drivers. Do you want to lead it? Otherwise, I'll do it20:50
kgriffsyeah, we should at least sit down and talk about all this stuff and find out what, if anything, in v1.x is preventing people from using the service.20:50
vkmcagree that v2 should be ther first discussion20:50
flwangwhat's the big move for v2?20:50
flwangmaybe I missed something20:51
flaper87flwang: there are quite few things: FIFO, get-message-by-id, listing semantics20:51
flaper87etc20:51
vkmcwe are removing the get messages by id thing20:51
vkmcand yeah ^20:51
flaper87ok, that's a go. We can choose who's going to lead it based on who has more time to work on it on the flight there20:52
kgriffsFIFO is interesting because people often don't realize that once you do listing semantics that is stateless (meaning clients track their own state), you kinda end up having to do FIFO anyway, but I digress. Lots of stuff we could talk about in that session.20:52
kgriffsflaper87: lol20:52
flaper87oh look, I'm in Europe and kgriffs is in the US20:52
flaper87TOOOO BAD!20:52
flaper87:D20:52
kgriffsWAH?!20:52
vkmchaha20:53
vkmckgriffs will have jetlag20:53
flaper87pffffff20:53
flaper87there's no such thing as jetlag20:53
flaper87:P20:53
vkmctravelling to the future is hard for people20:53
flaper87vkmc: he could travel to the past and still get here :P20:54
flaper87it'll be harder20:54
flaper87but well20:54
flaper87ok ok20:54
flaper87lets move on20:54
flaper87Persistent Transports20:54
flaper87vkmc: that's yours20:54
flaper87I'm very interested in it20:54
flaper87vkmc: also, cpallares proposed to discuss the cross-api layer too20:54
vkmcyeah well, currently we have support for wsgi20:55
flaper87which I don't think we need for the wsgi transport but I do think we'll need for persisten transports20:55
vkmcit would be cool to add support for another transport too20:55
flaper87vkmc: you and cpallares could work on something together there20:55
flaper87or we could discuss the cross-api thing in a POD session20:55
vkmcthat's great20:55
kgriffsthe first thing to talk about in that discussion is requirements/use cases20:56
flaper87just to avoid confussion, the cross-api thing is an implementation of a wire-like protocol20:56
vkmcI could ping cpallares and try to do something together20:56
vkmckgriffs, +120:56
kgriffswhat kind of transport we choose to do will vary widely based on our end goal - the kinds of apps we have in mind20:56
flaper87kgriffs: right, although I think we've a couple of strong ones20:56
flaper87Horizon+websockets, for example20:56
kgriffsyeah, I was just going to say we should try to align it with a project we know already wants to use Zaqar20:57
kgriffsone other consideration is do we do the entire API or just a subset20:57
flaper87I think among the ones listed there, websocket is the one we should play with to begin with20:57
flaper87but we'll figure that out there20:57
kgriffsor, start with a subset with the goal of getting the rest done (iterate for much win)20:57
kgriffsok. let's make sure to capture all this in the agenda20:57
vkmcI made this list https://gist.github.com/vkmc/f69337561466c4cf4f0520:58
flaper87Lets just make sure we don't waste too much time in the introduction to those protocols so that there'll be time to discuss the implementation as well20:58
vkmcI haven't updated yet with the pros/cons of using a persistent approach20:58
vkmc(sorry flaper87, no time >.>, will do this weekend)20:58
kgriffsI would like to propose that all discussions (formal sessions as well as pod discussions) have an etherpad prepared beforehand20:58
flaper87vkmc: no rush, I mean, the summit is right there but  don't worry, really. We'll have breakfast during your session20:58
flaper87:P20:58
flaper87kgriffs: yup, I'm working on that20:59
vkmcflaper87, breakfast sounds good20:59
flaper87we had them for the ATL summit20:59
kgriffsflaper87: how many time slots do we have?20:59
flwangflaper87: btw, we won't discuss the notification topic this time, we will just do it in Kilo, right?20:59
flwangkgriffs: 4?20:59
flaper87The other thing is that I'd like us to finilize sessions with a good plan forward for that topic so we get things done21:00
flaper87the idea for sessions is to discuss things we have already agreed on doing21:00
kgriffsflaper87: lol, yes let's just take the time to start coding. :D21:00
flaper87flwang: kilo, yeah!21:00
flaper87kgriffs: we have 4 slots21:00
kgriffskk21:00
flwangkgriffs: will you be there?21:00
kgriffsyes21:01
flwangawesome21:01
flaper87Integration with other services21:01
flaper87I pingged Zane and asked him if he was interested in participating21:01
flaper87as a Heat representative21:01
flaper87he said, YES!21:01
* flaper87 so happy21:01
flaper87:P21:01
flaper87that was a formal proposal21:01
flaper87We probably need someone from horizon too but I'm kinda leaning towards focusing on 1 service at a time21:02
flaper87so far, Heat has shown most interest in Zaqar than other projects21:02
kgriffsi think having 2 would help keep us honest21:02
kgriffsprevent us from becoming too myopic21:02
kgriffsbut no more than 221:02
vkmc+1 kgriffs21:02
flaper87right, but we need to prepare the material for the second one21:03
kgriffsotherwise we don't get anything done. :p21:03
flaper87we never do but lets keep that between us21:03
flaper87:P21:03
kgriffshow about inviting horizon to the transport session?21:03
flaper87mmh, I think it's too Zaqar specific21:03
kgriffsok21:03
vkmcyeah21:03
vkmcwe should have a intergration slot21:04
flaper87kgriffs: want to lead this session?21:04
flaper87I can take v221:04
kgriffsso I do think having an integration session is a good use of a time slot21:04
vkmcand there have horizon and heat21:04
kgriffsflaper87: ok21:04
flaper87SOLD!21:04
kgriffsdo you have an etherpad template you want to use?21:04
* flaper87 writes that down before this dude changes his mind21:04
flwangLOL21:04
kgriffsor should I just slap up some ASCII art and call it a day. ;)21:04
flaper87No template yet, I'll create the pads and link them in this: https://etherpad.openstack.org/p/kilo-zaqar-summit-topics21:04
flaper87I'll have that done tomorrow21:05
flaper87so you all can start preparing your stuff21:05
kgriffsok. I made some pads for some of the sessions I proposed but they are just rough drafts and I can port the content over.21:05
flaper87We have FIFO listed there but we can discuss it in the v2 session21:05
flaper87and have a more detailed POD session on FIFO if needed21:05
flaper87kgriffs: kk21:05
kgriffsagreed21:05
flaper87Docs21:06
flaper87Do we need a full session or can we do a 1h hackathon ?21:06
vkmchackaton sounds good21:06
flaper87cool21:06
vkmcdocs are mostly covered21:06
vkmcwe are missing HA21:06
flaper87Performance testing21:06
flaper87vkmc: GTK, we should work on an etherpad to list things that are missing21:07
vkmcflaper87, nice21:07
flaper87kgriffs: did you propose the performance session?21:07
flaper87Anything specific you wanted to discuss?21:07
kgriffsyeah, I think until we have more usage of the service, we won't have any super users show up to a formal design session anyway to discuss docs21:07
kgriffsso, pod time is kewl with me on that docs one21:08
kgriffsflaper87: yes21:08
kgriffsthat one I thought would be good to do with some rally peeps21:08
flwangkgriffs: +1 re doc topic21:08
vkmcsounds good21:08
flaper87kgriffs: ok, can that one be merged with some other infrastructure specific topics ?21:08
flaper87Missing gates ?21:08
flaper87Missing tests ?21:08
kgriffssure21:08
flwangflaper87: I think it's not a 'missing'21:09
kgriffswe can do one big happy infra session21:09
flwangit most like an enhancement :)21:09
flaper87+1 for the infra session21:09
flaper87flwang: yeah yeah, that's what EVERYONE says21:09
flaper87:P21:09
flwangsome small sessions can share the same slot21:09
kgriffsflaper87: if you could seed the pad with all the topics you'd like covered, that would be cool21:09
flaper87ok, lets convert that into an infra session21:09
flaper87kgriffs: will do21:09
* flaper87 writes that task down21:09
flwangkgriffs: is there any session from RAX about operations?21:10
flaper87ok, we just filled our 4 slots21:11
kgriffsi think there was a talk submission but it wasn't accepted21:11
kgriffsapparently we didn't bribe the right people. ;)21:11
kgriffsflwang: I would be happy to discuss with you and answer questions at the summit.21:11
flwangkgriffs: it would be awesome21:12
kgriffsflwang: kk21:12
kgriffssounds like a plan!21:12
flwangwe(Catalyst IT) is going to adopt zaqar in production21:12
kgriffsflaper87: ok, we can do the redis and notifications at the pod21:12
kgriffsflwang: wow, cool!21:12
flwangso there are a lot of questions about the operations21:12
flwanggiven the code is there and cool :D21:13
kgriffsflwang: maybe we should have a pod discussion around zaqar ops?21:13
kgriffsdiscuss the needs you have, share lessons learned, etc.21:14
flwangit would be cool21:14
kgriffsflaper87: ^^^ ?21:14
kgriffslooks like there is a topic on the pad21:15
kgriffs"Rock-solid operability"21:15
flwangI know the user of AWS are using SQS heavily, so I'm really keen to know what's the status of Zaqar in Rax world21:16
flwangand recently I just opened an account of Rax cloud to experience the queue service21:17
flwangthe GUI is so simple ;)21:17
kgriffsheh, yeah21:17
flwangkgriffs: btw, seems I can't post messages for a queue on GUI, is it?21:19
kgriffsflwang: no, I don't think you can. we can discuss more after this meeting.21:19
flwangkgriffs: okay21:19
openstackgerritA change was merged to openstack/python-zaqarclient: Setup developer docs for zaqarclient  https://review.openstack.org/12717121:19
flwangwhere is our PTL?21:20
* flaper87 is back21:22
flaper87POD discussion for ops sounds good to me21:22
openstackgerritA change was merged to openstack/python-zaqarclient: Add docs for `Client` instances  https://review.openstack.org/12718221:23
kgriffsflaper87: how are we scheduling the Pod sessions?21:23
flaper87kgriffs: we aren't21:24
flaper87:P21:24
kgriffsheh21:24
flaper87jokes apart, I'll start working on that tomorrow21:24
flaper87because we need to make sure folks have time to go to other sessions21:24
kgriffsI was just thinking last summit it was kinda hard to get everyone together via text messages and such.21:24
flaper87Assuming there's internet access, we can use G+21:24
flaper87to send messages21:25
vkmccheck the app21:25
vkmcthere is a messaging system there21:25
vkmcI haven't tried it yet though21:25
kgriffsoh boy21:25
flaper87that app never works21:25
flaper87T_T21:25
flwangflaper87: I suggest use wechat :)21:25
* kgriffs gets ready to post a XSS attack21:26
flwangthen we can create a group to talk in real time :)21:26
kgriffsthat would be cool21:26
flwangplease search wechat in your app store21:26
* vkmc looks for wechat21:26
flwangand create an account, then we can create a lovely group, why not have a try?21:26
vkmcwow, it needs access for everything21:27
flaper87flwang: is there really a wechat app ?21:27
flwangI'm seriously :D21:27
* kgriffs downloading21:28
kgriffsthis would be great21:28
flaper87what about simple telegram/whatsapp ?21:28
kgriffswe can use it to organize discussions, dinner groups, etc.21:28
kgriffshazing of flaper8721:28
kgriffsyou know, the usual stuff21:28
flaper87LOOOOOOOOOOOOOOOL21:28
vkmcwhatsapp sounds good too21:28
flaper87I'm sure you all have whatsapp21:29
flwangflaper87: I'm OK :D21:29
flwangbut the truth is I don't have whatsapp :)21:29
flwangdoes it support group?21:29
flaper87flwang: LIAAAAAAAAAAAAAR21:29
flaper87flwang: it does21:29
flwangcool21:30
flaper87flwang: don't act as if you don't know21:30
flaper87I'm sure you wast half of your day there21:30
flwangthe bad thing is I forgot to take my phone today, damn it21:31
kgriffsdoes whatsapp let you use "fun animated stickers"?21:31
kgriffscause that is a deal breaker for me. ;)21:32
kgriffsooh, cool. "Friend Radar". wechat actually looks pretty slick. anyway, whatever you all want to use, I'm cool with.21:32
flwangkgriffs: yes21:33
flwangit has the Radar21:33
flwangin the same area, if there are some other guys open the Radar, you can find him/her21:33
flwangit's super cool when you in a party instead of adding them one by one :)21:34
flwangi mean with their id21:34
vkmckgriffs, do you have whatsapp?21:34
vkmcflaper87 already created a group haha21:34
*** sriram has quit IRC21:34
flaper87kgriffs: flwang your mobile numbers, private message, now!21:35
flwangi'm wechat id is OpenStacker, please add me if you're using it :D21:35
flwangs/i'm/my/21:35
flwangmy NZ mobile number is +64 021 0832 634821:35
flwangkgriffs: please tell me your wechat id if you have installed and have any fun21:36
*** amitgandhinz has quit IRC21:39
kgriffsI just set my wechat id to "kgriffs"21:40
flwangkgriffs: awesome, I will catch you later21:41
* flaper87 confused21:41
* flaper87 thought we were using whatsapp21:41
flwangflaper87: haha21:41
flwangwe could21:41
flwangbut that doesn't impact kgriffs and I have some secret :D21:41
kgriffslol21:43
kgriffswhat are we using again?21:43
* kgriffs downloads ALL THE THINGS!21:43
vkmcICQ21:43
kgriffsAOL21:43
flaper87ok, flwang you are the only one missing in our whatsapp group21:44
* flaper87 is using ZAQARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR21:44
flaper87you should all be ashamed21:44
vkmcok.. lets use zaqar21:45
vkmcis too sexy to use21:46
* flwang is really shamed without a phone now :)21:46
flwangI really hope to have a whatsapp ubuntu version :)21:47
flaper87kk, I'm off guys! ttyt21:48
vkmcflaper87, ttfn, enjoy the rest of your evening!21:48
kgriffslet's just sell Zaqar to Facebook and retire young.21:56
kgriffsoh wait, open source.21:57
kgriffsoooooops21:57
*** mpanetta has quit IRC22:02
vkmckgriffs, if you have a moment later, could you help me brainstorm some other use cases for persistent transport?22:03
vkmcor somebody else :)22:05
*** flwang has quit IRC22:05
kgriffsvkmc: sure, is now good?22:06
kgriffsI can stick around for 5-10 more minutes22:06
kgriffsotherwise, you can ping me tomorrow22:06
vkmcits good now yeah!22:06
*** flwang has joined #openstack-zaqar22:06
vkmcas flaper87 mentioned, one of the cases is for Horizon22:07
vkmcwith websockets22:07
vkmcI checked the use case list for other projects but I'm not sure if a persistent connection would make any difference22:08
*** sgotliv has joined #openstack-zaqar22:08
kgriffshonestly, I don't think there would be much different between websockets and long polling22:08
vkmchttps://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases22:08
kgriffsweb sockets are good for things that are *actually* realtime such as streaming and shared whiteboards22:08
kgriffsthere is one exception there22:09
kgriffsif you are pushing a TON of events and the backend data store can keep up, then a persistent connection may help22:09
kgriffsbut really, with websockets you are probably talking a private cloud deployment since scaling persistent connections is a PITA (and gets expensive fast)22:10
kgriffsthat social media company22:11
kgriffsI think it is mentioned here22:11
kgriffshttps://etherpad.openstack.org/p/zaqar-overcloud-use-cases22:11
kgriffsthey wanted websockets (specifically, socket.io)22:11
vkmcaha.. makes sense22:11
kgriffsbut after we chatted they admitted that realistically, you can get what you need most of the time with keep-alive; other things are more likely to be a bottleneck.22:12
kgriffsthat being said, there is something about the "wow!" factor if you can do web sockets22:12
kgriffsIt makes a great demo22:13
vkmcyeah that's true22:13
vkmcso probably its not about what we can do with it22:13
vkmcbut if we can stick with the trend22:13
vkmceveryone is leaning towards websockets nowadays22:13
kgriffsI'm not saying we shouldn't do it, but just that we need to understand what the goals are.22:14
vkmcyeah, that is what I want to understand too22:14
vkmcbecause 'persistent connection' sounds great22:14
vkmcbut, why do we want that?22:14
vkmchow is Zaqar going to be improved with that?22:14
kgriffsright22:14
*** jchai has quit IRC22:14
kgriffsHTTP 2.0 will put a lot of this debate to rest22:15
kgriffsbut in the meantime, it may be worth doing websocket.22:15
vkmcok..22:16
kgriffsit will make latency a little better, and also everyone can get excited about it22:16
kgriffssorry, don't mean to sound cynical22:16
kgriffsi mean, it is a great selling point22:16
kgriffsno doubt22:16
vkmchaha not at all! its useful criticism22:16
vkmcso we know what to expect22:17
kgriffsnow, if you are hosting using pypy and the redis driver, you might notice a bigger difference in throughput or whatever by using a persistent transport22:17
kgriffsin any case, I think the two use cases are:22:18
kgriffscontrol surfaces (have to communicate over the internetz but are concerned about latency for whatever reason)22:18
kgriffsand22:18
kgriffshigh-throughput use cases where they need a multi-tenant, authenticated solution so something like Kafka doesn't work22:19
kgriffsanyway, that's my $0.0222:19
kgriffsI'm sure teh Flavio well have more things to add22:20
kgriffsfinal thought22:20
vkmcI'll ping him tomorrow22:20
vkmcI also mentioned other alternatives, like WAMP and AMQP22:20
kgriffsif we go this way, we should think about whether straight websockets is ok or if we need something that can fallback to other things ala socket.io22:20
vkmcexactly yes22:20
kgriffsah, yeah. WAMP is definitely interesting.22:21
vkmcit has a lot ot things we won't use IMO22:21
kgriffsyeah22:22
kgriffshttp://wamp.ws/compared/22:22
vkmcyeah22:22
kgriffsSTOMP is another one we should consider.22:22
kgriffsyou can pretty much do anything you want over websocket22:22
kgriffsI think we should optimize for22:22
vkmcisn't STOMP only text? that might be a bit constraining22:23
kgriffsso is HTTP22:23
kgriffs;)22:23
vkmctrue dat22:24
kgriffsI just bring it up because it is generic enough and alike enough to HTTP that it may be the simplest thing to map to our API22:24
vkmcyeah22:24
kgriffsactually, I guess HTTP isn't strictly "text"...22:24
kgriffshmmm22:24
* kgriffs looks at the STOMP spec22:24
kgriffs"Otherwise, the receiver SHOULD consider the body to be a binary blob."22:26
vkmcah well22:26
kgriffsanyway22:26
vkmcI also looked into crossbar.io http://crossbar.io/howitworks/22:26
kgriffsgetting off into the weeds22:26
vkmcis an implementation of WAMP22:26
kgriffsoic22:26
vkmcbut I heard really good comments22:26
kgriffshmm22:27
kgriffsyou know, to be honest, I wonder if going down this path is just going to confuse the mission of zaqar again22:28
kgriffsif you want WAMP, why wouldn't you just use crossbar.io?22:28
vkmcyeah22:28
vkmcwe have to be careful with this22:29
kgriffswe could say "we offer a multi-tenant and auth layer on top of all those things"22:29
kgriffsbut I don't think that is every going to work. the backends are too different22:29
vkmcI'm mostly convinced that we should go with websockets or raw tcp22:29
vkmcbecause those are more generic and one might expect that Zaqar clients use those transports22:30
vkmcidk honestly, its a tough call22:31
kgriffsyeah, can you make a note about that session that we should be really clear on zaqar's mission and make sure the transport choice aligns with that?22:33
vkmcyeah22:34
vkmcof course22:34
vkmcthat should be our north22:34
kgriffsI'm thinking we will have evaluation criteria like22:34
kgriffs1. does it fit in our mission of multi-tenant, HA, scalable, durable messaging?22:34
kgriffs2. how hard will it be to map the semantics to our API?22:35
kgriffs3. How much client library support is out there?22:35
kgriffs4. Will it make a super awesome demo at meetups (srsly. buzz FTW!)22:36
kgriffsanyway, you get the idea.22:36
kgriffs</soapbox>22:36
vkmc5. which should be the example use cases?22:36
vkmcI do22:36
kgriffskewl22:36
vkmcthanks kgriffs, its always useful your insight22:37
kgriffsheh, well I'm sometimes a little too opinionated I'm afraid. :p22:37
vkmcnah, you are fine :)22:38
kgriffs:)22:42
*** amitgandhinz has joined #openstack-zaqar22:49
riveterkgriffs, got a minute?22:53
kgriffssure22:54
*** amitgandhinz has quit IRC22:54
riveterso the idea now is to remove __getattr__ and just put any methods that are identical between the 3 metaclasses into RoutingController22:54
riveter?22:54
riveter*metacontrollers, sorry22:56
kgriffsfor the most part. let me clarify my proposal and we can see if it makes sense. :p22:58
rivetershoot22:58
kgriffsso, given that I think we are all starting to think it is pretty hacky to try and DRY this up without using something sneaky like macropy22:59
riveternot familiar with macropy23:00
kgriffslet's just embrace what Python does instead of trying to be so clever. By which I mean, let's not even try to do this __getattr__ thing because it actually doesn't give us a lot of value IMO.23:01
openstackgerritA change was merged to openstack/python-zaqarclient: Add reference docs for latest recommended client  https://review.openstack.org/12721523:01
riveteryeah23:01
kgriffs(since the calling conventions and responses when lookups fail vary so widely)23:01
kgriffsalso, it actually does more than we want23:01
kgriffswe only want to implement the base class interface, but we end up actually forwarding everything under the sun23:01
kgriffsso, here is what I was thinking to do instead23:02
kgriffsif you look in zaqar/queues/storage/base.py23:02
kgriffsthe interfaces for each controller that we want to forward are defined23:03
riveteryeah23:03
riveterI looked at this but decided not to mess with it23:03
kgriffsso, just inherit from those base classes like the real drivers do23:04
rivetermm, looks like most of the base class methods right now are not implemented23:05
riveteryou mean to move the implementations there?23:05
kgriffsbut the bodies will just be "do a lookup, call the target's same method. If no lookup, return a default answer or raise an error"23:05
openstackgerritA change was merged to openstack/python-zaqarclient: Extend some docstrings with useful information  https://review.openstack.org/12722723:05
kgriffshmmm23:06
rivetersorry, not sure I follow23:06
kgriffslet me look23:06
riveterthat's what the metacontrollers are already doing23:06
kgriffsi guess that is my point23:07
kgriffswhat is the point of keeping __getattr__ around?23:07
riveteryeah, I'm not arguing with that23:07
riveterI'm just not sure what you're suggesting to put in the base classes23:07
kgriffsoh, in base.py you would not change anything23:07
kgriffsin pooling.py23:08
riveterso how does inheriting from them help?23:08
kgriffsyou would change MessageController to inherit from zaqar.queues.storage.Message (as do the redis, mongo, and sqla drivers)23:09
kgriffsriveter: let me try to answer that23:10
kgriffsalthough Python's inheritance doesn't enforce implementation of the interface as strictly as say C++ or Java, it does make sure you don't forget to add a method in the child classes when the parent changes23:11
kgriffsit also serves as a reminder when reading the code what the contract is23:11
rivetermm, ok23:11
riveterso we're not looking at removing the duplicated code at all23:11
kgriffsI suspect that some of the method signatures have gotten out of sync with the base class interface as well, in subtle ways.23:11
riveteryeah, I noticed a few cases of that23:12
kgriffsinheriting won't catch that, but as part of this patch we should make sure the args and kwargs are in sync23:12
kgriffsso, basically23:12
riveterspent some time looking for a subtle reason, then decided maybe there wasn't one :)23:12
kgriffs1. remove __getattr__23:12
riveter2. make pooling controllers inherit from base classes23:13
kgriffsright23:13
riveter3. check that method signatures are consistent23:13
kgriffsyou can also inherit from routing controller23:13
rivetercan I suggest a 4?23:13
riveteryeah23:14
kgriffsbut now all it does is factor out the __init__ line23:14
kgriffsself._lookup = self._pool_catalog.lookup23:14
riveteryeah, the __init__ methods could actually be removed entirely, they're identical & could be done in RoutingC23:14
kgriffsright. I don't see anything right off that could be factored out.23:14
kgriffsmakes RoutingController pretty simple23:15
riveteryeah23:15
riveterone thought though?23:15
riveterthe really repetitive code all looks like23:16
rivetertarget = self._lookup(queue, project)23:16
riveterif target: control = target.message_controller23:17
rivetercould catalog just provide a lookup_message_controller method?23:17
riveterand similarly for queue and claim?23:17
kgriffssure23:18
riveterit'd trim one line out of every method without being weird or hitting performance23:18
kgriffssounds good!23:18
riveterok23:18
riveterum23:18
kgriffsso I know this is sort of the opposite of what this bug was going to do23:19
riveteris this just patch-set 3 for the same review process?23:19
kgriffsbut I think I would rather choose "clean and simple" rather than "DRY and super hacky"23:19
riveteror do I start a new branch, or something?23:19
kgriffsriveter: good question23:19
riveteryeah, that's probably just as well23:19
riveterclever code is more fun to write than to maintain :)23:19
kgriffsit is probably easiest to start a new branch and abandon the old one, since this approach is quite different23:19
riveterok23:20
riveterstill referring to the same bug though?23:20
kgriffsriveter: so, after all this is done, if we want to still try to DRY things a little more we could use macropy23:20
kgriffsbut idk if it is worth it23:20
kgriffshttps://gist.github.com/anonymous/71ba60f941446b6ae15423:20
riveterhonestly, if the catalog methods go in there won't be that much repetition23:20
kgriffsthat @proxy is actually a macro that changes the AST when the module is imported23:20
riveterooh23:20
kgriffsriveter: yeah, good point23:20
rivetershiny23:20
kgriffsanyway, I gotta run23:21
riveterok, thanks23:21
kgriffssure.23:21
riveterI'm not around much for the next week, but will do this first week of nov23:21
kgriffsOK23:21
kgriffssorry for the change of direction on this23:22
kgriffssometimes you have to give something a try before you know whether it is a good idea or not. :p23:22
riveterno worries :)23:22
rivetercheers23:22
kgriffsthanks!23:22
kgriffstake care23:22
kgriffso/23:22
riveter\o23:23
*** X019 has joined #openstack-zaqar23:31
*** sgotliv has quit IRC23:39
*** gmann has left #openstack-zaqar23:39
*** kgriffs is now known as kgriffs|afk23:49

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