Wednesday, 2013-04-10

*** rmohan has quit IRC00:05
*** rmohan has joined #openstack-meeting-alt00:07
*** sarob has quit IRC00:21
*** rmohan has quit IRC00:37
*** rmohan has joined #openstack-meeting-alt00:38
*** dhellmann is now known as dhellmann-away00:45
*** jcru is now known as jcru|away01:07
*** jcru|away is now known as jcru01:11
*** cp16net has quit IRC01:23
*** cp16net_ has joined #openstack-meeting-alt01:24
*** cp16net_ is now known as cp16net01:24
*** cp16net is now known as cp16net|away02:00
*** cp16net|away is now known as cp16net02:01
*** cp16net is now known as cp16net|away02:01
*** cp16net|away is now known as cp16net02:02
*** jcru is now known as jcru|away02:15
*** rmohan has quit IRC02:17
*** jcru|away is now known as jcru02:17
*** rmohan has joined #openstack-meeting-alt02:17
*** sdague has quit IRC02:52
*** SergeyLukjanov has joined #openstack-meeting-alt03:10
*** sdague has joined #openstack-meeting-alt03:12
*** bdpayne has quit IRC03:17
*** cyli has joined #openstack-meeting-alt03:46
*** SergeyLukjanov has quit IRC03:55
*** SergeyLukjanov has joined #openstack-meeting-alt04:00
*** amyt has joined #openstack-meeting-alt04:25
*** SergeyLukjanov has quit IRC04:43
*** SergeyLukjanov has joined #openstack-meeting-alt04:44
*** SergeyLukjanov has quit IRC05:03
*** amyt has quit IRC05:12
*** dmitryme has joined #openstack-meeting-alt05:25
*** dmitryme has quit IRC05:56
*** aignatov3 has joined #openstack-meeting-alt06:54
*** aignatov3 has quit IRC07:26
*** SergeyLukjanov has joined #openstack-meeting-alt07:26
*** SergeyLukjanov has quit IRC08:16
*** SergeyLukjanov has joined #openstack-meeting-alt09:23
*** dhellmann-away is now known as dhellmann10:56
*** dhellmann is now known as dhellmann-away11:18
*** SergeyLukjanov has quit IRC11:43
*** SergeyLukjanov has joined #openstack-meeting-alt11:44
*** dhellmann-away is now known as dhellmann12:14
*** rnirmal has joined #openstack-meeting-alt12:34
*** SergeyLukjanov has quit IRC12:46
*** SergeyLukjanov has joined #openstack-meeting-alt12:50
*** SergeyLukjanov has quit IRC13:36
*** SergeyLukjanov has joined #openstack-meeting-alt13:50
*** mtreinish has joined #openstack-meeting-alt13:52
*** cloudchimp has joined #openstack-meeting-alt13:59
*** sergmelikyan has quit IRC14:06
*** HenryG has quit IRC14:11
*** SergeyLukjanov has quit IRC14:12
*** jcru has joined #openstack-meeting-alt14:13
*** SergeyLukjanov has joined #openstack-meeting-alt14:15
*** SergeyLukjanov has quit IRC14:30
*** HenryG has joined #openstack-meeting-alt14:37
*** amyt has joined #openstack-meeting-alt14:43
*** jcru is now known as jcru|away14:46
*** markwash has quit IRC14:47
*** cp16net is now known as cp16net|away14:50
*** cp16net|away is now known as cp16net14:50
*** cp16net is now known as cp16net|away14:51
*** jcru|away is now known as jcru15:02
*** SergeyLukjanov has joined #openstack-meeting-alt15:16
*** bdpayne has joined #openstack-meeting-alt15:22
*** sacharya has joined #openstack-meeting-alt15:27
*** cp16net|away is now known as cp16net15:34
*** dhellmann is now known as dhellmann-away15:34
*** sarob has joined #openstack-meeting-alt16:09
*** dmitryme has joined #openstack-meeting-alt16:22
*** SergeyLukjanov has quit IRC16:31
*** dmitryme2 has joined #openstack-meeting-alt16:34
*** dmitryme has quit IRC16:34
*** dhellmann-away is now known as dhellmann16:45
*** SergeyLukjanov has joined #openstack-meeting-alt16:52
*** markwash has joined #openstack-meeting-alt17:04
*** esp1 has joined #openstack-meeting-alt17:08
*** esp1 has left #openstack-meeting-alt17:11
*** SergeyLukjanov has quit IRC17:22
*** SergeyLukjanov has joined #openstack-meeting-alt17:28
*** cp16net is now known as cp16net|away17:45
*** cp16net|away is now known as cp16net17:45
*** cp16net is now known as cp16net|away17:45
*** esp1 has joined #openstack-meeting-alt17:51
*** esp1 has left #openstack-meeting-alt17:52
*** dmitryme2 has quit IRC17:53
*** cp16net|away is now known as cp16net18:04
*** sarob has quit IRC18:10
*** sarob has joined #openstack-meeting-alt18:26
*** amyt has quit IRC18:26
*** amyt has joined #openstack-meeting-alt18:26
*** rmohan has quit IRC18:30
*** SergeyLukjanov has joined #openstack-meeting-alt18:30
*** flaper87 has joined #openstack-meeting-alt18:31
*** rmohan has joined #openstack-meeting-alt18:31
*** eglynn has joined #openstack-meeting-alt18:49
*** esheffield has joined #openstack-meeting-alt18:56
markwashlooks like we have some glance folks around?19:00
iccha_aye aye!19:00
flaper87o/19:00
*** jbresnah has joined #openstack-meeting-alt19:00
iccha_o/19:00
jbresnahwave19:00
nikhilack19:00
ameade+119:00
markwash#startmeeting glance19:01
openstackMeeting started Wed Apr 10 19:01:00 2013 UTC.  The chair is markwash. 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: glance)"19:01
openstackThe meeting name has been set to 'glance'19:01
markwashSo, I didn't really lay out the agenda in the wiki19:01
markwashbut the rough idea from my perspective is: follow up on caching discussion, more summit topic discussion, and more blueprint triage19:02
flaper87+119:02
brianr-g1ne+119:02
markwashbut anybody else who has important topics feel free to throw them out now, we can work them in19:02
ameadei want more code reviews19:02
markwashah, I've got a quick note on that19:03
markwash#topic review and bug squashing days19:03
*** openstack changes topic to "review and bug squashing days (Meeting topic: glance)"19:03
flaper87w00000t19:03
markwashlast meeting flaper87 suggested we have bug squashing days19:03
markwashthen privately made the suggestion that we ought to have review squashing as well19:04
markwashwhich struck me as even more critical, as it seems19:04
*** brianr-g1ne is now known as rosmaita19:04
iccha_is there a glance openstack room? where we can all discuss and coordinate during these days?19:04
markwashI know I haven't been doing enough review lately :-( sorry folks19:04
markwashI don't believe so, but we could make one19:04
flaper87openstack-glance19:04
ameade+1 on both types of squash19:04
markwashany thoughts on when we should have the first one? week after the summit?19:05
ameadei saw that last meeting the concern was that we dont have enough bugs19:05
jbresnahI agree with the review days for sure19:05
flaper87that sounds ok, the week after the summit19:05
ameadeso maybe we just have a "squash" day and do both? i dont want reviews to wait til squash days though19:05
jbresnahbug squash sounds good too, tho that is something that could end up being more async for people19:05
flaper87the suggestion was to have them together19:06
markwashameade: agreed, we shouldn't put them off until squash day19:06
iccha_+1 that19:06
markwashyeah, one day for both as needed19:06
flaper87starting with the one in worse shape19:06
nikhil+119:06
markwash#agreed have a shared review/bug squashing day during the week after the summit19:06
ameadewould it be more effective to have constant reviews if we do the traditional core review days where a core is assigned to a day?19:07
markwashameade: I think we should have constant reviews regardless of squashing days19:07
markwashameade: and I hope we aren't at a point where we need review days like nova19:07
ameademarkwash: yeah i dont think we are that bad19:07
*** ashwini has joined #openstack-meeting-alt19:08
ameadei agree, lets just try out the squash days and if we need more than that we will revaluate19:08
markwash#action markwash schedule a squash day during the week after the summit19:08
flaper87I think we should review daily and that review days should be used as a speed up on reviews and "shared reviews" day19:08
markwash++19:08
ameade+119:08
nikhilagree19:08
iccha_+119:08
nikhil+119:08
iccha_approved :p19:08
markwashany other thoughts on reviews?19:08
markwash#topic glance caching19:09
*** openstack changes topic to "glance caching (Meeting topic: glance)"19:09
markwashlast week we talked about new approaches to managing cache19:09
markwashjbresnah has posted his ideas about future approaches to caching here https://tropicaldevel.wordpress.com/2013/04/09/free-cache/19:10
ameadedid we decide to not have a summit session on this?19:10
markwashI'm not sure that we decided, but one was not proposed19:11
markwashI do feel like we could work out a reasonable solution outside of the summit, however19:11
* flaper87 wont be at the summit :(19:12
nikhilso, this seems to be something that could be benefitial to discuss before exposing glance19:12
nikhilwould help on some design decisions19:12
nikhilthoughts?19:12
iccha_should caching not work almost the same way either glance is exposed or not?19:13
jbresnahI am not sure what exposed means here exactly...19:13
nikhilfrom the previous meeting logs, looks like locations is something discussed19:14
iccha_jbresnah: it refers to being able to use glance directly19:14
iccha_as an independent service19:14
nikhilmy bad, it mean glance as a public deployment19:14
jbresnahoh right, sorry i forgot that in some places it is not public, thanks.19:14
jbresnahi think that multiple locations is a big part of the cache19:14
jbresnahnikhil: so i agree locations is something to discuss19:15
nikhiljbresnah: on the similar note19:15
nikhilif we decide on multiple locations and related glance cache19:15
markwashone thing I would note, is that with jbresnah's proposal, can we still keep the local cached copies urls hidden from regular users? if not I worry about exposing individual nodes to targeted dos attacks19:16
jbresnahi think you can19:16
iccha_we could have additional way to indicate provate urls maybe?19:16
jbresnahin one sense glance api becomes another user of the relica catalog19:16
flaper87I think it is important to be able to scale out cache instances19:16
markwashcool, wanted to make sure that wasn't antithetical19:16
jbresnahso, if a user goes to download an image from glance, glance looks at the catalog and chooses the best location19:17
jbresnahthen streams it19:17
markwashflaper87: yes, in general you had other ideas for how we might approach caching19:17
jbresnahif the locations are exposed to an end user, then can make that decisions19:17
markwashflaper87: any code or docs for us to look at?19:17
jbresnahif not glance can make it internally and then stream it19:17
jbresnahi agree that horizontal scalability is crucial19:18
jbresnahi hope i have not spoken against that19:18
flaper87markwash: I was writing it and then I thought that it should exist along the lines of what jbresnah proposed. The idea would be to use the multi-location implementation for caches so that cached images would be just a new location for an existing image but under a dedicated API.19:18
nikhiljbresnah: guess not, rather proved a thought on how to achieve this19:19
flaper87that will allow us to just disable glance-api paths and have instances dedicated just for caches19:19
nikhils/proved/provoked/19:19
jbresnahthe original problem was here was to deal with a cache management service19:19
jbresnahclearing the cache, listing images in it etc19:19
jbresnahi think that all of the problems there will also be in maintaining the consistency of multiple locations19:20
jbresnahso we should solve the multiple locations issue and accept the cache issue as a lesser included19:20
nikhili guess that is a challenge by itself19:20
markwashthat is interesting, and we do need some motivation for the multiple locations api19:21
nikhilthat's the reason why i wished to include public glance in this discussion19:21
nikhilbasically, maintaining consistency would be an issue19:21
markwashI don't know about everybody else, but I'd like a little more time to think on this, and we can certainly discuss it more over libations at the summit (those who can attend)19:22
nikhilmarkwash: we'r hoping to have the same uuid for copied/cache image to other location19:22
iccha_jbresnah: do you envision cache management being a sepaarte servoce?19:22
ameade+1 libations19:22
nikhilmarkwash: sure19:22
jbresnah+1 libations19:22
jbresnahiccha_: perhaps19:23
jbresnahor a tool19:23
*** rnirmal_ has joined #openstack-meeting-alt19:23
*** rnirmal_ has quit IRC19:23
jbresnahit gets complicated because issues come up like: Does the user who registered the replicated image deligate delete rights to the service19:23
* markwash searches for an action item. . . 19:23
jbresnahetc19:23
markwashhmm, interesting19:23
jbresnahthere are some other interesting bits that come out of it too that we can discuss when appropriate19:24
jbresnahfor example: nova-compute could register a local replica instead of maintaining its own cache19:24
jbresnahtho, that could be out of scope also19:24
jbresnahjust a use case example really19:24
*** rnirmal has quit IRC19:24
nikhiljbresnah: very interesting19:24
jbresnahmy main point is this:19:24
nikhilmay be a pluggable, though19:25
jbresnahmultiple-locations makes glance a replica service19:25
jbresnaha copy on a local disk is just another replica19:25
jbresnahspecial case code will cause complications19:25
jbresnahnod pluggable19:25
markwashvery thought provoking19:25
markwashhmm19:26
ameade+1 to an image living anywhere just being another location19:26
iccha_do we see this tying into image cloning?19:26
nikhiljbresnah: don't wanna go off topic, though one thing that stikes me is local copy is not at a known state and a snapshot on that is a different image (looks like deeper issue, may be?)19:26
flaper87iccha_: I kind of think it like that19:26
jbresnahnikhil: i may not follow, but if the checksum changes it is no longer a replica19:27
nikhilkk19:27
markwashI'm a little worried about scope creep here19:27
nikhilmay be i on a different thought train :)19:28
flaper87again, I think it is important to be able to scale that out and being able to identify which images are indeed a cached image and which not.19:28
ameadeimages shouldnt go stale anyways, they dont change?19:28
*** vipul is now known as vipul|away19:28
*** vipul|away is now known as vipul19:28
jbresnahthe issue about datasets changing is exactly why we will need some sort of consistency management with multiple locations19:29
jbresnahwhich feeds into my point about that feature subsuming cache management19:29
jbresnahi think for the purpose of this conversation the replicas are blogs of data, not images19:30
jbresnahtho i could definitely be missing critical info there19:30
flaper87another thing that we might also want to consider is being able to have some auto-caching algorithms19:30
markwashso for next steps here19:31
jbresnahflaper87: perhaps that is true, but i think that is a future feature wrt the conversation here19:31
jbresnahflaper87: but a good feature nonetheless19:31
nikhil+119:31
markwashI here a lot of interesting ideas, but maybe we need someone to synthesize these into some smaller concrete proposals for next steps?19:31
markwash*ehar19:31
markwash*hear19:31
markwashthere we go19:31
jbresnahi think the first step is to see the current multiple-locations effort through19:32
ameade+119:32
jbresnahand i would suggest that we stall the cache effort until then19:32
nikhil+119:32
jbresnahsee exactly what is needed at the end of that19:32
flaper87+1, once that's done we could talk about how to replicate it19:32
markwashsounds good19:32
nikhilmarkwash: besides the proposed topic for glance at the summit, whay else would you like to discuss?19:33
nikhil*topics19:33
markwashlets' leave caching off here, and move on to glance design summit topics19:33
jbresnahsounds good19:33
iccha_sounds good19:33
markwashall I have left is summit topics in general (which is probably a big talk) and then just blueprint triage19:33
iccha_https://wiki.openstack.org/wiki/Summit/Havana/Etherpads is the wiki page for etherpads for summit sessions19:34
markwashbut I'd be happy to leave off blueprint triage for other topics of interest19:34
markwash#topic glance summit sessions19:34
*** openstack changes topic to "glance summit sessions (Meeting topic: glance)"19:34
markwash3 sessions have been selected and scheduled so far19:34
markwash#link http://openstacksummitapril2013.sched.org/overview/type/design+summit/Glance#.UWWzb6tg_5819:34
markwashthat leaves 2 sessions left to schedule19:35
markwashand one of the topics we have to hit relates to http://summit.openstack.org/cfp/details/4719:35
iccha_i see only 2 sessions unreviewed19:35
markwashbut possibly more generally just image upload/download performance19:35
markwashand nova boot performance19:36
markwashimproving image transfer performance is a big topic, so I'm wondering 1) should it be split into two? 2) does anyone have any interest in rolling db migrations?19:36
rosmaitamarkwash: we definitely are interested in rolling db migrations19:37
iccha_+119:37
nikhilmarkwash: we'r also interested in interoperability/inter hypervisor compatibility as well19:37
ameadelets just unconference everything :)19:37
nikhil+119:37
markwashso splitting the performance topic into two sessions would come at some cost19:37
markwashI have a summit pitch about performance that I'd love to make now19:38
jbresnahcool19:39
jbresnahi would like to hear that pitch19:39
rosmaitawe are all ears19:39
flaper87go go go19:39
markwashtake this as a straw man if you like19:39
markwashbut I propose that Glance should not be worried about performance19:39
markwashat least not directly19:39
markwashGlance should concern itself with exposing the information that other performance-oriented clients need in order to work efficiently19:40
*** rnirmal has joined #openstack-meeting-alt19:40
ameade+119:40
jbresnahthat sounds right to me19:40
flaper87+119:40
markwashmost of the proposals that I've seen say:19:40
markwashIf we make images X, then we can have nova do Y, which is faster19:40
markwashwell, never mind that last train of thought. . not sure where it was going to derail19:41
ameadebut dont forget about glance being a 1st class API19:41
nikhil+119:41
ameadewe still need glance to do transfers at some level right?19:41
rosmaitaand i believe caching is done for performance improvements?19:42
nikhiltransfers and sync too19:42
markwashThis behavior feels kind of like legacy compatibility to me19:43
jbresnahI would like to couple resource management with transfer performance19:43
*** vipul is now known as vipul|away19:43
jbresnahwhen consoidering going super fast you have to consider resource usage19:43
jbresnahand how that effects others19:43
jbresnahalso i would like to add that as glance stands right now it cannot make proper decisions about either19:44
jbresnahbecause it is only on 1 side of the transfer19:44
markwashjbresnah: but if glance isn't concerning itself with those things, the responsibility for managing resource usage would be elsewhere. . glance isn't any side of the transfer19:44
jbresnahmarkwash: oh yeah +1 that19:44
flaper87I think glance should be more worried about knowing more from images than knowing more about improving performances19:45
ameadeI'd really like to see glance taken out of actual transfers and maybe just negotiate transfers?19:45
iccha_it boils down to what is the purpose of glance and what we want it to be once is it is public19:45
markwashyeah19:45
markwashiccha_: +119:46
markwashso glance didn't originally exist alongside nova19:46
nikhillooks like everyone wants to decouple the glance and image data management service19:46
jbresnahI love this convoersation so far19:46
markwashit was created because public clouds didn't want people to be able to boot just anything, since all the broken nova boots would cause a support nightmare19:46
markwashit was also created as a central place to manage image data, however, since swift isn't really up to the challenge19:47
markwashI think we should figure out a way to formally adopt the former purpose as something like a mission statement19:47
*** vipul|away is now known as vipul19:48
* markwash is really out on a limb here19:48
flaper87I agree19:48
jbresnahi am with you19:48
jbresnahin a past life i worked on grid computing.... i will save the details for when beer is near by...19:48
markwashand help out other projects so that we can move away from the latter purpose19:48
jbresnahbut to me it makes sense to have replica management and data transfer as separate things19:48
jbresnahtho i do understand the convenience of coupling them as well19:49
markwashjbresnah: I think it makes sense to keep track of different replicas, yes, assuming it is useful to keep multiple replicas of the same thing19:49
markwashwhich seems likely19:49
markwashwow, I've gotten kind of far from what I meant to do19:50
jbresnahmarkwash: replica might be too strong for me to be using, perhaps 'registry' is better19:50
iccha_Yeah its a different thing maintaining info about replicas vs transfering them or making the replicas19:50
ameadelets not get into redefining Glance maybe?19:50
markwashgoing back to the summit topic, I guess the default option is to make a "booting and snapshotting, download and upload performance" session19:50
markwashand approve the db rolling upgrades session19:51
iccha_sounds good19:51
ameade+119:51
iccha_+119:51
flaper87+119:51
markwashjbresnah: one session is not a lot of time19:51
jbresnahnod, i will try not to talk too much19:51
markwashjbresnah: lol, not what I was trying to suggest :-)19:52
iccha_we can try doing a glance grab a beer/dinner/coffee thing during the summit too19:52
jbresnahheh19:52
jbresnahmost of my thinking is on my blog (i think)19:52
ameades/beer/beers/19:52
markwashthere are also some folks who will want to talk about volumes as images19:52
iccha_ah yeah thats always been there19:52
ameademarkwash: can we ignore them?19:52
ameadelol19:52
jbresnahheh19:52
flaper87:P19:53
markwashwell, we can, but perhaps at our peril19:53
jbresnahi was also thinking of proposing a 'unconference' topic on an image transfer sercice19:53
jbresnahcould get time that way i suppose19:53
iccha_yeah unconferences are a good way to do that19:53
markwashzhiyan and IBM have an amazingly fast provisioning system they have built on top of volume-like abstractions, and want to expose that in openstack19:53
jbresnahthis is my first summit tho, so i may not have the culture quite right19:53
iccha_yeah i think i see a glance-cinder-driver blueprint too19:54
jbresnahmarkwash: can you point me at more details on that?19:54
markwashjbresnah: I will have to find a link19:55
rosmaitawell, having glance not transfer any image data would definitely improve its performance19:55
* nikhil is having a hard time finding out action item for this except for a philosophical discussion with glance folks19:55
nikhildeadlock?19:55
markwashrosmaita: :-)19:55
ameadeyeah i'm actually pretty excited about boot from volumes and stuff19:55
markwashas far as action items, I'm pretty sure the boot-from-volume stuff needs session time19:55
flaper87will all this be recorded, written, G+ ?19:56
markwashso I'll check the other topics to see if its sufficiently covered19:56
flaper87I'd love to participate somehow and catch up with everything that happens at the summit19:56
markwashand if not I'd like to boot the rolling db upgrades to an unconference19:56
iccha_flaper87: we will take notes19:56
flaper87iccha_: :D thank you so much!19:56
nikhilflaper87: they would be live streaming these sessions as well, i hope19:57
ameadeflaper87: I know they said they weren't gonna stream sessions but maybe enough people were unhappy about that and they changed their minds19:57
markwash#action markwash finish scheduling the summit sessions asap19:57
iccha_flaper87: https://wiki.openstack.org/wiki/Summit/Havana/Etherpads has etherpad links for summit sessions19:57
markwash#topic open discussion19:57
*** openstack changes topic to "open discussion (Meeting topic: glance)"19:57
markwashsorry I wandered so far afield today folks19:57
jbresnahi enjoyed it :-)19:58
ameademarkwash: just pretend that's what you meant to do :P19:58
flaper87ahhahaa19:58
markwashlol19:58
ameadei'm really hyped for the summit19:58
ameadegonna be a doosey19:58
iccha_i am glad we re having glance meetings :) and we all should try hanging out in the openstack-glance channel flaper87 mentioned19:58
markwashflaper87: I'll make sure we keep use the etherpads as much as possible during the summit19:58
nikhil+119:59
flaper87markwash: thank you, I'm really sad I wont be there! :(19:59
flaper87Notes will be really useful for catching up19:59
flaper87and commenting20:00
markwashthere was some mention of irc being used during the meetings20:00
markwashnot sure how well that would work, but if anyone has any ideas we could give it a try20:00
ameadewe could always google hangout20:00
markwashthe problem with AV solutions is that the A always sucks20:00
ameadewe appear to be out of time...20:01
markwashindeed20:01
markwash#endmeeting20:01
*** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack"20:01
flaper87awesome meeting guys20:01
openstackMeeting ended Wed Apr 10 20:01:18 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-04-10-19.01.html20:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-04-10-19.01.txt20:01
openstackLog:            http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-04-10-19.01.log.html20:01
nikhil+120:01
*** esheffield1 has joined #openstack-meeting-alt20:01
markwashthanks everybody20:02
jbresnahthank you!20:02
flaper87cheers!20:02
*** esheffield has quit IRC20:04
*** rmohan has quit IRC20:07
*** rmohan has joined #openstack-meeting-alt20:07
*** rmohan has quit IRC20:09
*** rmohan has joined #openstack-meeting-alt20:09
*** Yi_ has joined #openstack-meeting-alt20:09
*** cp16net is now known as cp16net|away20:14
*** cp16net|away is now known as cp16net20:15
*** cloudchimp has quit IRC20:18
*** Yi_ has quit IRC20:31
*** markwash_ has joined #openstack-meeting-alt20:40
*** cp16net is now known as cp16net|away20:40
*** markwash has quit IRC20:42
*** markwash_ is now known as markwash20:42
*** SergeyLukjanov has quit IRC20:47
*** cp16net|away is now known as cp16net20:51
*** zzs has joined #openstack-meeting-alt21:04
*** flaper87 has left #openstack-meeting-alt21:20
*** ashwini has quit IRC21:29
*** zzs has left #openstack-meeting-alt21:37
*** jcru is now known as jcru|away21:42
*** jcru|away is now known as jcru21:47
*** rnirmal has quit IRC21:52
*** jcru has quit IRC22:01
*** sacharya has quit IRC22:03
*** esp1 has joined #openstack-meeting-alt22:04
*** mtreinish has quit IRC22:11
*** esp1 has left #openstack-meeting-alt22:24
*** sarob has quit IRC23:02
*** markwash has quit IRC23:24
*** HenryG_ has joined #openstack-meeting-alt23:37
*** HenryG has quit IRC23:40

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