Wednesday, 2013-06-12

*** cp16net is now known as cp16net|away00:09
*** demorris has quit IRC00:11
*** cp16net|away is now known as cp16net00:15
*** djohnstone has quit IRC00:16
*** tanisdl has quit IRC00:26
*** cp16net is now known as cp16net|away00:29
*** lastidiot has joined #openstack-meeting-alt00:39
*** bdpayne has quit IRC00:58
*** demorris has joined #openstack-meeting-alt01:07
*** seanrob_ has joined #openstack-meeting-alt01:09
*** seanrob has quit IRC01:12
*** seanrob_ has quit IRC01:14
*** saurabhs has quit IRC01:34
*** demorris has quit IRC01:37
*** jcru has quit IRC01:38
*** grapex has quit IRC01:39
*** cp16net|away is now known as cp16net03:31
*** SergeyLukjanov has joined #openstack-meeting-alt03:35
*** bdpayne has joined #openstack-meeting-alt03:48
*** bdpayne has quit IRC04:06
*** bdpayne has joined #openstack-meeting-alt04:24
*** amytron has joined #openstack-meeting-alt04:30
*** grapex has joined #openstack-meeting-alt04:34
*** grapex has quit IRC04:36
*** amytron has quit IRC04:36
*** grapex has joined #openstack-meeting-alt04:36
*** amytron has joined #openstack-meeting-alt04:38
*** SergeyLukjanov has quit IRC05:06
*** bdpayne has quit IRC05:07
*** lastidiot has quit IRC05:10
*** amytron has quit IRC05:10
*** amytron has joined #openstack-meeting-alt05:10
*** bdpayne has joined #openstack-meeting-alt05:14
*** amytron has quit IRC05:14
*** amytron has joined #openstack-meeting-alt05:15
*** SergeyLukjanov has joined #openstack-meeting-alt05:16
*** amytron has quit IRC05:16
*** amytron has joined #openstack-meeting-alt05:17
*** grapex has quit IRC05:32
*** esp has left #openstack-meeting-alt05:37
*** SergeyLukjanov has quit IRC05:44
*** amytron has quit IRC05:44
*** amytron has joined #openstack-meeting-alt05:45
*** bdpayne has quit IRC05:49
*** BalleS_ has joined #openstack-meeting-alt06:03
*** amytron has quit IRC06:03
*** amytron has joined #openstack-meeting-alt06:03
*** susanne-balle has quit IRC06:06
*** BalleS_ has quit IRC06:07
*** akuznetsov has joined #openstack-meeting-alt06:08
*** akuznetsov has quit IRC06:19
*** grapex has joined #openstack-meeting-alt06:32
*** grapex has quit IRC06:41
*** amytron has quit IRC06:41
*** amytron has joined #openstack-meeting-alt06:41
*** akuznetsov has joined #openstack-meeting-alt07:01
*** amytron has quit IRC08:37
*** grapex has joined #openstack-meeting-alt08:37
*** amytron has joined #openstack-meeting-alt08:38
*** grapex has quit IRC08:41
*** amytron has quit IRC08:41
*** amytron has joined #openstack-meeting-alt08:42
*** akuznetsov has quit IRC08:45
*** amytron has quit IRC08:45
*** amytron has joined #openstack-meeting-alt08:47
*** jesusaurus has quit IRC09:00
*** amytron has quit IRC09:00
*** amytron has joined #openstack-meeting-alt09:01
*** akuznetsov has joined #openstack-meeting-alt09:04
*** amytron has quit IRC09:04
*** amytron has joined #openstack-meeting-alt09:05
*** jesusaurus has joined #openstack-meeting-alt09:09
*** amytron has quit IRC09:09
*** amytron has joined #openstack-meeting-alt09:10
*** qwerty_nor has joined #openstack-meeting-alt10:08
*** pcm__ has joined #openstack-meeting-alt10:27
*** amytron has quit IRC10:27
*** pcm__ has quit IRC10:27
*** pcm__ has joined #openstack-meeting-alt10:27
*** amytron has joined #openstack-meeting-alt10:28
*** amytron has quit IRC10:37
*** grapex has joined #openstack-meeting-alt10:37
*** amytron has joined #openstack-meeting-alt10:38
*** grapex has quit IRC10:41
*** amytron has quit IRC10:41
*** amytron has joined #openstack-meeting-alt10:43
*** stanlagun has quit IRC11:13
*** amytron has quit IRC11:13
*** amytron has joined #openstack-meeting-alt11:13
*** HenryG has joined #openstack-meeting-alt11:18
*** amytron has quit IRC11:18
*** HenryG_ has quit IRC11:18
*** amytron has joined #openstack-meeting-alt11:20
*** akuznetsov has quit IRC11:29
*** amytron has quit IRC11:29
*** amytron has joined #openstack-meeting-alt11:31
*** amytron has quit IRC11:55
*** amytron has joined #openstack-meeting-alt11:55
*** SergeyLukjanov has joined #openstack-meeting-alt11:59
*** amytron has quit IRC12:04
*** demorris has joined #openstack-meeting-alt12:06
*** demorris has quit IRC12:20
*** susanne-balle has joined #openstack-meeting-alt12:32
*** grapex has joined #openstack-meeting-alt12:37
*** grapex has quit IRC12:42
*** jergerber has joined #openstack-meeting-alt12:43
*** grapex has joined #openstack-meeting-alt12:43
*** grapex has quit IRC12:43
*** grapex has joined #openstack-meeting-alt12:44
*** grapex has quit IRC13:00
*** rnirmal has joined #openstack-meeting-alt13:10
*** akuznetsov has joined #openstack-meeting-alt13:22
*** mtreinish has joined #openstack-meeting-alt13:28
*** SergeyLukjanov has quit IRC13:42
*** grapex has joined #openstack-meeting-alt13:47
*** grapex has quit IRC13:48
*** grapex has joined #openstack-meeting-alt13:48
*** SergeyLukjanov has joined #openstack-meeting-alt13:49
*** demorris has joined #openstack-meeting-alt13:53
*** maroh has joined #openstack-meeting-alt14:04
*** lastidiot has joined #openstack-meeting-alt14:09
*** maroh has quit IRC14:09
*** demorris has left #openstack-meeting-alt14:10
*** cp16net is now known as cp16net|away14:11
*** djohnstone has joined #openstack-meeting-alt14:14
*** dhellmann-away has quit IRC14:15
*** dhellmann has joined #openstack-meeting-alt14:21
*** SergeyLukjanov has quit IRC14:22
*** amytron has joined #openstack-meeting-alt14:22
*** feleouet has joined #openstack-meeting-alt14:22
*** lastidiot has quit IRC14:23
*** jcru has joined #openstack-meeting-alt14:25
*** stackKid has joined #openstack-meeting-alt14:31
*** rkukura has joined #openstack-meeting-alt14:32
*** apech_ has joined #openstack-meeting-alt14:33
*** matrohon has joined #openstack-meeting-alt14:33
*** markmcclain has joined #openstack-meeting-alt14:34
*** susanne-balle has quit IRC14:35
*** megan_w has joined #openstack-meeting-alt14:39
*** imsplitbit has left #openstack-meeting-alt14:41
*** cp16net|away is now known as cp16net14:43
*** doude has joined #openstack-meeting-alt14:51
*** enikanorov has joined #openstack-meeting-alt14:52
mesteryHi folks, hopefully everyone is here for the ML2 Networking meeting now!15:00
*** BrianB has joined #openstack-meeting-alt15:00
markmcclainhi15:01
mestery#startmeeting networking_ml215:01
openstackMeeting started Wed Jun 12 15:01:05 2013 UTC.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
*** openstack changes topic to " (Meeting topic: networking_ml2)"15:01
openstackThe meeting name has been set to 'networking_ml2'15:01
mestery#agenda https://wiki.openstack.org/wiki/Meetings/ML215:01
mesterySo, first, apologies for the timing mistake on my part.15:01
mestery#info Next week and going forward we will have the ML2 meeting at 1400 UTC Wednesday15:01
*** rcurran has joined #openstack-meeting-alt15:02
*** lastidiot has joined #openstack-meeting-alt15:02
mestery#topic MechanismDriver15:02
*** openstack changes topic to "MechanismDriver (Meeting topic: networking_ml2)"15:02
mesteryI thought we could start out with the MechanismDriver.15:02
mestery#apech_: You here?15:02
apech_yup15:03
mesterycool15:03
mesteryI think your email to openstack-dev is a good starting point here, hopefully people have had a chance to read it.15:03
apech_thanks, I have a few questions to pose to the list if that's a good place to start, or can summarize quickly15:03
mestery#link http://lists.openstack.org/pipermail/openstack-dev/2013-June/010252.html15:03
mesteryapech_: Lets go with questions, assuming folks have read your email.15:04
apech_great15:04
*** akuznetsov has quit IRC15:04
apech_maybe one place to start is on the question of calls to the mechanism driver within or after the transaction15:05
apech_I think I actually misspoke in my email and our implementation will mostly use calls after the transaction15:05
*** ZangMingJie has joined #openstack-meeting-alt15:06
apech_but are there use cases out there for a call within the transaction?15:06
mesteryI think outside the transaction makes the most sense.15:06
mesteryThoughts by others?15:06
apech_and if there are, any suggestions on the function names? The best I can think of is "create_network_in_transaction" and "create_network_after_transaction", which makes me puke a bit :)15:06
*** fmanco has joined #openstack-meeting-alt15:07
rkukuraapech_: Outside would make sense for remote round-trip communications, inside for DB access.15:07
apech_rkurura: ok that makes sense15:07
mesterySo, sounds like we have our use case for in-transaction then.15:08
apech_do you have any thoughts on distinguishing between the method names?15:08
rkukuraI had thought of _tx on the in-transaction ones.15:08
*** Sukhdev has joined #openstack-meeting-alt15:08
mesteryrkukura: I like that naming approach better than apech_'s. :)15:08
apech_okay, that works for me15:08
apech_haha15:09
apech_good, I guilted people into better suggestions15:09
apech_alternatively, I guess inside the transaction could be considered the allocation of resources for the action, while outside the transaction is the implementation15:09
Sukhdevsorry for being late - went into the wrong meeting :-)15:09
mesteryapech_: Conceptually that makes sense.15:09
mesterySukhdev: No problem. :)15:10
mesteryAny other MechanismDriver questions?15:10
apech_yeah, i guess the other one that comes up (outside of the specific API), is how to order mechanism driver calls15:11
*** tanisdl has joined #openstack-meeting-alt15:11
*** tanisdl has quit IRC15:11
apech_so if you enable two mechanism drivers, do we need to be able to specify the order in which they are called? is it registration order?15:11
mesteryRegistration order would be easiest I guess, and would enable the user to order things, for better or worse.15:12
rkukuraapech_: ordering is something I've been thinking about for the ml2-portbinding DP15:12
rcurrani guess i envisioned an ini file having the list of mech_drivers ... called in that order15:12
rkukuraWe want to be able to prioritize which mechanism to try first, ...15:12
mesteryrkukura: So something like what rcurran suggested here?15:13
*** stanlagun has joined #openstack-meeting-alt15:13
rcurranand the order configured in the ini isn't good enough15:13
SukhdevHow do you decide on the priority?15:13
mesterySukhdev: Order in the .ini file?15:13
rkukuraprobably - but I'd want to look at stevedore again to see if the same mechanism_driver list can be used once they are loaded15:14
*** tanisdl has joined #openstack-meeting-alt15:14
apech_rkukura: are you envisioning a case where only one mechanism driver handles a given call, or they all do?15:14
rkukuraonly for portbinding right now15:14
apech_I was thinking of the later, but the way you put your statement, I wonder if you're thinking of the former15:14
rkukuraI think the CRUD ops need to go to them all, and I'm not sure if order matters for that15:14
mesteryrkukura: Agreed on both accounts there.15:15
apech_okay great, seems like we agree there15:15
rkukuraI'm at Red Hat Summit this week, and haven't had a chance to read the proposal in detail15:15
mesteryOne other question I had related to all this is, the OVS and LinuxBridge stuff is currently embedded in ML2. Is the plan to make that a MechanismDriver as well?15:16
apech_did anyone have any feedback for me after reading the proposal? Sounds like we need to add inside vs outside method calls. If that's it, we can get this coded up prety quickly and send this out for review15:16
rkukuraplease don't take anything I say as intentionally contradicting anything in that15:16
mesteryI see cases where some plugins won't want to run with that enabled in ML2.15:16
rkukuraI've been viewing the RPCs as a plugin service that can eventually be extended by MechanismDrivers15:17
rkukuraAll the RPC mixins kind of need to come from the plugin (L3, firewall, ...)15:17
mesteryrkukura: So in the case of a controller MechanismDriver which won't want to use OVS/LinuxBridge, that will be supportable then?15:17
rkukuraSince the L2 RPC is so similar for all existing L2 agents, it made sense to share this, at least initially15:18
mesteryrkukura: I'm thinking of something like OpenDaylight for example.15:18
*** qwerty_nor has quit IRC15:18
rkukuraOne goal I've had for ml2 is to support all types and mechanisms concurrently15:18
mesteryOk, that makes sense.15:19
mesteryAnything else on MechanismDriver?15:19
rkukuraso part of a datacenter might be using a controller, while some other part is using the L2 agent(s)15:19
feleouetOne more question: when mechanism driver is called, will the plugin use the same process? (calling _notify_port_updated for example)15:19
rkukuraand a flat network or vlan might span these15:19
apech_feleouet: I'm not sure I followed your question, sorry15:20
rkukurafeleouet: I wouldn't think so15:20
mesteryfeleouet: Can you explain your concern a bit more?15:21
rkukuraIf the portbinding results in an L2 agent being used for that port, then the L2 agent will initiate the RPCs, etc. If a controller "owns" the port, the RPCs won't occur15:21
feleouetI'm concerned about that, and joining kyle question about making OVS & LB as machnisms drivers:15:21
rkukuraThe ml2-portbinding BP does talk about adding MechDrivers for each L2 agent15:22
mesteryWith regards to OVS & LB, from what rkukura is indicating here, if a "controller" MechanismDriver owns the port, the RPC calls won't happen for that port. Is that right?15:22
rkukuramestery: That's what I was trying to say15:22
mesteryrkukura: OK, I guess I'm missing how a MechanismDriver claims ownership of a port then.15:23
mesteryBut I can check the code out for that part.15:23
*** dhellmann_ has joined #openstack-meeting-alt15:23
apech_I think this is part of what rkukura is defining for the ml2 port binding bp15:23
rkukurano code yet for that15:23
mesteryOK, makes sense, I'll keep my eye on the ml2 portbinding BP.15:24
apech_for the generic mechanism driver bp, I'm not imagining adding this, as I think we'll call all registered mechanism drivers for all calls15:24
apech_(all calls = create_network, delete_network, etc)15:24
mesteryapech_: We will need to coordinate this with Bob's blueprint then to ensure it's possible to make this happen though.15:24
rkukuraapech_: Agreed - I thought it made sense to treat what you are working on and ml2-portbinding as separate BPs so we could work in parallel15:25
mesterySounds like we're all on the same page here then.15:25
apech_mestery: agreed15:25
apech_rkukura: great15:25
mesteryOK, any other MechanismDriver questions or thoughts?15:25
rkukuraml2-portbinding will result in the binding:vif_type being correct based on which MechDriver is used, and will also allow picking which segment of multi-segement networks that agent has access to15:25
apech_that's all I had on the mechanism driver. I'll send out an updated proposal to my email after this15:26
mesteryapech_: OK, thanks.15:26
mesteryrkukura: That makes sense as well.15:26
rcurranwant to make sure i understand this ... so if a mdriver owns a port then the rpc calls made by the ovs driver would be stifed somehow15:26
rcurranis it ok that the other code inside of these events are still executed15:26
*** dhellmann has quit IRC15:26
*** dhellmann_ is now known as dhellmann15:26
rcurran?15:26
*** SergeyLukjanov has joined #openstack-meeting-alt15:27
mesteryrcurran: I think that's the general idea, yes, though I wouldn't expect the code to be executed in the case of hte port being owned by a different MechanismDriver.15:28
mesteryMakes sense rcurran?15:28
rcurranso no code inside of say plugin.py create_port() would be called15:29
rkukurarcurran: Not sure stifling them is needed, but we could consider that15:29
mesteryOK, lets move on to the TypeDrivers now.15:29
rkukurawe clearly could get the MechDrivers in the loop on the RPC calls, but lets see if that turns out to be needed15:30
mestery#topic TypeDrivers15:30
*** openstack changes topic to "TypeDrivers (Meeting topic: networking_ml2)"15:30
mesteryIs Rohon here?15:30
matrohonyep15:30
mesterymatrohon: Hi!15:30
mestery#link Early ml2-gre code here: https://github.com/mathieu-rohon/quantum/commits/bp/ml2-gre15:31
mesterymatrohon: Thanks for sharing that early code, will review it today.15:31
mesterymatrohon: Anything you wanted to share or discuss around it today?15:31
matrohonok15:31
matrohonit works fine for tenant networks15:31
matrohonneed some more test for other use cases15:31
mesterymatrohon: Awesome!15:31
rkukuratook a quick glance, will review more closely as soon as I can15:32
mesteryI'm going to look at it to see if some of it can be leveraged for the ml2-vxlan BP too :)15:32
matrohoni've copy a lot of code from ovs plugin15:32
mesterymatrohon: I think that makes some sense, given the approach of ML2 may be to deprecate the OVS+LB plugins.15:33
matrohonbut i use gre-endpoints instead of globol endpoint (for vxlan and gre)15:33
rkukuraseems the attribute validation and tenant pooling should be very similar to the VlanTypeDriver as well15:33
*** rods has joined #openstack-meeting-alt15:33
mesterymatrohon: I didn't follow your gre-endpoint vs. global endpoint?15:34
matrohonyou could have use the same endpoint managment code for vxlan endpoints and gre endpoints15:35
matrohonbut that's not the way i choose15:35
mesterymatrohon: OK, got it.15:35
mesterymatrohon: Let me look at your code, maybe it makes sense to combine them? The OVS+VXLAN work was just approved today in fact.15:35
matrohonagent may be a gre endpoint but not vxlan endpoint15:37
feleouetBut won't actual OVS VXLAN code use GRE typeDriver for now?15:37
mesterymatrohon: We can add that support to your code, or I can rather, let me know.15:37
rkukuraI think mestery is adding a VxlanTypeDriver that will mirror the GreTypeDriver15:37
mesteryfeleouet: Why would it use the GRE TypeDriver for now? We will need a VXLAN TypeDriver I think.15:37
mesteryrkukura: Yes, exactly.15:38
rkukuraSo the RPC interface might be shared, but need to dispatch to the right TypeDriver to manage the endpoints for that tunnel type15:38
feleouetyes, in turn, but for now how will you allocate segments if they can't overlap?15:38
matrohonrkukura : exactly15:38
rkukuraAt that point, I think we can have the L2 agents pass tunnel_type in the RPCs15:39
matrohonrkukura : I think so, in the tunnel_sync15:39
mesterymatrohon rkukura: Exactly, that is the plan.15:39
mesteryfeleouet: What do you mean the segments can't overlap? You could reuse a segment ID for both GRE and VXLAN type networks.15:40
rkukurafeleouet, mestery: these are segmentation_ids right? I agree they should be independently managed by ml2 TypeDrivers.15:40
mesteryrkukura feleouet: Yes, that's my thinking as well. No reason they can't overlap, and each TypeDriver can manage their own segment IDs.15:41
mesteryWould be configurable in the ini files per TypeDriver I believe.15:42
feleouetyes, agree they have to be managed independantly.15:42
matrohonthe overlaping will be hard to manage in the ovs agent15:42
matrohonsince flow are managed by tunnel_id15:42
mesterymatrohon: We'll need to make changes to the agent, yes, this was discussed during the review of my OVS+VXLAN patch.15:43
mesteryThe idea is to change from tunnel_id to something like the partial mesh patch implements.15:43
feleouetMy remark was concerning current VXLAN code, that doesn't supports segemntation_id overlap15:43
matrohonmestery : great15:44
feleouetthis is was i was thinkin it would use GRE typedriver until we use perport flow rules in agents15:44
mesteryfeleouet: The current code only supports VXLAN OR GRE tunnels, not both at the same time.15:44
mesteryfeleouet: Got it, now I understand.15:44
*** Riddhi has joined #openstack-meeting-alt15:44
mesteryI'll make changes to the agent side to support both at the same time next.15:44
mesterySo we can manage IDs using the two TypeDrivers separately.15:44
matrohonactually we think that partial mesh stuff could be handle in the l2 population BP15:45
mesterymatrohon: That makes sense to me.15:45
rkukuraSo the openvswitch plugin will remain one-or-the-other, while ml2 supports multiple types concurrently15:45
mesteryrkukura: Exactly.15:45
mesteryOK, so I think we're making good progress here on the TypeDrivers it seems.15:46
mesteryAnd coming to consensus on things.15:46
mesteryAnything else on TypeDrivers?15:46
*** Riddhi has quit IRC15:47
mestery#topics General Questions15:47
mestery#topic General Questions15:48
*** openstack changes topic to "General Questions (Meeting topic: networking_ml2)"15:48
mesterySo the list of blueprints on ML2 is on the wiki.15:48
mestery#link ML2 blueprints link: https://wiki.openstack.org/wiki/Meetings/ML215:48
mesteryapech_: Getting the MechanismDriver out for review this weekend woudl be great considering it's importance.15:49
apech_yeah, agreed. Should be able to do that15:49
mesteryOnce that and rkukura's portbinding BP are in, people can start writing MechanismDriver's.15:49
mesteryA question for people: We have an OpenDaylight plugin mostly working now.15:50
mesteryWhat are people's thoughts on making that the first Open Source ML2 MechanismDriver in the controller model?15:50
apech_fine by me - we have to convert something in the controller model to make sure we have the right model15:51
apech_(too many uses of model, but you hopefully get what I mean)15:51
mesteryapech_: My thoughts exactly, and we'll want an Open Source Controller MechanismDriver as well, which was my thinking here.15:51
mesteryapech_: Yes. :)15:51
mesteryOK, any other questions or thoughts by anyone?15:51
mesteryIf not, we'll end the meeting.15:51
*** bdpayne has joined #openstack-meeting-alt15:52
rcurrani'm good15:52
apech_yup, gotta run anyway15:52
apech_thanks all15:52
rkukuramestery: +115:52
mesteryOk, thanks everyone!15:52
Sukhdevgood meeting15:52
mesteryReminder: Next week's meeting is at 1400 UTC Wednesday on #openstack-meeting.15:52
mestery#endmeeting15:52
*** openstack changes topic to "OpenStack meetings (alternate)"15:52
openstackMeeting ended Wed Jun 12 15:52:51 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:52
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_ml2/2013/networking_ml2.2013-06-12-15.01.html15:52
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_ml2/2013/networking_ml2.2013-06-12-15.01.txt15:52
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_ml2/2013/networking_ml2.2013-06-12-15.01.log.html15:52
rkukurathanks everyone!15:53
mesteryYes, thanks all!15:53
feleouetthanks, bye.15:53
*** apech_ has quit IRC15:53
*** rcurran has quit IRC15:55
*** Sukhdev has quit IRC15:55
*** matrohon has quit IRC15:55
*** BrianB has quit IRC16:07
*** SergeyLukjanov has quit IRC16:18
*** cp16net is now known as cp16net|away16:19
*** esp has joined #openstack-meeting-alt16:29
*** esp has left #openstack-meeting-alt16:29
*** feleouet has quit IRC16:42
*** rkukura has quit IRC16:51
*** stanlagun has quit IRC16:54
*** jcru is now known as jcru|away16:58
*** seanrob has joined #openstack-meeting-alt17:18
*** vipul is now known as vipul|away17:23
*** Riddhi has joined #openstack-meeting-alt17:24
*** megan_w has quit IRC17:28
*** sirushti has quit IRC17:32
*** sirushti has joined #openstack-meeting-alt17:33
*** vipul|away is now known as vipul17:38
*** grapex has quit IRC17:45
*** seanrob has quit IRC17:54
*** cp16net|away is now known as cp16net17:56
*** SergeyLukjanov has joined #openstack-meeting-alt18:01
*** akuznetsov has joined #openstack-meeting-alt18:18
*** grapex has joined #openstack-meeting-alt18:19
*** grapex has quit IRC18:19
*** grapex has joined #openstack-meeting-alt18:19
*** markmcclain has quit IRC18:20
*** jcru|away is now known as jcru18:23
*** markmcclain has joined #openstack-meeting-alt18:26
*** markwash has joined #openstack-meeting-alt18:27
*** mestery has quit IRC18:32
*** rods has quit IRC18:45
*** megan_w has joined #openstack-meeting-alt18:52
notmynameswift meeting time. who's here?19:00
notmynamewhoops wrong channel19:01
*** mestery has joined #openstack-meeting-alt19:12
*** qwerty_nor has joined #openstack-meeting-alt19:20
*** jcru is now known as jcru|away19:22
*** rnirmal has quit IRC19:30
*** jcru|away is now known as jcru19:30
*** vipul is now known as vipul|away19:35
*** rkukura has joined #openstack-meeting-alt19:51
*** seanrob has joined #openstack-meeting-alt20:12
*** cp16net is now known as cp16net|away20:15
*** cp16net|away is now known as cp16net20:15
*** vipul|away is now known as vipul20:37
*** megan_w has quit IRC20:38
*** seanrob has quit IRC20:42
*** seanrob has joined #openstack-meeting-alt20:42
*** rkukura has quit IRC20:45
*** seanrob has quit IRC20:47
*** akuznetsov has quit IRC20:47
*** seanrob has joined #openstack-meeting-alt20:49
*** seanrob has quit IRC20:51
*** seanrob has joined #openstack-meeting-alt20:51
*** seanrob has quit IRC20:56
*** grapex has left #openstack-meeting-alt20:56
*** jcru is now known as jcru|away21:02
*** qwerty_nor has quit IRC21:03
*** seanrob has joined #openstack-meeting-alt21:05
*** fmanco has left #openstack-meeting-alt21:17
*** djohnstone has quit IRC22:00
*** mtreinish has quit IRC22:05
*** jcru|away is now known as jcru22:05
*** SergeyLukjanov has quit IRC22:14
*** lastidiot has quit IRC22:37
*** vipul is now known as vipul|away23:08
*** jergerber has quit IRC23:09
*** vipul|away is now known as vipul23:09
*** jergerber has joined #openstack-meeting-alt23:10
*** dnosovitsky has quit IRC23:26
*** tanisdl has quit IRC23:26
*** markwash has quit IRC23:29
*** jcru has quit IRC23:30
*** seanrob_ has joined #openstack-meeting-alt23:32
*** seanrob has quit IRC23:34
*** seanrob_ has quit IRC23:37
*** amytron has quit IRC23:41
*** cp16net is now known as cp16net|away23:49
*** mestery has quit IRC23:50

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