Monday, 2016-05-23

*** markvoelker has joined #openstack-meeting-cp00:24
*** markvoelker_ has joined #openstack-meeting-cp00:25
*** markvoelker has quit IRC00:29
*** markvoelker_ has quit IRC00:30
*** notstevemar is now known as stevemar01:57
*** Niham has joined #openstack-meeting-cp04:52
*** sheel has joined #openstack-meeting-cp05:21
*** sigmavirus24_awa has quit IRC05:27
*** belmoreira has joined #openstack-meeting-cp06:43
*** ttx has quit IRC06:56
*** ttx has joined #openstack-meeting-cp06:57
*** bauzas has joined #openstack-meeting-cp07:02
*** sdake_ has quit IRC08:10
*** sdake has joined #openstack-meeting-cp08:11
*** vgridnev has quit IRC09:14
*** vgridnev has joined #openstack-meeting-cp09:19
*** Niham has quit IRC09:26
*** _amrith_ is now known as amrith10:04
*** amrith is now known as _amrith_10:33
*** Niham has joined #openstack-meeting-cp10:40
*** sdague has joined #openstack-meeting-cp10:46
*** pgreg has joined #openstack-meeting-cp10:54
*** sdake has quit IRC11:04
*** Niham has quit IRC11:04
*** _amrith_ is now known as amrith11:14
*** pgreg has quit IRC12:49
*** sigmavirus24 has joined #openstack-meeting-cp13:12
*** piet has joined #openstack-meeting-cp13:23
*** xyang1 has joined #openstack-meeting-cp13:30
*** belmoreira has quit IRC13:32
*** sheel has quit IRC13:35
*** sdake has joined #openstack-meeting-cp13:56
*** sdake_ has joined #openstack-meeting-cp14:00
*** sdake has quit IRC14:02
*** belmoreira has joined #openstack-meeting-cp14:17
*** sheel has joined #openstack-meeting-cp14:20
*** superdan is now known as dansmith14:32
*** sdake_ has quit IRC14:38
*** markvoelker has joined #openstack-meeting-cp14:56
*** sdake has joined #openstack-meeting-cp14:59
*** amrith is now known as _amrith_15:15
*** piet has quit IRC15:20
*** belmoreira has quit IRC15:39
*** xyang1_ has joined #openstack-meeting-cp16:12
*** xyang1 has quit IRC16:13
*** xyang1_ is now known as xyang116:13
*** xyang1 has quit IRC16:17
*** xyang1 has joined #openstack-meeting-cp16:17
*** geguileo has joined #openstack-meeting-cp16:50
ildikov#startmeeting cinder-nova-api-changes17:00
openstackMeeting started Mon May 23 17:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.17:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
*** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)"17:00
openstackThe meeting name has been set to 'cinder_nova_api_changes'17:00
ildikovscottda ildikov DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis17:00
scottdaHi17:00
scottdaildikov: Just pinged you in Cinder :)17:00
ildikovscottda: :)17:00
geguileoHi17:01
patrickeasthi17:01
ildikovI started to answer there, but then I switch to this channel17:01
hemnahey17:01
hemnais this our meeting slot now?17:02
hemnaI can't keep it straight17:02
ildikovhemna: yes :)17:02
hemnaseems to change every week17:02
ildikovhemna: sorry for the many variations17:02
hemnanah it's cool.17:02
hemna:)17:02
*** piet has joined #openstack-meeting-cp17:02
ildikovhemna: last week's slot was meant to be the one, but then it turned out we don't have a channel for that slot anymore...17:02
hemnacoolio17:03
ildikovhemna: and next week Monday is a US holiday, so we need to find another slot or sync up separately...17:03
hemnaso do we have an agenda today?17:03
ildikovI hope we have jgriffith around17:03
ildikovto discuss his part as I haven't seen patches from him but I might missed it17:03
hemnaman that'd be great to see that patch(s)17:04
ildikovhemna: I also checked check_attach a bit last week17:04
ildikovand I found that in case of attaching a volume at boot time Nova does not call reserve_volume17:04
hemnaw t f17:05
hemnaseriously?17:05
patrickeastlol17:05
hemnaugh, lets follow that up17:05
hemnathat needs to get fixed asap17:05
ildikovI raised an exception from the reserve call and attach at boot time went through and then detach and the attach after that failed there17:05
ildikovI mean I had this dumb way of testing, but anyway, the point is the same17:06
hemnayah17:06
ildikovI think if we can have that fixed than check_attach can be removed from there too17:06
ildikovs/than/then/17:06
ildikovmaybe where they call check_attach first we can call reserve volume there17:07
ildikovlet's follow that up after the meeting17:07
hemnahttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L128817:07
hemnathat's the one I thought should be changed to a reserve_volume call17:08
hemnaI haven't tried it yet though17:08
ildikovyeah, I meant this one17:08
ildikovI think this method is called only in that flow17:08
hemnain the boot from volume flow ?17:08
ildikovyeap17:08
ildikovotherwise they just call attach and that creates the BDM17:09
hemnaok, so do you think I should try the same thing I did here: https://review.openstack.org/#/c/315789/ ?17:09
ildikovhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L310117:09
ildikovthat and also call reserve_volume17:10
hemnaildikov, so for that one, my patch changes it already17:10
ildikovas otherwise no one will17:10
hemnahttps://review.openstack.org/#/c/315789/2/nova/compute/api.py17:10
ildikovright, I meant that for other attach cases this method is called here, but for boot from volume they use the _validate_bdm, etc17:11
hemna*smh*17:11
hemnaok, so at some point in the boot from volume workflow there has to be a call to initialize_connection and attach17:12
ildikovregarding the reserve call, I would guess we need to check that what if anything goes wrong, I did not analyse the full call sequence...17:12
hemnaI'll see if I can track those down17:12
ildikovI didn't look for initialize_connection, next time I will be smarter17:13
hemnaI can't comprehend why nova has copy/paste code for doing the same operation.17:13
hemnamind boggling17:13
ildikovdo you have any other case I should check?17:13
ildikovagreed, good that we're doing some cleanup17:13
ildikovso normal attach has reserve, live migration is a special case anyway17:14
*** sdake has quit IRC17:15
hemnahttp://paste.openstack.org/show/498223/17:15
hemnathat's the entire list of check_attach references17:15
hemnafwiw17:15
hemnalots of tests referencing it17:15
hemnaanyway, I'll try testing my patch against he boot from volme and modify the check_attach case there to call check_availability_zone and reserve_volume instead17:16
ildikovthere is a fake check_attach code as well, which is the copy of the normal basically17:16
hemnaand see how that goes17:16
ildikovthat code is a nightmare17:16
johnthetubaguy+1 to the above comments, that seems crazy17:17
hemnacheck_attach should go away IMHO17:17
johnthetubaguywhere is the cut and paste again?17:17
ildikovI meant line 33 for my previous comment17:17
* johnthetubaguy reads more of scrollback17:17
*** sdake has joined #openstack-meeting-cp17:17
hemnahttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L1287-L129117:17
hemnahttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L3097-L309917:18
hemnathose should be the same thing IMHO17:18
hemnabut should be changed to....17:18
ildikovjohnthetubaguy: the base of this discussion is that the BFV case with existing Cinder volume does not call reserve_volume17:18
hemnahttps://review.openstack.org/#/c/315789/2/nova/compute/api.py17:18
hemnathat17:18
johnthetubaguyah...17:18
ildikovso we thought to add that missing call and also remove check_attach from there as well17:20
johnthetubaguya new method in volume_api to do those calls?17:20
hemnapossibly yah17:20
hemnaI had thought of refactoring those 2 into a single place17:20
hemnaif all goes well :)17:20
johnthetubaguyyeah, that makes sense17:21
johnthetubaguyseems like reserve and check should always both we done?17:21
hemnapossibly17:21
hemnalive migration is a special case though17:21
hemna:(17:21
johnthetubaguyoh, true17:22
*** sdake has quit IRC17:22
johnthetubaguyits always a special case17:22
johnthetubaguythats why its so dammed broken17:22
hemnayup17:22
hemnapain17:22
hemnaok so baby steps17:22
ildikovbut in general the less state check in Nova is the better17:22
hemnaildikov, +117:22
ildikovand use reserve what it's for17:23
johnthetubaguyyeah, +117:23
ildikovdo we have any other special case like live migration?17:23
hemnaI'm shocked that BFV doesn't use reserve17:23
ildikovor it's the only, but big monster?17:23
hemnaI'd like to confirm that17:23
ildikovI haven't checked how it is done when Nova creates the volume17:23
johnthetubaguyso I wonder if we should get you lovely cinder folks to write a very quick doc on how we *should* use your API? we could put that in our devref thingy?17:23
scottdaildikov: I think we need to look at shelve_offload, as cinder state if fudged there as well.17:23
hemnaheh17:24
johnthetubaguyildikov: so migrate, and shelved, evacuate, resize17:24
ildikovjust add an exception to the client call and it will get through or I'm a magician...17:24
scottdajohnthetubaguy: That's a good idea.17:24
hemnaI think jgriffith created a nice blog about it and was working on a devref for it as well17:24
johnthetubaguythat would be prefect17:24
*** harlowja has joined #openstack-meeting-cp17:24
*** itisha has joined #openstack-meeting-cp17:25
ildikovjohnthetubaguy: migrate is live migrate or Cinder migrate there?17:25
johnthetubaguyso I think its when the server moves, we have issues17:25
johnthetubaguylet me find a doc on those, one second...17:25
hemnajohnthetubaguy, http://docs.openstack.org/developer/cinder/devref/attach_detach_conventions.html17:25
hemna:)17:25
johnthetubaguyhttp://developer.openstack.org/api-guide/compute/server_concepts.html17:25
johnthetubaguyhemna: ah, coolness, we might want to add something in the Nova docs, that just link to your doc :) but that might be overkill!17:26
ildikovhemna: nice, we could add a ref to your diagrams there as well17:26
hemnajohnthetubaguy, I think that'd be nice.17:26
johnthetubaguyso the api docs cover server moves, we have very silly names17:26
johnthetubaguylive-migrate is what you know17:26
johnthetubaguymigrate is cold migrate17:26
hemnaserver move = live migration ?17:27
johnthetubaguyi.e. turn it off, move it, turn it on17:27
johnthetubaguyyeah, live-migration is move the server, but with only a slight pause and no reboot17:27
ildikovjohnthetubaguy: yeah, right, I forgot you call it migrate as well, my bad :)17:27
johnthetubaguyyeah, live migrate and cold migrate is what we often call it now17:27
johnthetubaguynow we have dead parrot migrate (I totally just made that up)17:27
johnthetubaguyits called evacuate17:28
ildikovjohnthetubaguy: how much are these things tested?17:28
johnthetubaguywhen you host is dead, you need to move your server17:28
johnthetubaguyildikov: honestly, its a WIP17:28
johnthetubaguyildikov: migrate is OK, live-migrate is only tested in the experimental queue, we can't make it pass enough yet17:28
hemnais cold migrate = shelve/unshelve ?17:28
johnthetubaguynope17:28
hemnaok17:28
johnthetubaguylets do evacuate17:28
johnthetubaguyyour host is head17:29
johnthetubaguyyou can't get to it17:29
johnthetubaguyits in a skip17:29
johnthetubaguybut you want your VM back17:29
johnthetubaguyso you use evacuate17:29
johnthetubaguy(resurrect is another name we came up with, since we created that API call)17:29
johnthetubaguydoes that make any sense?17:29
hemnayah17:29
ildikovI know the operation17:29
hemnathanks :)17:29
johnthetubaguysweet17:29
ildikovbut what happens with the volume there?17:29
johnthetubaguyit gets re-attached on the destination host17:30
johnthetubaguywe don't have access to the old host to do anything there17:30
johnthetubaguywe technically share that code with rebuild17:30
ildikovbut then from volume perspective it's like a migrate?17:30
scottdaso volume does not need to be "reserved", i.e. set to attaching, it should already be attached and in-use17:30
johnthetubaguyI am not sure if we call terminate correctly17:30
johnthetubaguyildikov: kinda, yeah17:30
johnthetubaguyscottda: yeah, thats the key bit I guess17:31
johnthetubaguythe detach is harder, as we can't call os-brick on the old host, its dead17:31
hemnaso nova will call initialize_connection  on a new host then, when the volume is already 'in-use'17:31
scottdaand we don't want Nova to check the volume state, because it won't be correct for non-multi-attach case17:31
johnthetubaguyhemna: I think so17:31
hemnaok17:31
hemnayet another case where the connector information should be updated17:31
ildikovyeah, like migrate17:31
hemnaildikov, yup17:31
johnthetubaguyyeah, its very similar17:32
scottdajohnthetubaguy: Yes, detach won't work for Nova, we'll want to call cinder force-detach (which needs fixing after jgriffith patches)17:32
johnthetubaguyscottda: yeah, that sounds correct for evacuate (although wrong for rebuild/migrate)17:32
johnthetubaguywhich might be tricky, and rebuild and evacuate are mostly common code, but lets ignore that for now17:32
ildikovI just wanted to ask whether we could call force-detach :)17:33
johnthetubaguyhehe, I think we should be able to fix that17:33
scottdaildikov: Force detach won't work properly until Cinder saves the connector info...17:33
hemnascottda, +!17:33
scottdaWhich is will soon with jgriffith patches.17:33
hemna+117:33
johnthetubaguyscottda: +117:33
johnthetubaguycool beans, we should do shelved?17:33
ildikovscottda: right, I got it now :)17:33
johnthetubaguyso that migrate, with a really long pause, and possible a delete before the resume17:34
scottdajohnthetubaguy: Yes, please proceed with shelved :)17:34
johnthetubaguythe idea is this:17:34
ildikovjohnthetubaguy: please educate us :)17:34
johnthetubaguyuser wants to keep all their resources17:34
johnthetubaguybut they don't want to pay for compute resources when the instance isn't used17:34
johnthetubaguy(i.e. over night)17:34
johnthetubaguyand what a really quick resume, where possible, when they do want to use it17:34
johnthetubaguyits a bit messy17:35
johnthetubaguybut the instance is basically not really on a host, once it is selved (offloaded)17:35
johnthetubaguythe offloaded bit is about snapshotting any local disks, so you can resume on a different host)17:35
hemnabut the volume is still 'in-use'17:35
johnthetubaguyyeah, volume stays in-use17:35
johnthetubaguyit shouldn't be attached to any other place17:36
scottdaso similar to evacuate, we need to skip state checking17:36
johnthetubaguy... now there is a spec to detach disks from a shelved instance, which we currently don't support, but thats not approved yet, AFAIK17:36
johnthetubaguyscottda: +117:36
scottdajohnthetubaguy: I believe that under the covers, os-brick is called to actually disconnect the disk when we shelve, does that sound right?17:37
scottdaand a new connection occurs during un-shelve.17:37
johnthetubaguyyes, that does sound correct17:37
johnthetubaguyyeah, its assumed to be on a new host, and you want to clean up the old host17:37
johnthetubaguynot sure how well shelve is tested yet, I don't remember if the tempest stuff landed or not17:38
johnthetubaguybut thats the general intent17:38
scottdaSo, there's no messy force-detach issues, or dangling connection. Just a basic disconncect/re-connect in brick and dealing with weird state management.17:38
johnthetubaguythats my understanding of it17:38
johnthetubaguyevacuate is the only one with the force, I think...17:38
johnthetubaguyI think thats the main move operations all covered17:39
johnthetubaguyoh, right, live-migrate is slightly different to the other migrates17:39
smcginnisjohnthetubaguy: So for shelve, were you saying we need to detach the volume but still keep it in-use?17:40
johnthetubaguysmcginnis: yes17:40
johnthetubaguyits possible we just don't call terminate_connection thinking about it17:40
ildikovI guess it's only disconnected from the host17:40
johnthetubaguyildikov: +117:40
johnthetubaguyildikov: at least, thats the intent17:40
johnthetubaguyits logically still attached to the instance17:41
ildikovjohnthetubaguy: otherwise the state would change and you don't want to have the volume available17:41
johnthetubaguy+117:41
scottdaI need to move to IRC_on_phone mode, sorry folks, mostly Read-only from here on out....17:42
ildikovscottda: any updtes on the migrate test?17:42
ildikovscottda: on the Cinder migrate ones I meant17:42
johnthetubaguyare there any other questions like the above ones I can help with?17:43
scottdaildikov: sorry, no update.17:44
ildikovjohnthetubaguy: I wonder where we will update the host info for the shelve case17:44
ildikovscottda: no worries, I just wanted to check17:45
johnthetubaguyildikov: so there is no host, until you do unshelve, and we call initialize_connection again17:45
hemnaildikov, any time initialize_connection is called the connector passed in has the host and it should be updated17:45
johnthetubaguyI guess for local volumes, that messes things up, but otherwise, that should be OK?17:46
hemnaI'm hoping jgriffith's change has this in place as part of his patch(es)17:46
ildikovjohnthetubaguy: ah, ok, I wasn't sure we have the initialize_connection call17:46
johnthetubaguyildikov: I think we should have17:46
ildikovok, cool, I'll check if I get there17:46
ildikovjohnthetubaguy: can you also take a look at the multiattach spec?17:47
ildikovnext week is the deadline if I'm not mistaken17:47
johnthetubaguyildikov: for unshelve, its doing this: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L420517:48
johnthetubaguyildikov: yeah, sorry, I must look at that again, ASAP17:48
hemnaI think we are stuck waiting for jgriffith's patches no ?17:48
johnthetubaguyI have a quite a few specs in that list, I am afraid, but hope to get through more of those tomorrow17:48
johnthetubaguywe should be able to merge the spec before the patches, or is there something undecided we are depending on?17:49
ildikovI think we should be able to conclude on the spec17:50
johnthetubaguycool17:51
ildikovat least in my opinion, but it would be nice to get a heads up if there's anything missing17:51
johnthetubaguytotally, I will try hit that soon17:51
johnthetubaguyildikov: you totally have permission to keep bugging me every morning till I review it17:52
ildikovI tried to handle things like jgriffith's patches as an identified dependency, but not part of the multiattach spec technically17:52
johnthetubaguyildikov: that sounds correct17:52
johnthetubaguywe could call the other stuff a bug fix17:52
johnthetubaguyish17:52
ildikovjohnthetubaguy: thanks :) I might use it, but hopefully I will not need :)17:52
ildikovjohnthetubaguy: +117:53
ildikovmany of the discussions today sound like a cleanup and fixing issues we have hidden17:53
johnthetubaguyyeah17:53
smcginnisildikov: +117:53
ildikovok, we have 7 minutes left from the today's slot17:54
johnthetubaguyhonestly, most of this comes from neither side understand what the other is wanting to do17:54
johnthetubaguyso great we are cleaning this up now :)17:54
ildikovis there anything we should discuss?17:54
johnthetubaguyI was looking at the devref stuff in cinder, I think we might want a more API focused doc17:54
ildikovjohnthetubaguy: my thinking as well :)17:54
johnthetubaguythat includes os-brick in the discussion, maybe17:54
smcginnisjohnthetubaguy: I do like the suggestion of a devref in Nova for some of this. It's duplication, but hopefully it saves this from happening again once it's cleaned up.17:54
johnthetubaguyactually, that would work17:55
johnthetubaguydo the nova focused one in Nova17:55
johnthetubaguyi.e. here are the patterns17:55
ildikovsmcginnis: johnthetubaguy: I think we can also add hemna's diagrams17:55
johnthetubaguyif we do create server, delete server, live-migrate server, evacuate and shelve, we should be there17:55
johnthetubaguyyeah, diagrams are good to make this clearer17:55
ildikovnot as an API ref, but if someone would like to figure it out what's in the background it's pretty useful17:56
johnthetubaguyyeah17:56
scottdaI'll put it on my list to put up a patch in Nova devref17:57
johnthetubaguyit goes the core reviews something to go double check when we can't remember the details next time17:57
johnthetubaguys/ws/wers/17:57
johnthetubaguyscottda: awesome, thank you17:57
johnthetubaguynothing more from me for this week :)17:58
ildikovI think we have home work with these server moving actions and fix the reserve_volume in BFV17:58
ildikovI will try to hunt down jgriffith as soon as I can17:58
johnthetubaguyyeah, feel free to ping me in channel if later in the week, if thats useful17:58
ildikovjohnthetubaguy: cool, thanks17:59
ildikovanything else from anyone before we close?17:59
ildikovthen, thanks for the good chat!18:00
johnthetubaguy+118:00
scottdaThanks everyone18:00
ildikovI learnt a lot today :)18:00
smcginnisildikov: Thanks again for arranging this.18:00
ildikovoh one thing18:00
ildikovnext Monday is US holiday, so I will ask around when we could have a quick sync18:00
scottdaI'm out until Wed next week18:00
hemnaI think next week is going to be a bit of a loss for some18:01
hemnaI might be taking time off next week too.18:01
johnthetubaguyactually, its a UK holiday too18:01
ildikovthanks for the info, Matt is out too at the beginning18:01
johnthetubaguyI forget about those18:01
johnthetubaguyby which I mean, I forget they are coming up18:01
ildikovok, then let's aim for having a short chat mid next week18:02
scottdacool18:02
johnthetubaguythat works18:02
ildikovjohnthetubaguy: we need to get the spec landed, otherwise we should be good18:02
johnthetubaguyyeah, +118:02
smcginnisMaybe sync up on Thurday?18:02
johnthetubaguythats a good plan18:02
ildikovsmcginnis: yeap, sounds good18:02
scottdayup18:03
ildikovI hope 1700UTC can work18:03
johnthetubaguyif its quick, that should be OK18:03
ildikovI will send out a heads up mail later this week18:03
scottdathanks ildikov18:03
smcginnisWorks for me. We can hijack the cindre channel again if we need to.18:03
ildikovjohnthetubaguy: due to the holidays I would assume we can keep it short18:04
johnthetubaguy+118:04
johnthetubaguy:)18:04
ildikovsmcginnis: cool, thanks, I'll check the channels18:04
ildikovok, I don't want steal more of your time today :)18:04
ildikovthanks guys!18:05
ildikov#endmeeting18:05
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:05
openstackMeeting ended Mon May 23 18:05:17 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:05
openstackMinutes:        http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-05-23-17.00.html18:05
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-05-23-17.00.txt18:05
openstackLog:            http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-05-23-17.00.log.html18:05
*** geguileo has left #openstack-meeting-cp18:08
*** markvoelker has quit IRC19:14
*** markvoelker has joined #openstack-meeting-cp19:15
*** _amrith_ is now known as amrith19:31
*** piet has quit IRC19:46
*** amrith is now known as _amrith_19:46
*** piet has joined #openstack-meeting-cp19:48
*** rockyg has joined #openstack-meeting-cp20:11
*** rockyg has quit IRC20:19
*** sdake has joined #openstack-meeting-cp20:21
*** itisha has quit IRC20:29
*** sdake has quit IRC20:37
*** _amrith_ is now known as amrith20:46
*** sdake has joined #openstack-meeting-cp20:47
*** sdake_ has joined #openstack-meeting-cp20:51
*** sdake has quit IRC20:54
*** rockyg has joined #openstack-meeting-cp21:00
*** amrith is now known as _amrith_21:01
*** sheel has quit IRC21:45
*** rockyg has quit IRC22:07
*** rockyg has joined #openstack-meeting-cp22:10
*** piet has quit IRC22:11
*** rockyg has quit IRC22:12
*** sdague has quit IRC22:28
*** tonyb_ has joined #openstack-meeting-cp22:48
*** lbragstad_ has joined #openstack-meeting-cp22:51
*** dolphm_ has joined #openstack-meeting-cp22:51
*** reed_ has joined #openstack-meeting-cp22:51
*** odyssey4me_ has joined #openstack-meeting-cp22:51
*** tbarron_ has joined #openstack-meeting-cp22:52
*** xyang1 has quit IRC22:53
*** ildikov has quit IRC22:53
*** GheRivero has quit IRC22:53
*** odyssey4me has quit IRC22:53
*** lbragstad has quit IRC22:53
*** samueldmq has quit IRC22:53
*** tonyb has quit IRC22:53
*** reed has quit IRC22:53
*** tbarron has quit IRC22:53
*** dolphm has quit IRC22:53
*** patrickeast has quit IRC22:53
*** tbarron_ is now known as tbarron22:53
*** reed_ is now known as reed22:53
*** dolphm_ is now known as dolphm22:53
*** lbragstad_ is now known as lbragstad23:33
*** tonyb_ is now known as tonyb23:43

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