Wednesday, 2014-06-04

*** sriram has joined #openstack-marconi00:50
*** prashanthr_ has left #openstack-marconi01:13
*** oz_akan__ has joined #openstack-marconi01:38
*** nosnos has joined #openstack-marconi01:38
*** oz_akan_ has quit IRC01:40
*** sriram has quit IRC02:50
*** rwsu has quit IRC03:10
*** vkmc has quit IRC03:23
*** nosnos has quit IRC03:29
*** haomaiwang has joined #openstack-marconi03:40
*** haomaiwang has quit IRC03:48
*** haomaiwang has joined #openstack-marconi03:48
*** haomai___ has joined #openstack-marconi04:05
*** haomaiwang has quit IRC04:05
*** oz_akan__ has quit IRC04:10
*** haomaiwang has joined #openstack-marconi04:21
*** haomai___ has quit IRC04:23
*** haomaiwa_ has joined #openstack-marconi04:25
*** haomaiwang has quit IRC04:25
*** nosnos has joined #openstack-marconi04:26
*** haomai___ has joined #openstack-marconi04:34
*** haomaiwa_ has quit IRC04:36
*** oz_akan_ has joined #openstack-marconi04:41
*** oz_akan_ has quit IRC04:46
*** shakamunyi has joined #openstack-marconi05:04
*** AAzza_afk is now known as AAzza05:22
*** flwang has quit IRC05:40
*** oz_akan_ has joined #openstack-marconi05:42
*** oz_akan_ has quit IRC05:46
*** haomai___ has quit IRC05:49
*** haomaiwa_ has joined #openstack-marconi05:49
*** AAzza is now known as AAzza_afk05:59
*** AAzza_afk is now known as AAzza06:17
*** mkoderer has joined #openstack-marconi06:20
*** jamie_h has joined #openstack-marconi06:32
*** oz_akan_ has joined #openstack-marconi06:43
*** oz_akan_ has quit IRC06:47
*** AAzza is now known as AAzza_afk07:08
*** oz_akan_ has joined #openstack-marconi07:43
*** renlt has joined #openstack-marconi07:46
*** oz_akan_ has quit IRC07:48
*** shakamunyi has quit IRC08:10
*** lvh_ is now known as lvh08:19
*** flaper87|afk is now known as flaper8708:35
*** jamie_h has quit IRC08:48
*** mkoderer has quit IRC08:48
*** openstackgerrit has quit IRC08:48
*** mkoderer has joined #openstack-marconi08:48
*** jamie_h has joined #openstack-marconi08:49
*** openstackgerrit has joined #openstack-marconi08:50
openstackgerritFlavio Percoco proposed a change to openstack/marconi: Rename shards to pool
*** oz_akan_ has joined #openstack-marconi09:45
*** oz_akan__ has joined #openstack-marconi09:47
*** oz_akan_ has quit IRC09:47
*** oz_akan__ has quit IRC09:51
*** wirehead_ has quit IRC09:52
*** renlt has quit IRC09:59
*** haomaiwa_ has quit IRC10:05
*** haomaiwang has joined #openstack-marconi10:06
*** nosnos has quit IRC10:08
*** haomai___ has joined #openstack-marconi10:09
*** haomaiwang has quit IRC10:12
*** wirehead_ has joined #openstack-marconi10:13
*** haomai___ has quit IRC10:24
*** haomaiwang has joined #openstack-marconi10:25
*** shakamunyi has joined #openstack-marconi10:37
*** oz_akan_ has joined #openstack-marconi10:38
*** shakamunyi has quit IRC10:41
*** oz_akan_ has quit IRC10:43
*** torgomatic has quit IRC10:48
*** torgomatic has joined #openstack-marconi10:55
*** flaper87 is now known as flaper87|afk11:25
*** oz_akan_ has joined #openstack-marconi11:39
*** oz_akan_ has quit IRC11:44
*** vkmc has joined #openstack-marconi12:05
*** vkmc has quit IRC12:05
*** vkmc has joined #openstack-marconi12:05
*** haomaiwang has quit IRC12:40
*** haomaiwang has joined #openstack-marconi12:40
openstackgerritAlex Bettadapur proposed a change to openstack/marconi: Decoupled Unit Tests
*** jchai has joined #openstack-marconi12:43
*** abettadapur has joined #openstack-marconi12:44
*** sriram has joined #openstack-marconi12:45
*** haomaiw__ has joined #openstack-marconi12:46
abettadapursriram: i submitted another patch if you want to take a look12:46
sriramabettadapur: awesome, let me check.12:46
*** Obulpathi has joined #openstack-marconi12:48
*** haomaiwang has quit IRC12:49
*** abettadapur has quit IRC12:55
*** Obulpathi has quit IRC13:04
*** abettadapur has joined #openstack-marconi13:09
*** jmckind has joined #openstack-marconi13:11
*** shakamunyi has joined #openstack-marconi13:17
openstackgerritAlex Gaynor proposed a change to openstack/marconi: Removed now unnecesary workaround for PyPy
*** oz_akan_ has joined #openstack-marconi13:24
*** Obulpathi has joined #openstack-marconi13:31
sriramkgriffs|afk: ping13:31
*** balajiiyer has joined #openstack-marconi13:53
*** mwagner_lap has joined #openstack-marconi13:53
*** flaper87|phone has joined #openstack-marconi13:55
sriramflaper87|phone: Is there a way to check response for deleting/claiming messages in the client?14:05
sriramdeserealized content just returns None, would it require another patch?14:05
*** alcabrera|afk is now known as alcabrera14:06
flaper87|phoneYou should be able to know the result based on the response code14:06
flaper87|phoneI don't have a link handy but there should be some info in the wiki14:06
flaper87|phone(Sorry) :D14:07
flaper87|phoneAs you may have figured, I'm using my phone14:07
sriramhmm, msg.delete() returns None, there is no response object.14:07
sriramflaper87|phone: haha, thats fine :)14:07
flaper87|phoneThen everything went well. The client raises an exception when a non 200 status code is returned14:07
flaper87|phoneOr at least it should14:08
flaper87|phoneBTW, make sure to mention me when you write something :D14:08
flaper87|phoneOtherwise I won't know you did14:08
flaper87|phone(Stupid irc client)14:08
*** Obulpathi has quit IRC14:09
sriramflaper87|phone: the exceptions right now are raised only in the case of 400, and 404.14:09
*** Obulpathi has joined #openstack-marconi14:09
flaper87|phoneMmh, not for 500?14:10
flaper87|phoneI wouldn't be surprised. I've been adding exceptions based on our API spec14:10
sriramflaper87|phone: hmm, alright. do we want another patch in there for that? I'm just making sure we can do error handling for marconi-bench14:15
sriramsince it uses the client for both the consumer and producer14:15
flaper87|phoneAbsolutely, if there are unhandled errors then yes14:15
sriramflaper87|phone: all right, I'll put out another patch for that once claim and delete is merged.14:17
sriramflaper87|phone: Thanks for your thoughts! :)14:17
sriramalcabrera: hey!14:17
sriramalcabrera: could you have a look at ?14:18
flaper87|phoneLoool @ "once claim is merged.... alcabrera could you have a look at...."14:20
alcabreragood morning, all. :)14:21
alcabrerasriram: sure thing14:21
sriramThanks alcabrera :) and good morning :P14:21
*** prashanthr_ has joined #openstack-marconi14:23
alcabrerasriram: small nit. +0. I'm ready to merge this, but I wanted you to see my comment. :)14:24
Alex_Gaynoralcabrera: Can you W+ this: (it's already got +2s, but lost the W+ on rebase)14:25
sriramalcabrera: ooh nice, thanks for the comment! I'll make that change.14:26
alcabreraAlex_Gaynor: sure thing14:26
alcabreranp. :)14:27
alcabrerasriram: I like to minimize the use of local bindings as much as possible, since it's one less assignment (local state) to track.14:28
sriramalcabrera: makes sense :)14:28
*** kgriffs|afk is now known as kgriffs14:28
alcabreralet me know when it's ready and I'll +2 and try to bug flaper87|phone or kgriffs to get the patch moving. :)14:28
sriramalcabrera: hmm, if we remove claim1 we wont we able to prove that the and msg.claim_id is the same.14:31
sriramI think that print statement is required to show that we are indeed claiming messages that have the same claimid, as claim1.id14:32
sriramalcabrera: ^14:32
alcabrerasriram: oohh14:32
sriramwhat are your thoughts?14:32
alcabreraoh I see14:32
alcabreraprint('{claim_id} =? {id}'.format(claim_id=claim_id,
alcabrerahaha, the (=?) operator reminded me of prolog-like syntax14:33
alcabreragiven the need for the local state14:33
alcabreraand that it is an example14:33
alcabreraI'm super cool with it14:33
sriramalcabrera: woohoo :)14:34
alcabrerasriram: approved, thanks!14:35
sriramthanks for the review alcabrera!14:36
alcabreranp. :)14:38
*** rwsu has joined #openstack-marconi14:40
sriramkgriffs: ping, I'll submit another patch to the client for error handling. and we should be able to use those for marconi-bench's producer and consumer.14:41
*** reed has joined #openstack-marconi14:43
kgriffssriram: do you think we can get something extremely basic for benchmarking done by next tuesday?14:45
sriramkgriffs: I think so.14:46
sriramwe have the producer and consumer ready.14:46
sriramjust need to do some error handling.14:46
kgriffsObulpathi: can you confirm this is fixed?
openstackgerritA change was merged to openstack/python-marconiclient: Enable deleting of message with claim id
Obulpathikgriffs: looking into it14:50
kgriffssriram: I'd like to do a 0.0.2 release of the client - can you recruit a couple folks to smoke-test the latest code?14:50
sriramsure. Obulpathi,abettadapur : can you guys help?14:51
kgriffsin other news, I'd love to get some reviews on my patch:
Obulpathisriram kgriffs: Sure, I can test the code14:54
sriramkgriffs: I'l have a look.14:54
kgriffseveryone: I've got some training to go to today, so I'll be offline for a few hours. thanks for everyone's help!14:54
kgriffssriram: thanks!14:54
sriramkgriffs: \m/14:54
prashanthr_alcabrera , sriram , kgriffs: Good morning :)14:55
kgriffsprashanthr_: o/14:56
alcabreraprashanthr_: o/14:56
sriramprashanthr_: hey! Good Morning :)14:56
sriramvkmc: \o14:56
Obulpathikgriffs: confirm means ... should I test and confirm or should I mark it as done?14:57
vkmcgood morning/evening all!14:57
kgriffsprashanthr_, alcabrera: oh, before I forget, you should try and sync with flaper87 regarding whether redis driver should be in the main repo... I think it should given some people's AGPL concerns with deploying mongo. But I'd like to get everyone else's thoughts.14:57
*** haomaiw__ has quit IRC14:58
kgriffsObulpathi: I think it is marked as "fixed" but I want to be sure there is no pending work on it14:58
Obulpathikgriffs: nop .. its done14:58
prashanthr_kgriffs: Sure. Will sync with flaper87.14:58
Obulpathimalini and me both tested it. thanks kgriffs14:58
*** haomaiwang has joined #openstack-marconi14:58
alcabrerakgriffs, prashanthr_: good thought.14:59
alcabreraI'm favorable towards redis driver being part of marconi proper, for the record. :)14:59
alcabrerathe license point is a good one14:59
alcabrerabut also14:59
alcabrerahaving a non-persistent driver adds avenues for different use cases -- e.g., different performance optimizations15:00
kgriffsprashanthr_: I think Redis can support the entire v1 API, so it would be a good alternate for mongo. If we can find something else that could also do that, then we would need to decide which one to include "out of the box". I haven't investigated riak or kafka enough to know if they can support our entire API... TBD15:00
kgriffsgotta run15:01
alcabrerakgriffs: o/15:01
kgriffsprashanthr_, alcabrera: maybe you can start a thread on the ML to discuss?15:02
*** flaper87|phone has quit IRC15:02
prashanthr_alcabrera: True. I remember the priority based queue sharding discussion we had initially.15:02
*** kgriffs is now known as kgriffs|afk15:03
*** abettadapur has quit IRC15:11
*** sriram has quit IRC15:16
*** sriram has joined #openstack-marconi15:17
*** balajiiyer has quit IRC15:17
*** AAzza_afk is now known as AAzza15:19
*** malini_afk is now known as malini15:23
*** jamie_h has quit IRC15:37
sriramalcabrera,malini: we also need reviews on
*** jamie_h has joined #openstack-marconi15:39
alcabreraoh my -- +834, -24415:39
alcabrerathat's quite the patch.15:39
alcabreraI'll punt on reviewing that one 'til the end of the week. I don't think I can give that patch a proper review at the moment.15:40
sriramyeah, its big :) we need our unit tests decoupled pretty badly :P15:40
sriramalcabrera: ok15:40
*** balajiiyer has joined #openstack-marconi15:41
*** AAzza is now known as AAzza_afk15:45
*** balajiiyer has quit IRC15:58
*** abettadapur has joined #openstack-marconi15:59
*** mpanetta has joined #openstack-marconi16:01
*** haomaiwang has quit IRC16:10
sriramabettadapur: ping16:10
*** mpanetta has quit IRC16:12
*** mpanetta has joined #openstack-marconi16:12
*** ametts has quit IRC16:19
*** oz_akan_ has quit IRC16:19
*** oz_akan_ has joined #openstack-marconi16:19
*** abettadapur has quit IRC16:20
*** AAzza_afk is now known as AAzza16:21
*** prashanthr_ has left #openstack-marconi16:26
*** abettadapur has joined #openstack-marconi16:33
*** jchai is now known as jchai_afk16:39
*** balajiiyer has joined #openstack-marconi17:06
*** shakamunyi has quit IRC17:13
tjanczuk_vkmc: are you there?17:16
tjanczuk_flapper87: are you there?17:17
*** jchai_afk is now known as jchai17:21
*** jamie_h has quit IRC17:49
*** jamie_h has joined #openstack-marconi17:50
vkmctjanczuk_, hey there!17:52
tjanczuk_I spent some time with AMQP yesterday17:52
tjanczuk_I ran into an issue I think we need to discuss17:52
tjanczuk_It has to do with consuming messages using claims. I don't think this can be accomplished with the current shape of the HTTP APIs.17:53
vkmcyes I ran into the same issue with AMQP 1.017:53
vkmcwe should discuss this with alcabrera, flaper87 or/and kgriffs who has been working on Marconi since its beginning17:54
tjanczuk_With the HTTP APIs, one first creates a claim (and obtains the messages). In a subsequent HTTP call, the message[es] can be permanently deleted to indicate the client has "consumed" them.17:54
tjanczuk_Similar mechanism exists in AMQP: you first get the messages, and subsequently send an ack to the server to indicate they have been "consumed" and can be permanently deleted.17:55
tjanczuk_The problem is (and I believe it exists in both AMQP 0.9 and 1.0) that the acknowledgements must be sent over the same AMQP channel instance (bound to a TCP connection) that the messages were received over.17:56
*** jamie_h has quit IRC17:57
vkmcyes tjanczuk_, it happens in AMQP 1.0 as well17:57
alcabrerathat sounds tricky. :/17:57
tjanczuk_To implement this semantics over the HTTP-AMQP protocol bridge, one would need server affinity.17:57
alcabreraso you'd need to maintain a mapping of connections17:57
tjanczuk_I think there are a few options:17:57
tjanczuk_1) WebSockets. This is a natural way to maintain affinity.17:58
tjanczuk_2) When an API server receives a request to acknowledge a message for which it does not hold a channel instance, it forwards it (reverse proxy) to the appropriate backend instance that does.17:59
tjanczuk_3) Redirects. This would require individual API servers in the cluster to be addressable. Also, redirecting HTTP POSTs is a bit of a cutting edge,17:59
tjanczuk_4). Do not support claim semantics with AMQP storage. Basically an HTTP request would permanently consume the message. This is rather pathetic as it does not event support at-least-once, but I suppose it is better than not being able to receive messages at all ;)18:01
*** jamie_h has joined #openstack-marconi18:02
tjanczuk_Also, re: 4, I was trying to find the code that implements the "pop" semantics of deleting messages from a queue as per spec here: I could not find that code. Where is it?18:03
* alcabrera catches up18:04
vkmctjanczuk_, the pop functionality is not merged yet
tjanczuk_How does that code review thing work? Can I help move it along somehow?18:06
alcabreraI really like (1), in the sense of pursuing an alternate transport, since that would map more cleanly to amqp18:06
vkmctjanczuk_, regarding the options to support claims... I think that looking into adding websockets is good idea18:06
alcabreratjanczuk_: code review -- if 2 or more core reviewers +2 a given patch, it is then approved and merged18:06
tjanczuk_I also like the websockets approach most, I think it has a number of other advantages besides fixing this problem.18:07
vkmctjanczuk_, everyone can review :)
alcabreragood link, vkmc!18:08
vkmcthe pop fix has already been reviewed and is waiting for the changes... so there is nothing we can do there18:08
vkmctjanczuk_, which are the other advantages of adding websockets?18:09
vkmcalcabrera, yay to our wiki18:10
vkmcbtw tjanczuk_, did you created a blueprint to track the rabbit driver?
tjanczuk_In general many message broker protocols are optimized around persistent connections. AMQP, MQTT, even STOMP. Following from that broker implementations try to optimize around that persistent connection assumption (e.g. Kafka). If we can somehow expose that long lived connection concept all the way through the transport layer, we can have a much more optimal implementation than with that HTTP/TCP disparity.18:12
vkmctjanczuk_, I see, thanks18:14
tjanczuk_I did not create a blueprint. If I created it yesterday it would be out of date already. It is a discovery mission. I think once the prototype is running an issues understood and designed around, it makes sense to capture it in a blueprint.18:14
tjanczuk_What is the best way to go about adding support for WebSockets?18:14
tjanczuk_I understand WSGI has no notion of websockets.18:15
tjanczuk_Would that be a new transport layer in Marconi?18:15
*** AAzza is now known as AAzza_afk18:16
tjanczuk_Also, even if we have a new, connection-oriented transport implementation, I expect we would still have to model that concept in the ABC of the storage layer. So I would expect the storage layer abstractions to need some changes.18:17
alcabreratjanczuk_: that would be a new transport layer in marconi18:18
alcabrerae.g., websockets18:18
alcabreraflaper87|afk did a little work into this in the past18:18
tjanczuk_Yes, I think flapper87lafk was just bridging websockets to WSGI, which would not make the cut for the problem at hand.18:19
tjanczuk_Does Marconi support running multiple transports side by side?18:20
tjanczuk_Or is it an exclusive choice?18:20
tjanczuk_We have to reconcile the fact that WebSockets are really HTTP.18:21
alcabrerait's currently an exclusive choice18:21
alcabrerayou'd have to run two instances of marconi side by side18:22
alcabrerato achieve using two transports on one machine, for example18:22
alcabreratjanczuk_: ^18:23
tjanczuk_I am new to Python. What are folks using mostly for WebSockets? I saw some positive mentions of tornado, I think it also comes up towards the top in benchmarks.18:25
alcabreraI'm not familiar with websockets, so I'm not entirely sure what's being used atm.18:26
alcabreraor recommended18:26
vkmcI heard about Autobahn, but I haven't check it out yet18:26
tjanczuk_What did flapper87lafk use?18:26
openstackgerritA change was merged to openstack/marconi: Removed now unnecesary workaround for PyPy
alcabreraseems to be18:30
alcabreratjanczuk_: ^^18:30
alcabrerathanks, vkmc!18:30
openstackgerritSriram Madapusi Vasudevan proposed a change to openstack/python-marconiclient: Throw exceptions on erroneous status codes
vkmcyeah he used ws4py :)18:30
tjanczuk_Is that an HTTP server itself, or does it compose with other servers?18:32
alcabreranot sure. I haven't looked into it.18:33
tjanczuk_Let me look at that code...18:37
vkmctjanczuk_, there is something I'm not so sure about... don't we need server affinity for HTTP too?18:46
vkmcsorry if it's a silly question... I'm giving my first steps in this area18:46
*** stritz has quit IRC18:48
tjanczuk_The only two storage technologies implemented so far were DB-based: mongo and SQL. The mode of accessing DBs in vast majority of cases involves running RPC-style queries which map very well to short lived HTTP requests. That is why I suppose this issue has not come up before.18:48
tjanczuk_So to answer your question: there was no pressing need for server affinity of HTTP transport when the storage is Mongo or SQL.18:49
vkmcit makes sense yeah18:50
vkmcthanks for clearing it up18:50
tjanczuk_On the notion of my being new to Python: is my understanding correct that WSGI implies a blocking IO implementation, i.e. there is a thread held up for every active HTTP request in the system?18:56
Alex_GaynorNotionally yes, except there are things like eventlet which will monkey patch all your IO to use greenthreads, so you can get some concurrency18:57
tjanczuk_How does this work? Does it detect blocking IO and yields the thread under the hood? Does it operate a thread pool or is it single-threaded?18:58
Alex_Gaynorstill single threaded18:59
Alex_Gaynoryeah, it'll put the file descriptor in something like epoll and then switch to another green thread18:59
tjanczuk_Interesting. How does it compare to systems that are built on async io from the ground up like tornado?19:00
Alex_GaynorPersonally I find all the monkey patching distateful, and prefer something more explicit, like twisted; that said performance wise they're all pretty much in the same ballpark.19:01
tjanczuk_Also, can you take pretty much any WSGI app and run it with eventlet, or are there some restrictions?19:01
tjanczuk_Does Marconi run with eventlet?19:01
Alex_GaynorMore or less, except you often have other stuff that does IO, like a databsae library, and you need to make sure you use something that's monkeypatched or otherwise handles eventlet correctly.19:01
Alex_GaynorYes, marconi uses eventlet.19:01
Alex_Gaynor(If you care about performance, I strongly recommend using PyPy)19:02
tjanczuk_What is involved in "monkeypatching"? Does a library need to do something, the app using the library, or does eventlet just take care of it all?19:03
*** reed has quit IRC19:06
tjanczuk_vkmc: another AMQP issue I ran into has to do with message ID. That concept does not really exist in AMQP, so something needs to be done about all the HTTP APIs that accept or return message IDs. For example, publishing messages endpoint is supposed to return an array of message IDs. These are later used to delete the message (along with a claim id).19:09
openstackgerritSriram Madapusi Vasudevan proposed a change to openstack/python-marconiclient: Throw exceptions on erroneous status codes
tjanczuk_vkmc: a model that would work better for AMQP is to have 1-1 relationship between claim ID and a message (rather than 1-n as it is the case right now), and use the claim IDs alone to delete messages.19:13
vkmctjanczuk_, iirc the messages in amqp-proton have an id attribute
vkmctjanczuk_, perhaps that is library related?19:32
tjanczuk_I am not sure. Does that ID later act as input to any of the operations?19:32
*** malini is now known as malini_afk19:32
*** jamie_h has quit IRC19:33
* vkmc checking19:34
tjanczuk_In the AMQP 0.9 model, a "delivery tag" is issued for a message being consumed by the server. That tag is unique within a given AMQP channel. The client later uses that tag to acknowledge the message (and have the server permanently delete it) *on the same channel*. Message IDs are not involved in the process.19:36
tjanczuk_(This is by the way simialar to how SQS and Azure model consumption and acknowledgment with HTTP).19:38
*** reed has joined #openstack-marconi19:38
vkmcwell.. as far as I could see19:42
vkmcthe id is not used19:42
vkmcI guess it's an added attribute to ease de management in applications using qpid-proton19:42
tjanczuk_right, message IDs are not really relevant in the AMQP model19:43
vkmcMessages in qpid-proton also have an user-id... so I think we could use them for claims instead of websockets19:44
vkmcyou are right tjanczuk_, is not part of the AMQP model19:45
vkmcsorry for the delay but there are no manuals for proton yet19:45
tjanczuk_I am not sure what you mean by "we could use them for claims instead of websockets"?19:45
vkmcI mean that we could implement claims as we do with the HTTP API, using a client-id to claim messages19:47
vkmcuser-id is also an added attribute in proton19:47
vkmcwe would need websockets for rabbit19:48
tjanczuk_I am still not sure how user-id helps. How does consumption/acknowledgement work in AMQP 1.0?19:49
*** malini_afk is now known as malini19:56
*** oz_akan_ has quit IRC19:57
*** fifieldt_ has joined #openstack-marconi20:00
vkmcwell in fact it's confusing because it's quite different to how AMQP < 1.0 works20:02
vkmcI'm following this thread
*** fifieldt-afk has quit IRC20:04
vkmcgive me a moment to see if I'm heading in the right direction20:04
*** mwagner_lap has quit IRC20:20
*** ykaplan has joined #openstack-marconi20:23
tjanczuk_People in the know (Clemens Vesters) pointed me at Apparently AMQP 1.0 has a concept of resuming deliveries which I think (not sure) would allow acknowledgment (disposition in AMQP 1.0 lingo) to be sent over a different TCP connection. I suspect the devil is in the details. You may want to read through the AMQP 1.0 spec looking for things like20:31
openstackgerritAndreas Jaeger proposed a change to openstack/marconi: Prepare marconi for localization
*** abettadapur has quit IRC20:35
*** sriram has quit IRC20:38
*** alcabrera is now known as alcabrera|afk20:51
*** balajiiyer has quit IRC20:52
*** oz_akan_ has joined #openstack-marconi21:12
*** Obulpathi has quit IRC21:22
*** jchai has quit IRC21:28
*** oz_akan_ has quit IRC21:33
*** oz_akan_ has joined #openstack-marconi21:34
*** vkmc has quit IRC21:55
*** malini has left #openstack-marconi22:06
*** mkoderer has quit IRC22:06
*** mkoderer has joined #openstack-marconi22:11
*** ykaplan has quit IRC22:38
*** oz_akan_ has quit IRC23:29

Generated by 2.14.0 by Marius Gedminas - find it at!