Thursday, 2013-02-07

*** bdpayne has joined #openstack-meeting-alt00:06
*** esp1 has joined #openstack-meeting-alt00:07
*** esp1 has left #openstack-meeting-alt00:08
*** kaganos has quit IRC00:11
*** rnirmal has quit IRC00:15
*** grapex has quit IRC00:19
*** cloudchimp has joined #openstack-meeting-alt00:23
*** cloudchimp has quit IRC00:27
*** sacharya has joined #openstack-meeting-alt00:33
*** bdpayne has quit IRC01:40
*** robertmyers has joined #openstack-meeting-alt01:48
*** esp has joined #openstack-meeting-alt02:15
*** esp has left #openstack-meeting-alt02:16
*** yidclare has quit IRC02:47
*** grapex has joined #openstack-meeting-alt02:56
*** grapex has quit IRC02:56
*** grapex has joined #openstack-meeting-alt02:56
*** treeder has quit IRC03:23
*** yidclare has joined #openstack-meeting-alt03:32
*** treeder has joined #openstack-meeting-alt03:35
*** amyt has joined #openstack-meeting-alt04:07
*** amyt has quit IRC04:10
*** amyt has joined #openstack-meeting-alt04:10
*** amyt_ has joined #openstack-meeting-alt04:19
*** amyt has quit IRC04:20
*** amyt_ is now known as amyt04:20
*** esp has joined #openstack-meeting-alt04:22
*** esp has left #openstack-meeting-alt04:24
*** grapex has quit IRC04:33
*** amyt has quit IRC04:34
*** amyt has joined #openstack-meeting-alt04:35
*** bdpayne has joined #openstack-meeting-alt04:45
*** bdpayne has quit IRC05:00
*** bdpayne has joined #openstack-meeting-alt05:05
*** sacharya has quit IRC05:17
*** bdpayne has quit IRC05:54
*** treeder has quit IRC05:57
*** bdpayne has joined #openstack-meeting-alt06:00
*** bdpayne has quit IRC06:03
*** amyt has quit IRC09:17
*** robertmyers has quit IRC13:32
*** grapex has joined #openstack-meeting-alt14:14
*** robertmyers has joined #openstack-meeting-alt14:29
*** robertmyers has joined #openstack-meeting-alt14:30
*** grapex has quit IRC14:51
*** jcru has joined #openstack-meeting-alt14:58
*** cloudchimp has joined #openstack-meeting-alt15:01
*** amyt has joined #openstack-meeting-alt15:19
*** sacharya has joined #openstack-meeting-alt15:19
*** rnirmal has joined #openstack-meeting-alt15:20
*** sacharya has quit IRC15:29
*** jcru is now known as jcru|away15:44
*** jcru|away is now known as jcru15:49
*** amyt has quit IRC15:56
*** amyt has joined #openstack-meeting-alt15:57
*** sacharya has joined #openstack-meeting-alt15:59
*** cp16net is now known as cp16net|away16:04
*** cp16net|away is now known as cp16net16:06
*** robertmyers has left #openstack-meeting-alt16:13
*** grapex has joined #openstack-meeting-alt16:22
*** grapex has quit IRC16:25
*** grapex has joined #openstack-meeting-alt16:25
*** bdpayne has joined #openstack-meeting-alt16:27
*** grapex has quit IRC16:50
*** grapex has joined #openstack-meeting-alt16:52
*** grapex has quit IRC16:56
*** grapex has joined #openstack-meeting-alt16:56
*** grapex has quit IRC16:57
*** grapex has joined #openstack-meeting-alt17:51
*** esp1 has joined #openstack-meeting-alt18:10
*** jcru is now known as jcru|away18:17
*** cppcabrera has joined #openstack-meeting-alt18:29
*** bdpayne has quit IRC18:30
*** bdpayne has joined #openstack-meeting-alt18:31
*** esp1 has left #openstack-meeting-alt18:36
*** wkharold has joined #openstack-meeting-alt18:49
*** kgriffs has joined #openstack-meeting-alt18:49
*** treeder has joined #openstack-meeting-alt18:52
*** flaper87 has joined #openstack-meeting-alt18:54
*** carimura has joined #openstack-meeting-alt18:59
carimuraHowdy.19:00
kgriffsHey19:01
kgriffs#startmeeting marconi19:01
openstackMeeting started Thu Feb  7 19:01:50 2013 UTC.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.19:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:01
*** openstack changes topic to " (Meeting topic: marconi)"19:01
openstackThe meeting name has been set to 'marconi'19:01
*** ametts-atl has joined #openstack-meeting-alt19:01
kgriffs#topic API19:02
*** openstack changes topic to "API (Meeting topic: marconi)"19:02
kgriffsSo, as I mentioned in the meeting agenda email, I spent a lot of time cleaning up and simplifying the API spec based on feedback from the community as well as from some Rackspace folks.19:03
kgriffsIt's by no means final, but I wanted to get everyone's feedback on the draft as it now stands.19:03
*** edsrzf has joined #openstack-meeting-alt19:04
kgriffshttp://wiki.openstack.org/marconi/specs/api/v119:04
kgriffsAnyone have something specific they want to bring up?19:04
treederreading...19:04
flaper87o/19:04
flaper87so, the api looks good so far19:05
flaper87what I was wondering is whether we're planning to support just http requests or also add support for other channels like zmq (for example)? (might be a bit too early to talk about this but it would help us to define the api in a more consistent way)19:06
wkharoldagree, might help if resources were identified explicitly19:06
flaper87I was wondering that because other channels might be faster for some cases19:06
flaper87and would help to improve performance19:06
kgriffsThere's been a little bit of talk about doing web sockets or something, but I think it makes sense to consider the broader question of other protocols.19:08
kgriffsScaling out can get tricky with persistent connections, but it can be done.19:08
flaper87kgriffs: indeed it can but, considering that we're defining it right now, it might be worth it to design it more pluggable from the beggining. I've no objections so far and I think it can be "translated" to something else easily19:10
treederkgriffs: should we go through the spec function by function?19:10
flaper87I guess what I'm trying to say is that I agree with the api so far but I would definitely create a more pluggable architecture19:10
kgriffsAgreed. In fact, I've alluded to that in the spec (scroll to the bottom):19:11
kgriffshttp://wiki.openstack.org/marconi/specs/grizzly19:11
treederflaper87: are you suggesting to not use http?19:12
kgriffsHowever, I hadn't considered making the protocol itself pluggable. That's something that could be done without too much trouble.19:12
flaper87treeder: not at all, I'm suggesting to use http and other channels19:12
flaper87kgriffs: agreed!19:12
kgriffs#action kgriffs to update spec/architecture plan to allow more than just HTTP19:14
flaper87kgriffs: feel free to add me in that action as well19:14
kgriffsCool, thx.19:14
kgriffs#action flaper87 to update spec/architecture plan to accommodate persistent transports such as ZMQ19:15
kgriffsOK, getting back to the API19:15
kgriffs#topic API - Media Types19:16
*** openstack changes topic to "API - Media Types (Meeting topic: marconi)"19:16
treederbe nice if we could comment right in the wiki19:16
kgriffsyeah19:16
kgriffsI could try to paste it into etherpad19:17
flaper87kgriffs: +119:17
kgriffshttps://etherpad.openstack.org/queuing-api19:18
kgriffsSo, the eternal debate: XML, JSON19:18
kgriffsDoes 1.0 need to support XML?19:19
*** cp16net is now known as cp16net|away19:19
* flaper87 loves JSON and hates xml19:19
*** grapex has quit IRC19:19
treederjson +1019:19
wkharoldflaper87: +119:19
* kgriffs senses mild enthusiasm for JSON19:20
treederkgriffs: would there be any particular reason to support it?19:20
flaper87I would say we should got step-by-step and add first one of those (and by one of those I mean JSON) and think about creating a more consistent api19:20
flaper87then we would be able to add support for other stuff like xml, msgpack or whatsoever19:20
kgriffsAgreed.19:21
treederagreed19:21
wkharold#agreed19:21
*** cp16net|away is now known as cp16net19:21
kgriffsThere was a push at the last summit to get better XML support (some projects don't offer it at all, or are buggy). However, the argument was that enterprises have these expensive appliances they've invested in that only do XML.19:22
flaper87kgriffs: makes sense19:22
kgriffsThat being said, there's the argument for using a translator that takes in JSON and spits out XML.19:22
kgriffs(ala Atom Nuke)19:23
kgriffsOf course, I think it's OK to not target large enterprise with 1.019:23
flaper87kgriffs: hehe19:23
flaper87kgriffs: translators could make sense, even though I'm afraid there'll be a real pain in the ***19:24
flaper87anywho19:24
kgriffsOK19:24
kgriffs#agreed Start with JSON, add other media types later19:24
kgriffsSo, if you guys want to comment directly in etherpad and I can bubble those up as discussion topics, we can keep moving.19:25
*** grapex has joined #openstack-meeting-alt19:25
treederok19:25
kgriffs(or just post on IRC)19:25
treederi'm going to go through each function19:25
cppcabrera(I'm taking notes of the meeting. I can distribute them afterwards to those interested.)19:25
kgriffsSounds good19:25
treederi think that'll be most productive19:25
treederCreate a qudeue19:26
treederqueue19:26
treederI think that looks fine as is19:26
kgriffscppcabrera: Thx. meetbot does that too, but it would be good to compare notes.19:26
flaper87+119:26
treedercool19:26
treederAlright, Reconfigure a queue19:26
kgriffsOK. I didn't have any other config other than TTL at the moment.19:27
treederI think this could just be changed to the parameters themselves19:27
*** vipul is now known as vipul|away19:27
treederinstead of having ops, how about just if "ttl" is specified, then it changes the ttl?19:27
*** jcru|away is now known as jcru19:27
treedersame as creating a queue19:27
kgriffsIf/when more options are available, I think we want standard JSON-Patch support. However, we can just allow all-or-nothing to start with.19:28
kgriffs"op" is from the JSON Patch RFC19:28
treederoh19:28
treederdoes that mean one op per request though?19:28
kgriffsno, I messed that up. It's supposed to be inside an array19:29
treederhttp://tools.ietf.org/html/draft-pbryan-json-patch-0419:30
kgriffsyep. It's actually on revision 10 now19:30
kgriffshttps://tools.ietf.org/html/draft-ietf-appsawg-json-patch-1019:30
wkharoldis PATCH supported in the relevant HTTP servers?19:31
kgriffsThere was some talk about doing xml-patch as well, but not sure where that ended up19:31
kgriffsDo you have one in mind?19:31
kgriffs(server)19:31
treederprobably the bigger problem is client libs supporting it19:32
wkharoldThe usual suspects, Apache, etc19:32
kgriffsoic19:32
kgriffsJust wanted to make sure you weren't talking about IIS. :p19:32
flaper87hahahaha19:32
wkharoldblech19:32
treederhehe19:32
* flaper87 takes his shotgun19:32
kgriffsDoes anyone know about Apache and Nginx off the top of their heads.19:32
flaper87cherokee ?19:33
wkharoldnope, hence the query19:33
kgriffsAnyone want to volunteer to survey PATCH support?19:34
wkharoldI guess I should step up19:34
kgriffscool.19:34
flaper87wkharold: thx19:34
treederwkharold: bet you wish you didn't ask that question huh?  ;)19:35
kgriffs#action wkharold to check PATCH support in Apache, Nginx, Cherokee, etc.19:35
wkharoldsomeday I'll learn19:35
*** grapex has left #openstack-meeting-alt19:35
treederregarding json patch vs just a straight json object (same as PUT), i'd vote for straight up json object.19:36
treedermuch simpler19:36
kgriffswkharold: if you could send out an email to openstack-dev [marconi] with the results, or share in the next meeting that would be groovy.19:36
flaper87treeder: +119:36
kgriffsAgreed, as long as the document isn't complex19:36
wkharoldtreeder: modulo the size of the json19:36
treederi don't think we'll have any complex documents in this spec19:36
flaper87that would make everything more consistent19:37
cppcabrerakgriffs: Does the marconi project have a Trello board or something similar yet? This thought struck me as action items are being detailed.19:37
kgriffs#agreed for simple document updates, don't use PATCH19:37
* flaper87 is a big fan of consistency19:37
kgriffscppcabrera: Not a public one, but that can be easily remedied.19:37
* treeder is a big fan of consistency too19:37
treedertrello board: +119:38
flaper87trello board ++19:38
kgriffs#action cppcabrera to hook us up with a public trello board19:39
kgriffsLooks like we have a volunteer. :D19:39
cppcabreraWill do. I'll start adding action items to it during the course of the meeting. :)19:39
treederawesome19:39
kgriffscppcabrera: At the end of the meeting, meetbot will summarize actions, but it would be good to watch for anything we miss19:40
*** vipul|away is now known as vipul19:40
cppcabreradone - https://trello.com/board/openstack-marconi/511403287d138cd6200078e019:40
treederalright, done with patching a queue then?19:40
kgriffs#topic API - Delete a Queue19:40
*** openstack changes topic to "API - Delete a Queue (Meeting topic: marconi)"19:40
treedercppcabrera: can you us to the board? i'm treeder19:41
treederthanks19:41
cppcabreratreeder: np19:41
treederdelete looks good to me19:42
flaper87cppcabrera: flaper8719:42
flaper87:)19:42
ametts-atlcppcabrera: allanmetts19:42
flaper87looks good to me as well19:42
treederkgriffs: notice you changed reconfigure to a PUT19:42
treederI think the http op should still be PATCH19:43
kgriffs#agreed Delete a Queue is OK as-is19:43
kgriffsmmm. Not sure about that.19:43
treederand here's example of why19:43
treederlet's assume there's more than one parameter19:43
treederttl and x19:43
treedersay I just want to change the ttl19:43
treederthen I just send in the ttl19:44
treeder{ "ttl": x}19:44
treederif i want to change both: {"ttl":y, "x": z}19:44
kgriffsWell, in that case I'd rather use json-patch since that's on the standards track.19:44
kgriffsBut if there are only two attributes, it seems fine to require setting the entire thing19:45
treederyou think that'll become a used standard?19:45
kgriffsyes19:45
flaper87yep19:45
treederrough19:45
treederwell maybe we should use it then19:46
kgriffsI know that there's a de-factor standard out there today to do what you describe, but eventually things will move to JSON-patch19:46
flaper87wait19:46
kgriffsIMHO19:46
* flaper87 thinking19:46
kgriffsAlthough, either way it's really only a few lines of code to implement.19:47
kgriffs#topic API - json-patch vs. implicit patch19:47
flaper87PATCH http method should be used for modifine *some* arguments of the document19:47
*** openstack changes topic to "API - json-patch vs. implicit patch (Meeting topic: marconi)"19:47
flaper87and PUT for the whole document19:48
kgriffsCorrect. If you want to modify all of them, then it doesn't make sense.19:48
kgriffsThat's what I was saying about not needing it if there's only "ttl", for example.19:48
kgriffsBut we could always add support l8r19:48
wkharoldusually PUT updates by replacing the whole representation, even if only one thing changes19:48
kgriffsgood point. And you aren't really recreating the queue19:49
treederkgriffs: ya, there's high probability that more features will be added19:49
kgriffsit's a fuzzy line. What's everyone's vote?19:49
treederand we'll want to keep this consistent across entire api19:49
*** cp16net is now known as cp16net|away19:49
kgriffsyes, and currently claiming a message is done with PATCH19:50
*** bdpayne has quit IRC19:50
flaper87let's vote19:50
treederI vote PATCH, but not sure about the json-patch19:50
kgriffsnoted19:50
flaper87options json-patch or straight json19:50
*** bdpayne has joined #openstack-meeting-alt19:50
wkharoldstraight json, PUT complete representation19:51
cppcabrera+1 json-patch19:51
treederstraight json19:51
flaper87kgriffs: bot should handle votes19:51
flaper87so it is logged in the meeting report19:51
kgriffsoic19:51
kgriffshmmm. Is there a hashtag for that?19:52
kgriffsI'm not seeing it19:52
kgriffshttp://meetbot.debian.net/Manual.html19:52
flaper87#startvote JSON-PATCH? Yes, No19:52
openstackOnly the meeting chair may start a vote.19:52
flaper87kgriffs: :)19:52
* flaper87 shoots the stupid bot19:53
kgriffscool19:53
kgriffsOk, let's take it one at a time - first, PATCH vs. PUt19:53
kgriffs#startvote PATCH vs. PUT? PATCH, PUT19:53
openstackBegin voting on: PATCH vs. PUT? Valid vote options are PATCH, PUT.19:53
openstackVote using '#vote OPTION'. Only your last vote counts.19:53
treeder#vote PATCH19:53
flaper87#vote PATCH19:53
cppcabrera#vote PATCH19:53
wkharold#vote PUT19:53
kgriffs#endvote19:54
openstackVoted on "PATCH vs. PUT?" Results are19:54
openstackPUT (1): wkharold19:54
openstackPATCH (3): cppcabrera, treeder, flaper8719:54
flaper87(perhaps we should have considered both?)19:54
flaper87:P19:54
treederwkharold: we could have PUT too19:54
wkharoldnp ... I'm a good loser19:54
treederahh, ya, was just thinking the same flaper8719:54
kgriffs#startvote Do PUT first, add PATCH later? Yes, No19:54
openstackBegin voting on: Do PUT first, add PATCH later? Valid vote options are Yes, No.19:54
openstackVote using '#vote OPTION'. Only your last vote counts.19:54
wkharold#vote Yes19:55
flaper87#vote Yes19:55
treedermy vote for that depends on what we decide on the next vote. ;)19:55
cppcabrera#vote Yes19:55
*** cp16net|away is now known as cp16net19:56
kgriffs#endvote19:56
openstackVoted on "Do PUT first, add PATCH later?" Results are19:56
openstackYes (3): wkharold, cppcabrera, flaper8719:56
kgriffs"The PUT method requests that the state of the target resource be19:56
kgriffs   created or replaced with the state defined by the representation19:56
kgriffs   enclosed in the request message payload."19:56
* flaper87 likes IRC politics19:56
kgriffshttp://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.3.419:56
treederalright, that makes it easy19:56
kgriffsI'm fine with doing PUT19:56
cppcabreraPUT is simpler to support than PATCH - makes sense to go after it first, IMO.19:57
treederuntil we get to something else that requires modifications19:57
kgriffsRESTafarians may disagree, but it's close enough semantically19:57
treedercan we skip to POST Message before GET?19:57
kgriffs#agreed PUT first, PATCH later if needed19:57
flaper87I stick with my vote, both should be supported. PUT first and then patch it if needed19:57
flaper87w00t19:57
kgriffsYou read my mind. :D19:57
kgriffsOK, we only have time for one more topic19:58
kgriffs#topic API - POST message19:58
*** openstack changes topic to "API - POST message (Meeting topic: marconi)"19:58
treederok19:58
treederok, one thing that isn't clear to me is what body format is19:58
wkharold#info according to http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates most servers grok PATCH19:59
treederlooks like it's json in the spec19:59
kgriffswait a sec19:59
*** jcru has quit IRC19:59
kgriffssorry, I think I forgot to hoist those up one level19:59
kgriffsLet me try something in etherpad...19:59
treederI think it should be a string?19:59
treederie: anything19:59
kgriffsOh, wait19:59
kgriffsOK, let's talk about contents of body then we can jump back to whether "body" can be removed and the contents hoisted.20:00
flaper87treeder: what do you mean? I'm missing something20:00
kgriffsSo, body can be anything JSON supports20:00
kgriffs"body": "foo"20:01
kgriffsGuess I should add more examples20:01
flaper87kgriffs: mmh, not sure about that20:01
flaper87so20:01
flaper87Body content can be anything, agreed, but we should somehow "de-normalize" it to something less harmful20:02
wkharoldquestion, why POST to queue_name/messages why not just POST to queue_name?20:03
flaper87for example, what happens if the content has non-ascii characters? or other characters?20:03
flaper87what about having it serialized to b64 or something like that in order to *always* have a string20:03
flaper87or whatever20:03
kgriffsIt would have to be valid JSON, and we could enforce UTF-820:03
treederit should be a json safe string20:03
flaper87celery does something similar20:03
kgriffsI anticipate doing JSON validation20:03
* flaper87 is way paranoid20:04
kgriffsIf a client submits something bogus, they get 40020:04
kgriffsStorage backends can just store as an opaque string (no need to parse)20:04
cppcabrera+1 for JSON validation20:04
flaper87fair enough20:04
wkharoldditto +120:04
kgriffs#agreed JSON validation required20:04
flaper87and, we will support compressed messages?20:05
flaper87maybe for the next meeting20:05
wkharoldstill wondering about queue_name/messages ...20:05
kgriffsIf we ever add JSON-P support, we will have to get even more paranoid, like using the while(1) trick20:05
* flaper87 shoots json-p in the legs20:05
treederseems to me that shoudl be encoded20:05
treedereg:20:05
wkharoldJSON-P old and broken, CORS new hotness20:05
kgriffs#action kgriffs to Add more examples for body of messages20:06
treeder "body": "{20:06
treeder      \"event\": \"BackupStarted\",20:06
treeder      \"backupId\": \"c378813c-3f0b-11e2-ad92-7823d2b0f3ce\"20:06
treeder    }"20:06
treedercould be xml, could be anything20:06
kgriffsWell, if clients want to do that, they are perfectly welcome.20:06
kgriffsBut I don't want to prevent people from just using straight JSON for readability or whatever20:07
wkharoldMIME?20:07
wkharoldfor message body ...20:07
cppcabrera'application/json' makes sense for a json-encoded body.20:09
treedermight need a mime type i guess if we support json structures20:09
kgriffsWell, I don't think it's very hard to validate the body text and make sure there's nothing funky in there, and assuming you aren't constructing DB inserts by hand, I'm not worried about the security issue.20:09
treederjson or text20:09
flaper87I'd stick with application/json20:09
kgriffsagreed20:10
flaper87cool20:10
flaper87gotta run20:10
flaper87lets finish it :P20:10
kgriffsIf clients want to use something different, as long as they can UTF-8 encode into a string, go for it.20:10
kgriffsOK20:10
treederguess it just makes more work on the backend20:11
kgriffsLet me just touch real quick on why /messages20:11
wkharoldyes please20:11
*** vipul is now known as vipul|away20:11
kgriffsWell, the backend needs to somehow validate whatever it's given anyway, IMHO, and re SQL injection or whatever, it can just be stored as an opaque blob.20:11
treederon the way back, it has to be marshalled back into json though20:12
kgriffsThe reason for the extra namespace is that it lets us add things like /actions and /stats20:12
kgriffsWell, depends on how you are constructing the JSON20:12
treederi gotta run, good meeting guys.20:13
kgriffsIf you are using, e.g., dumps then yes, that's true20:13
kgriffsk20:13
treedergood progress!20:13
kgriffsthx for the feedback20:13
cppcabreraTake care, treeder.20:13
wkharoldOK ... if there are additional resources coming OK20:13
kgriffsyeah20:13
kgriffsit makes it consistent20:13
kgriffsOnce we take a full pass through the spec, we can loop back to the top and see how everything looks in context.20:14
flaper87makes sense20:14
kgriffsSo, next week let's continue going down the list of each action in the spec20:14
flaper87+120:14
cppcabrera+120:14
*** treeder has quit IRC20:15
ametts-atlWe switching back to weekly meetings?20:15
flaper87great meeting guys20:15
flaper87thx folks20:15
kgriffsRelated: Falcon is coming along nicely. Check it out and let me know what you think.20:15
kgriffshttps://github.com/racker/falcon20:15
kgriffsThanks everyone.20:15
cppcabreraI'll keep the Trello up to date.20:15
kgriffs#endmeeting20:15
*** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack"20:15
openstackMeeting ended Thu Feb  7 20:15:54 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:15
openstackMinutes:        http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-07-19.01.html20:15
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-07-19.01.txt20:15
openstackLog:            http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-07-19.01.log.html20:15
cppcabrerameetbot is pretty sweet.20:16
kgriffsP.S. - I'll be here next week if anyone wants to come, although we officially don't meet every week. :D20:17
cppcabreraI'll be joining in, too. I'm interested in watching the Marconi project evolve.20:17
cppcabreraI'm out. Good meeting, everyone. :)20:21
*** cppcabrera has left #openstack-meeting-alt20:21
*** vipul|away is now known as vipul20:22
*** cp16net is now known as cp16net|away20:23
*** cp16net|away is now known as cp16net20:24
*** carimura has quit IRC20:27
*** jcru has joined #openstack-meeting-alt20:28
*** ametts-atl has left #openstack-meeting-alt20:34
*** kgriffs has quit IRC20:36
*** vipul is now known as vipul|away20:37
*** kgriffs has joined #openstack-meeting-alt20:45
*** joe5081 has joined #openstack-meeting-alt21:02
*** jcru has quit IRC21:04
*** kgriffs has quit IRC21:04
*** jcru has joined #openstack-meeting-alt21:08
*** kaganos has joined #openstack-meeting-alt21:10
*** kaganos has quit IRC21:12
*** wkharold has left #openstack-meeting-alt21:14
*** kgriffs has joined #openstack-meeting-alt21:17
*** cp16net is now known as cp16net|away21:20
*** cp16net|away is now known as cp16net21:21
*** vipul|away is now known as vipul21:34
*** kaganos has joined #openstack-meeting-alt21:35
*** amyt has quit IRC21:44
*** amyt has joined #openstack-meeting-alt21:47
*** cloudchimp has quit IRC21:56
*** esp has joined #openstack-meeting-alt22:00
*** esp has left #openstack-meeting-alt22:00
*** amyt has quit IRC22:11
*** amyt has joined #openstack-meeting-alt22:11
*** kgriffs has quit IRC22:25
*** kgriffs has joined #openstack-meeting-alt22:25
*** DandyPandy has quit IRC22:36
*** rnirmal has quit IRC22:48
*** kaganos has quit IRC22:53
*** kgriffs has quit IRC22:56
*** robertmyers has joined #openstack-meeting-alt23:15
*** vipul is now known as vipul|away23:16
*** vipul|away is now known as vipul23:16
*** robertmyers has quit IRC23:20
*** DandyPandy has joined #openstack-meeting-alt23:27
*** sacharya has quit IRC23:28
*** vipul is now known as vipul|away23:31
*** vipul|away is now known as vipul23:40
*** Zin|Gone has joined #openstack-meeting-alt23:45
*** jcru has quit IRC23:48

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