Wednesday, 2015-02-18

*** baoli has quit IRC00:01
*** carl_baldwin has quit IRC00:08
*** stanzgy has quit IRC00:16
*** Yi has joined #openstack-meeting-300:22
*** mattgriffin has quit IRC00:22
*** marun has quit IRC00:23
*** jaypipes has quit IRC00:27
*** carl_baldwin has joined #openstack-meeting-300:27
*** VW_ has quit IRC00:28
*** etoews has joined #openstack-meeting-300:28
*** banix has joined #openstack-meeting-300:28
*** nelsnelson has quit IRC00:33
*** banix has quit IRC00:35
*** markvoelker has quit IRC00:37
*** markvoelker has joined #openstack-meeting-300:37
*** Piet has quit IRC00:37
*** banix has joined #openstack-meeting-300:39
*** bknudson has quit IRC00:41
*** MarkAtwood has quit IRC00:42
*** markvoelker has quit IRC00:42
*** seizadi has joined #openstack-meeting-300:42
*** david-lyle has quit IRC00:44
*** seizadi has quit IRC00:44
*** banix has quit IRC00:46
*** pasha117 has quit IRC00:50
*** pasha117 has joined #openstack-meeting-300:51
*** alexsyip has quit IRC00:52
*** banix has joined #openstack-meeting-300:52
*** reed has quit IRC00:58
*** yamamoto has quit IRC01:03
*** absubram has quit IRC01:05
*** ivar-lazzaro has quit IRC01:08
*** ivar-lazzaro has joined #openstack-meeting-301:09
*** ivar-lazzaro has quit IRC01:10
*** Rockyg has quit IRC01:11
*** ivar-lazzaro has joined #openstack-meeting-301:11
*** mwagner_lap has joined #openstack-meeting-301:24
*** banix has quit IRC01:32
*** banix has joined #openstack-meeting-301:35
*** yamamoto has joined #openstack-meeting-301:36
*** sigmavirus24 is now known as sigmavirus24_awa01:38
*** bpokorny_ has quit IRC01:41
*** salv-orlando has quit IRC01:58
*** markvoelker has joined #openstack-meeting-301:59
*** banix has quit IRC02:07
*** banix has joined #openstack-meeting-302:11
*** david-lyle has joined #openstack-meeting-302:11
*** SridharRamaswamy has quit IRC02:11
*** mwang2 has quit IRC02:17
*** s3wong has quit IRC02:42
*** salv-orlando has joined #openstack-meeting-302:59
*** carl_baldwin has quit IRC03:07
*** devanand_ has joined #openstack-meeting-303:12
*** yamahata has quit IRC03:13
*** melwitt_ has joined #openstack-meeting-303:24
*** melwitt has quit IRC03:25
*** sarob has quit IRC03:26
*** melwitt_ is now known as melwitt03:27
*** Yi has quit IRC03:34
*** david-lyle has quit IRC03:35
*** david-lyle has joined #openstack-meeting-303:35
*** david-lyle has quit IRC03:40
*** coolsvap_ is now known as coolsvap03:43
*** salv-orlando has quit IRC03:51
*** amotoki has joined #openstack-meeting-303:54
*** bpokorny has joined #openstack-meeting-304:00
*** bpokorny has quit IRC04:01
*** bpokorny has joined #openstack-meeting-304:02
*** sarob has joined #openstack-meeting-304:16
*** sarob has quit IRC04:16
*** Yi has joined #openstack-meeting-304:20
*** david-lyle has joined #openstack-meeting-304:22
*** david-lyle is now known as david-lyle_afk04:23
*** Piet has joined #openstack-meeting-304:25
*** killer_prince is now known as lazy_prince04:31
*** tmazur has joined #openstack-meeting-304:38
*** Yi has quit IRC04:38
*** etoews has quit IRC04:41
*** etoews has joined #openstack-meeting-304:41
*** etoews has quit IRC04:52
*** seizadi has joined #openstack-meeting-304:52
*** seizadi has quit IRC04:59
*** seizadi has joined #openstack-meeting-304:59
*** MarkAtwood has joined #openstack-meeting-305:00
*** jckasper has joined #openstack-meeting-305:02
*** jckasper has quit IRC05:02
*** jckasper has joined #openstack-meeting-305:02
*** seizadi has quit IRC05:03
*** seizadi has joined #openstack-meeting-305:04
*** seizadi1 has joined #openstack-meeting-305:08
*** seizadi has quit IRC05:08
*** banix has quit IRC05:09
*** seizadi has joined #openstack-meeting-305:12
*** seizadi1 has quit IRC05:12
*** seizadi1 has joined #openstack-meeting-305:16
*** seizadi has quit IRC05:16
*** dkehn has quit IRC05:19
*** seizadi has joined #openstack-meeting-305:19
*** seizadi1 has quit IRC05:20
*** jckasper has quit IRC05:23
*** devanand_ has quit IRC05:25
*** seizadi1 has joined #openstack-meeting-305:25
*** seizadi has quit IRC05:26
*** seizadi has joined #openstack-meeting-305:29
*** seizadi1 has quit IRC05:30
*** belmoreira has joined #openstack-meeting-305:31
*** jckasper has joined #openstack-meeting-305:33
*** yamahata has joined #openstack-meeting-305:33
*** seizadi1 has joined #openstack-meeting-305:34
*** seizadi has quit IRC05:34
*** salv-orlando has joined #openstack-meeting-305:36
*** seizadi has joined #openstack-meeting-305:38
*** Yi has joined #openstack-meeting-305:38
*** seizadi1 has quit IRC05:38
*** jckasper_ has joined #openstack-meeting-305:42
*** Yi has quit IRC05:43
*** seizadi has quit IRC05:44
*** seizadi has joined #openstack-meeting-305:45
*** seizadi has quit IRC05:45
*** jckasper has quit IRC05:46
*** mattgriffin has joined #openstack-meeting-305:52
*** markvoelker has quit IRC06:03
*** armax has quit IRC06:04
*** markvoelker has joined #openstack-meeting-306:04
*** markvoelker has quit IRC06:08
*** eghobo has joined #openstack-meeting-306:12
*** eghobo has quit IRC06:26
*** ivar-laz_ has joined #openstack-meeting-306:33
*** ivar-lazzaro has quit IRC06:37
*** lazy_prince is now known as killer_prince06:37
*** ivar-laz_ has quit IRC06:38
*** killer_prince is now known as lazy_prince06:44
*** melwitt has quit IRC06:46
*** FallenPegasus has joined #openstack-meeting-306:48
*** FallenPegasus has quit IRC06:48
*** MarkAtwood has quit IRC06:50
*** markvoelker has joined #openstack-meeting-306:53
*** markvoelker has quit IRC06:58
*** gulic has joined #openstack-meeting-307:02
*** pkoniszewski has joined #openstack-meeting-307:09
*** sarob has joined #openstack-meeting-307:26
*** sergef has joined #openstack-meeting-307:27
*** sahid has joined #openstack-meeting-307:32
*** scheuran has joined #openstack-meeting-307:40
*** vitorc has quit IRC07:49
*** salv-orlando has quit IRC07:51
*** markvoelker has joined #openstack-meeting-307:54
*** vitorc has joined #openstack-meeting-307:55
*** mrunge has joined #openstack-meeting-307:58
*** markvoelker has quit IRC07:59
*** etoews has joined #openstack-meeting-308:06
*** jtomasek has joined #openstack-meeting-308:06
*** etoews has quit IRC08:10
*** vitorc has quit IRC08:11
*** evgenyf has joined #openstack-meeting-308:11
*** tmazur has quit IRC08:13
*** yamamoto has quit IRC08:13
*** mwang2 has joined #openstack-meeting-308:13
*** yamahata has quit IRC08:15
*** yamahata has joined #openstack-meeting-308:16
*** vitorc has joined #openstack-meeting-308:16
*** mwang2 has quit IRC08:18
*** devvesa has joined #openstack-meeting-308:18
*** JeanBriceCombebi has joined #openstack-meeting-308:20
*** tmazur has joined #openstack-meeting-308:26
*** stanzgy has joined #openstack-meeting-308:26
*** wojdev has joined #openstack-meeting-308:35
*** wojdev has quit IRC08:36
*** etoews has joined #openstack-meeting-308:38
*** etoews has quit IRC08:42
*** zz_ttrifonov is now known as ttrifonov08:46
*** MaxV has joined #openstack-meeting-308:47
*** salv-orlando has joined #openstack-meeting-308:48
*** evgenyf has quit IRC08:49
*** JeanBriceCombebi has quit IRC08:54
*** markvoelker has joined #openstack-meeting-308:55
*** JeanBriceCombebi has joined #openstack-meeting-308:57
*** markvoelker has quit IRC09:00
*** salv-orlando has quit IRC09:01
*** matrohon has joined #openstack-meeting-309:01
*** salv-orlando has joined #openstack-meeting-309:01
*** yamamoto has joined #openstack-meeting-309:10
*** salv-orlando has quit IRC09:10
*** salv-orlando has joined #openstack-meeting-309:10
*** cbader has quit IRC09:10
*** egallen has joined #openstack-meeting-309:11
*** cbader has joined #openstack-meeting-309:11
*** yamamoto has quit IRC09:12
*** cbader has quit IRC09:14
*** yamamoto has joined #openstack-meeting-309:15
*** stanzgy has quit IRC09:17
*** egallen has quit IRC09:21
*** sarob has quit IRC09:22
*** salv-orlando has quit IRC09:32
*** salv-orlando has joined #openstack-meeting-309:32
*** yamamoto has quit IRC09:33
*** JeanBriceCombebi has quit IRC09:34
*** JeanBriceCombebi has joined #openstack-meeting-309:34
*** salv-orlando has quit IRC09:35
*** salv-orlando has joined #openstack-meeting-309:36
*** etoews has joined #openstack-meeting-309:39
*** sahid has quit IRC09:41
*** yamamoto has joined #openstack-meeting-309:42
*** etoews has quit IRC09:43
*** salv-orlando has quit IRC09:45
*** salv-orlando has joined #openstack-meeting-309:46
*** jtomasek has quit IRC09:46
*** yamamoto has quit IRC09:46
*** JeanBriceCombebi has quit IRC09:49
*** salv-orl_ has joined #openstack-meeting-309:49
*** sahid has joined #openstack-meeting-309:50
*** salv-orl_ has quit IRC09:51
*** salv-orlando has quit IRC09:51
*** salv-orlando has joined #openstack-meeting-309:51
*** obondarev_ has quit IRC09:55
*** obondarev has joined #openstack-meeting-309:56
*** salv-orlando has quit IRC09:56
*** markvoelker has joined #openstack-meeting-309:56
*** salv-orlando has joined #openstack-meeting-309:56
*** mattgriffin has quit IRC09:58
*** evgenyf has joined #openstack-meeting-309:58
*** markvoelker has quit IRC10:02
*** jtomasek has joined #openstack-meeting-310:02
*** yamahata has quit IRC10:15
*** obondarev has quit IRC10:25
*** obondarev_ has joined #openstack-meeting-310:25
*** abramley has quit IRC10:27
*** zz_johnthetubagu is now known as johnthetubaguy10:28
*** egallen has joined #openstack-meeting-310:28
*** abramley has joined #openstack-meeting-310:30
*** evgenyf has quit IRC10:32
*** yamamoto has joined #openstack-meeting-310:33
*** yamamoto has quit IRC10:38
*** etoews has joined #openstack-meeting-310:39
*** etoews has quit IRC10:44
*** yamamoto has joined #openstack-meeting-310:52
*** yamamoto has quit IRC10:58
*** obondarev_ has quit IRC10:59
*** Piet has quit IRC11:00
*** obondarev has joined #openstack-meeting-311:00
*** yamamoto has joined #openstack-meeting-311:00
*** yamamoto has quit IRC11:02
*** JeanBriceCombebi has joined #openstack-meeting-311:03
*** Yi has joined #openstack-meeting-311:05
*** kbyrne has quit IRC11:09
*** Yi has quit IRC11:10
*** kbyrne has joined #openstack-meeting-311:13
*** pkoniszewski has quit IRC11:13
*** stanzgy has joined #openstack-meeting-311:18
*** amotoki has quit IRC11:20
*** egallen has quit IRC11:21
*** stanzgy has quit IRC11:23
*** evgenyf has joined #openstack-meeting-311:24
*** stanzgy has joined #openstack-meeting-311:25
*** robcresswell has joined #openstack-meeting-311:36
*** jtomasek has quit IRC11:39
*** jcoufal has joined #openstack-meeting-311:41
*** jtomasek has joined #openstack-meeting-311:43
*** JeanBriceCombebi has quit IRC11:55
*** akrivoka has joined #openstack-meeting-311:59
*** rbertram has joined #openstack-meeting-312:03
*** bradjones has joined #openstack-meeting-312:03
*** sambetts has joined #openstack-meeting-312:06
*** obondarev_ has joined #openstack-meeting-312:07
*** obondarev has quit IRC12:09
*** jtomasek has quit IRC12:12
*** rdopiera has joined #openstack-meeting-312:13
*** jtomasek has joined #openstack-meeting-312:17
*** obondarev_ has quit IRC12:18
*** salv-orlando has quit IRC12:20
*** bradjones has quit IRC12:21
*** pkoniszewski has joined #openstack-meeting-312:26
*** jtomasek has quit IRC12:27
*** egallen has joined #openstack-meeting-312:28
*** jtomasek has joined #openstack-meeting-312:29
*** amotoki has joined #openstack-meeting-312:37
*** jtomasek has quit IRC12:46
*** lblanchard has joined #openstack-meeting-312:46
*** kashyap has quit IRC12:47
*** seizadi has joined #openstack-meeting-312:50
*** jpomero has joined #openstack-meeting-312:52
*** egallen has quit IRC12:53
*** seizadi1 has joined #openstack-meeting-312:54
*** seizadi has quit IRC12:54
*** seizadi has joined #openstack-meeting-312:58
*** seizadi1 has quit IRC12:59
*** seizadi1 has joined #openstack-meeting-313:01
*** seizadi has quit IRC13:02
*** baoli has joined #openstack-meeting-313:03
*** baoli has quit IRC13:04
*** baoli has joined #openstack-meeting-313:05
*** seizadi1 has quit IRC13:05
*** seizadi has joined #openstack-meeting-313:05
*** jaypipes has joined #openstack-meeting-313:05
*** fwdit has joined #openstack-meeting-313:07
*** yamamoto has joined #openstack-meeting-313:08
*** fwdit has quit IRC13:10
*** markvoelker has joined #openstack-meeting-313:11
*** seizadi has quit IRC13:11
*** Yi has joined #openstack-meeting-313:12
*** seizadi has joined #openstack-meeting-313:13
*** egallen has joined #openstack-meeting-313:14
*** VW_ has joined #openstack-meeting-313:14
*** VW_ has quit IRC13:14
*** VW_ has joined #openstack-meeting-313:14
*** jtomasek has joined #openstack-meeting-313:15
*** JeanBriceCombebi has joined #openstack-meeting-313:16
*** obondarev has joined #openstack-meeting-313:17
*** zigo has quit IRC13:18
*** zigo has joined #openstack-meeting-313:20
*** Yi has quit IRC13:21
*** salv-orlando has joined #openstack-meeting-313:25
*** seizadi has quit IRC13:26
*** seizadi has joined #openstack-meeting-313:27
*** marg7175 has joined #openstack-meeting-313:31
*** marg7175 has quit IRC13:39
*** seizadi has quit IRC13:41
*** tmazur has quit IRC13:44
*** VW_ has quit IRC13:51
*** JeanBriceCombebi has quit IRC13:51
*** ttrifonov is now known as zz_ttrifonov13:56
*** VW_ has joined #openstack-meeting-313:57
*** yamamoto has quit IRC14:00
*** jckasper_ has quit IRC14:00
*** JeanBriceCombebi has joined #openstack-meeting-314:00
*** annegent_ has joined #openstack-meeting-314:01
*** mattgriffin has joined #openstack-meeting-314:03
*** akrivoka has quit IRC14:04
*** yamamoto has joined #openstack-meeting-314:08
*** gulic has quit IRC14:16
*** annegent_ has quit IRC14:18
*** annegent_ has joined #openstack-meeting-314:19
*** peristeri has joined #openstack-meeting-314:25
*** jckasper has joined #openstack-meeting-314:26
*** evgenyf has quit IRC14:27
*** VW_ has quit IRC14:28
*** sambetts has left #openstack-meeting-314:30
*** pkoniszewski has quit IRC14:33
*** peristeri has quit IRC14:38
*** jgrimm is now known as zz_jgrimm14:38
*** Yi has joined #openstack-meeting-314:38
*** baoli has quit IRC14:39
*** baoli has joined #openstack-meeting-314:39
*** peristeri has joined #openstack-meeting-314:40
*** VW_ has joined #openstack-meeting-314:41
*** baoli has quit IRC14:42
*** peristeri has quit IRC14:43
*** seizadi has joined #openstack-meeting-314:43
*** baoli has joined #openstack-meeting-314:43
*** peristeri has joined #openstack-meeting-314:43
*** seizadi has quit IRC14:47
*** mrmartin has joined #openstack-meeting-314:59
*** salv-orlando has quit IRC15:00
*** Piet has joined #openstack-meeting-315:01
*** armax has joined #openstack-meeting-315:01
*** salv-orlando has joined #openstack-meeting-315:02
*** egallen has quit IRC15:02
*** evgenyf has joined #openstack-meeting-315:03
*** nelsnelson has joined #openstack-meeting-315:05
*** egallen has joined #openstack-meeting-315:07
*** roaet has joined #openstack-meeting-315:08
*** thangp has joined #openstack-meeting-315:10
*** jmeridth has joined #openstack-meeting-315:13
*** MarkAtwood has joined #openstack-meeting-315:13
*** sigmavirus24_awa is now known as sigmavirus2415:16
*** marun has joined #openstack-meeting-315:17
*** fischerw has joined #openstack-meeting-315:19
*** zz_jgrimm is now known as jgrimm15:22
*** dkehn has joined #openstack-meeting-315:22
*** ihrachyshka has joined #openstack-meeting-315:24
*** Piet has quit IRC15:29
*** markmcclain has joined #openstack-meeting-315:30
*** pc_m has joined #openstack-meeting-315:30
mesteryAnyone here for the neutron drivers meeting?15:30
markmcclaino/15:30
jmeridtho/15:30
armaxyo15:30
*** rdopiera has left #openstack-meeting-315:30
ihrachyshkao/15:30
roaeto/15:30
* pc_m lurking15:30
marunhi15:30
mesteryCool! Lets get started :)15:31
amotokihi15:31
mestery#startmeeting neutron_drivers15:31
openstackMeeting started Wed Feb 18 15:31:05 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.15:31
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:31
*** openstack changes topic to " (Meeting topic: neutron_drivers)"15:31
openstackThe meeting name has been set to 'neutron_drivers'15:31
mestery#link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda15:31
mesteryThe only thing to discuss is based on the email armax sent yesterday15:31
mestery#link http://lists.openstack.org/pipermail/openstack-dev/2015-February/057196.html15:31
mestery#topic Patch Discussion15:31
*** openstack changes topic to "Patch Discussion (Meeting topic: neutron_drivers)"15:31
armaxmestery: is there’s any other item to discuss I am happy to hear it15:31
mesteryarmax: dougwig had something, though we'll get to that at the end15:31
armaxmestery: cool15:32
* mestery realizes dougwig may still be in bed15:32
mesteryOK, lets get started with the first patch on the list15:32
mestery#link https://review.openstack.org/#/c/155373/15:32
*** devlaps has joined #openstack-meeting-315:32
armaxihrachyshka: you around?15:32
mesteryThis is the monkey patch from ihrachyshka.15:32
ihrachyshkaarmax, sure15:32
salv-orlandoLOH15:32
ihrachyshkaI think markmcclain concerns are really valid and this one needs discussion, hence email thread and we discussing it here :)15:33
mesteryExcellent!15:33
ihrachyshkaafaik markmcclain wants us to look at getting rid of eventlet15:33
ihrachyshkawhich I support with all my heart15:33
armaxI like amotoki’s proposal15:33
mesteryThat seems like a good goal to have :)15:33
ihrachyshkaand we should look into doing some work around it the next cycle (i'm in)(15:34
markmcclaincool15:34
ihrachyshkathat said, I think the patch series is worth going now, for they fix potential issues15:34
armaxihrachyshka: not sure how straightforward or realistic it is to get rid of eventlet at this point15:34
ihrachyshkaand actually allows us to consider switching to threading model case by case later15:34
*** egallen has quit IRC15:34
*** egallen_ has joined #openstack-meeting-315:34
ihrachyshkasince we will have more clear view of what's patched15:34
markmcclainright I do think a measured approach is best15:34
armaxihrachyshka: that sounds like a plan to me15:34
ihrachyshkaarmax, I updated patches as per amotoki comments15:35
armaxihrachyshka: cool15:35
markmcclainlooking at amotoki's comment is a good suggestion15:35
ihrachyshkaright, you can all check latest upload, it uses 'dumb' main()s15:35
salv-orlandothat makes sense to me as well15:35
markmcclainthe only lingering question is what about some of hte plugin agents15:35
markmcclaingiven that we're trying to spin them out15:35
mesteryThat's a good point markmcclain15:36
markmcclainis moving their mains into the cmd sub tree .. something we want?15:36
ihrachyshkaI guess some/most of them will stay for kilo?15:36
mesterymarkmcclain: You're talking about LB and OVS agents with regards to ML2 right?15:36
ihrachyshkamestery, there are other vendor plugins as well15:36
markmcclainall of them15:36
armaxmarkmcclain: I don’t think we have to worry about all of them15:36
ihrachyshka(btw some vendor agents are not actually patched, like mellanox015:36
salv-orlandois this really a blocker?15:36
marunall of them?15:36
amotokiI think htere are two options: in-tree or handle it in their trees.15:36
markmcclainsalv-orlando: not a blocker15:37
mesteryamotoki: ++15:37
markmcclainjust want to make sure we have clear plan15:37
amotokiif they want to keep something in tree, they need to follow neutron convention.15:37
ihrachyshkaamotoki++15:37
ihrachyshkawhich is I guess will be 'a dumb main calling proper main that is located wherever they want'15:37
markmcclain+1 to dumb mains for plugins15:37
salv-orlandoamotoki: well, the thing is that eventually everything will go out of tree. And vendor agent should be out of tree by the end of htis release cycle15:37
ihrachyshkafor reference, list of plugins switching: https://review.openstack.org/15541215:38
armaxihrachyshka: right, but I would personally leave it to the plugin maintainer to take any action on this regard15:38
salv-orlandoso I guess it probably does not matter if we don't worry at all about patching them or not15:38
markmcclainso ihrachyshka could we roll them into one file?15:38
ihrachyshkaarmax, leaving them with potential regressions introduced instead of handling patching uniformly? I don't think it's a great idea.15:38
armaxihrachyshka: if and when they observe the issue, they’ll have to follow the practice we’re putting in place to avoid the eventlet snafus15:38
*** egallen_ has quit IRC15:39
ihrachyshkamarkmcclain, you mean, having single py file with multiple dumb main()s?15:39
markmcclainihrachyshka: yes15:39
markmcclainbasically have the dummy import the plugin module and then exec the main15:39
ihrachyshkasalv-orlando, afaik we give them chance to stay till Liberty15:39
ihrachyshkamarkmcclain, that means lots of unneeded imports15:39
mesteryihrachyshka: That's right, they have until Liberty15:39
markmcclainihrachyshka: not really15:39
markmcclainthe import would be inside of the dummy main15:40
armaxmarkmcclain: I don’t like the idea, it’s an overkill IMO15:40
markmcclainso only exec would the import actually occur15:40
salv-orlandoihrachyshka: might be. but they should enter the deprecation path, which is irreverisible afaict15:40
ihrachyshkaok, that's an option. not sure whether we'll need to tweak pep8 for that, but sounds good to me15:40
markmcclainihrachyshka: pep8 should allow it15:40
ihrachyshkaI'm with armax on this, but really anything works for me15:40
salv-orlandosingle file it might be ok for me... what's the advantage over multiple files (beyond having all the mains in one place)15:41
armaxihrachyshka: I would worry about what we can right now…which is the basic stuff15:41
armaxihrachyshka: lb, ovs agents, l3, dhcp, meta and server15:41
markmcclainit's more all of the boilerplate files added in 15541215:41
armaxihrachyshka: once we have line of action is clear, we can recommend through devref what needs to be done for eventlet15:42
armaxand people who care need to follow suit15:42
* dougwig groggily approaches his keyboard...15:42
ihrachyshkaarmax, sure, I'll make a note in my todo to update devref15:43
armaxso I don’t think that https://review.openstack.org/#/c/155412/ is needed, and I fear it messes us with the decomp efforts15:43
ihrachyshkaso, what's the end result of this? we're ok with the patches, right? should I merge mains?15:43
markmcclainI'm fine with the chain of patches up until '41215:44
ihrachyshkaarmax, well, in theory if we want to go threading route, we'll need to set unit tests running without monkey patching to check how we deal without it15:44
ihrachyshkaarmax, and then having eventlet.monkey_patch() isolated (and avoided in that test run) would be a good thing15:44
markmcclainihrachyshka: if we're doing things right.. our unit tests shouldn't need eventlet15:45
*** carl_baldwin has joined #openstack-meeting-315:45
markmcclainand it should be transparent15:45
*** carl_baldwin has quit IRC15:45
marunthat's a pretty big 'if'15:45
dougwigyou're right, BUT...15:45
ihrachyshkamarkmcclain, I think until we run services with eventlet in production, we want patched run to be the default15:45
amotokiwe have seeveral unit tests which uses eventlet threads15:45
markmcclainright well the ones that need eventlet are functional tests and we should ID them for moving in L15:45
salv-orlandomarkmcclain: the unit tests which started a task manager based on eventlet are not there anymore ;)15:45
*** carl_baldwin has joined #openstack-meeting-315:46
ihrachyshkaideally, I would have monkey_patch() call in just two places - for services and for tests.15:46
ihrachyshkaand then introduce a switch to disable it for the latter15:46
ihrachyshkaand be able to get results for unpatched mode15:47
salv-orlandoanyway, to amotoki's point there is still code in neutron server and agents which explicitly uses eventlet, and it's covered by unit tests. For instance the threadpool started in the l3 agent15:47
marunihrachyshka: I think our unit tests are bad enough that removing the requirement for eventlet is going to be an uphill battle.  But they *shouldn't* need to be patched if they were sane.15:47
ihrachyshkawith calls spread thru the code base, and tests importing the code, we don't have an easy way to achieve this15:47
salv-orlandomarun: that's point I made on the mailing list, agree with that15:47
ihrachyshka...uphill battle... sounds like smth I need to get involved15:47
markmcclainthe good thing is that we don't have to fix them today, but at least collectively decide as a team that is where we want to be at the end of L or M15:48
*** Sukhdev has joined #openstack-meeting-315:48
ihrachyshkaok, what's the plan for plugins? dropping the patch and leaving them explicitly patch themselves?15:48
armaxihrachyshka: I would be in favor of this15:49
markmcclainleave the plugins as is?15:49
armaxat least for now15:49
ihrachyshkaI would better stick to uniform approach for everything in the tree, but you decide15:49
*** peristeri has quit IRC15:49
*** cbader has joined #openstack-meeting-315:49
ihrachyshkaok, I'm in minority, and we'll get back to it once we really consider switching to threads15:49
dougwigwe're focused on eventlet, but isn't this really a meta-argument about DRY+magic versus explicit coding?  which is always a judgement call, and I have a mild preference for explicit _in this one case_.15:49
ihrachyshkadougwig, we don't want to bound ourselves to eventlet, it will die, and we don't want to follow it15:50
*** peristeri has joined #openstack-meeting-315:50
ihrachyshkaso the fewer explicit eventlet/greenthread usages in the tree, the better15:50
markmcclaindougwig: very much an argument of explicit vs magic :)15:50
amotokiihrachyshka: i prefre your patch. If they exists in the tree, it is better to do the same way.15:50
armaxso, ihrachyshka: of the 5 patches that are now targeting bug 1418541, is there anything else to be posted?15:51
openstackbug 1418541 in neutron "processutils checks whether stdlib is monkey patched during import" [Undecided,In progress] https://launchpad.net/bugs/1418541 - Assigned to Ihar Hrachyshka (ihar-hrachyshka)15:51
dougwigihrachyshka: right, but i don't think this is discussion is about eventlet at all.15:51
ihrachyshkaarmax, I was going to move wsgi monkey patching under the same umbrella15:51
armaxso it sounds like there is still something pending?15:51
ihrachyshkajust one patch. also I will need to understand why some non-entry point files do monkey_patching15:52
ihrachyshkalike neutron/plugins/ml2/drivers/cisco/apic/apic_topology.py15:52
ihrachyshkabut that's a separate story15:52
armaxok15:52
mesterySo, approaching the halfway point here, did we reach some consensus on this patch series now?15:53
*** bpokorny has quit IRC15:53
*** pasha117 has quit IRC15:53
armaxmy understanding is that of the https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1418541,n,z we need to unblock the top of the chain, and drop the last one15:53
markmcclain+115:54
mesteryarmax: That's what I took from this too.15:54
armaxthen ihrachyshka will complete the work with yet another patch15:54
ihrachyshkaok, I'll mark the last one as WIP15:54
amotokias far as I understand, (a) neutron/cmd/eventelet seems reasonable, (b) all patches including vendor agents are okay, (c) apply monkey patch in tests/__init__15:54
armaxplus a devref one, if he wants to do it separately15:54
salv-orlandosounds good to me15:54
amotokiam not sure about (c).15:54
ihrachyshkaamotoki, I guess (b) was not the case?...15:54
amotokiis my understanding on (b) correct?15:54
ihrachyshkapeople are against it15:55
ihrachyshkahence WIP for the patch15:55
ihrachyshkaright?15:55
mesteryihrachyshka: Right, that's what I understood15:55
armaxamotoki: I think the suggestion was to leave them for now and have the agents follow the practice explicitely should they see the isuse15:55
armaxissue15:55
armaxwe’re seeing with the reference elements15:55
salv-orlandowe can  argue whether patch tests/__init__.py in a separate discussion - to happen on gerrit which is the right place for them15:56
armaxsalv-orlando: agreed15:56
ihrachyshkaack15:56
salv-orlandounless you think that going to gerrit means automatically getting blocked on a -215:56
salv-orlandobut that's not the case I believe15:56
mesteryRight, lets discuss on gerrit for that one15:56
mesteryShall we move on to patch #2 now?15:56
salv-orlandoyes for me15:57
amotokilet's go15:57
armaxmestery: yup15:57
ihrachyshkasure15:57
markmcclainI've added my +2 for most of the series now that we have a plan15:57
mestery#link https://review.openstack.org/#/c/148318/15:57
mesterymarkmcclain: Thanks!15:57
ihrachyshkamarkmcclain, thanks!15:57
mesteryNext patch is the CLI extension for neutronclient15:57
armaxroaet: you there?15:57
roaetAye15:57
*** insequent has joined #openstack-meeting-315:58
salv-orlandoI've read the comments in the review. I kind of agree with the statement on openstack client, but...15:58
*** yamahata has joined #openstack-meeting-315:58
salv-orlandomy question is: if we add this feature in neutronclient now, are we making it worse? are we causing any harm?15:58
salv-orlandoor wasting our time?15:58
armaxI think none of the above15:58
dougwigi have one question.  which client/CLI will be documented here: http://docs.openstack.org/kilo/install-guide/install/apt/content/ ?15:58
markmcclainsalv-orlando: well teh neutronclient is already a steaming pile15:58
mesteryI don't know how htis could make it worse or cause harm.15:58
roaetI don't believe that there is harm, and we'll probably be saving time as there are already people planning to add things to it.15:59
mesterydougwig: That link doesn't work for me, so the answer is none.15:59
dougwigi did say "will be".  :)15:59
armaxit sounds to me that at none of the recent summits we ever talked _seriously_ about the client15:59
mesterydougwig: Is the openstackclient ready to take on the work of python-neutronclient in Kilo? If the answer is no, then it's python-neutronclient.16:00
markmcclainarmax: we had full session in Paris with dtroyer16:00
marunI don't think we can afford to block ourselves on somedays.16:00
mesterymarun: ++16:00
armaxmarkmcclain: about the neutron client?16:00
dougwigthat's what i'm asking.  we've heard "they're ready" from both sides.  which his going to be in the official docs?16:00
markmcclainyes16:00
dougwig /his/is/16:00
*** marg7175 has joined #openstack-meeting-316:00
markmcclaindougwig: prob have to ping annegent_ or another member of her team and see what their plans are16:01
* armax wonder what was the outcome of that16:01
salv-orlandoso markmcclain if I get your point right you'd rather see roaet's work to land directly on openstackclient?16:01
markmcclainarmax: the outcome of the session was that we'd be putting resources on the openstack client16:01
markmcclainsalv-orlando: yes16:01
salv-orlandoroaet: have you considered that option?16:01
armaxmarkmcclain: ah, ok, so the usual wishful thinking but nothing serious :)16:01
marunmarkmcclain: so why is this the first time this is coming to everyone's attention?16:01
roaetBut there are providers whose users still use neutronclient16:01
mesterySo, what I'm hearing is, the openstackclient is ready to deprecate python-neutronclient in Kilo?16:01
mesteryHow did I miss this until this moment?16:01
marunmarkmcclain: If this is a priority, where is it on the list of our priorities for this cycle?16:01
amotokii think we agreed that python sdk improvement should be done in openstacksdk and gradually migrate to openstack-cli.16:02
roaetsalv-orlando: aye, it is not feasible to release at the moment.16:02
amotokibut we didn't decide we deprecate neutronclient in kilo.16:02
salv-orlandowell to roaet point I have to agree that we've not eol-ed python-neutronclient yet, nor freezed it16:02
marunmarkmcclain: nothing about what your telling us suggests that it is going to happen this cycle.16:02
dougwigis this, openstackclient is the client for kilo, and let's not waste time?  or was it, let's do this, like putting py33 as a default env in tox, and hope for unicorns?16:02
marunmarkmcclain: and that doesn't suggest that we should block legitimate enhancements.16:02
mesteryI'm hear to say that I am not deprecating python-neutronclient in Kilo16:02
salv-orlandoI'm speaking from a user expectation perspective. I know it's a pile of <put your denigrative substantive here>16:02
mesteryBecause honestly, this is the first I'm hearing of "the openstackclient is ready to deprecate the other clients"16:03
mesteryHow can we deprecate it at this point in kilo?16:03
dougwigmestery: +116:03
mesterySo, lets move past that argument16:03
markmcclainwe can collectively decide to announce it's deprecation16:03
mesterypython-neutronclient will be around for Kilo16:03
mesteryRight, but it will be there for Kilo16:03
marunmarkmcclain: it's definitely too late for this cycle though.16:03
markmcclaindeprecation doesn't mean we're killing the code today16:03
marunmarkmcclain: maybe for lemming16:03
markmcclainit's never too late16:04
amotokidoes anyone check the status of openstack client support stauts of neturon?16:04
markmcclaindeprecation just signals we're done making substantial changes to it16:04
armaxso I am still unclear as to what the openstack client is and is not16:04
salv-orlandoI have unfortunately no idea atm on whether we can replace our client with openstackclient. If anyone can share some info on that it might be useful. It seems that this is indeed the gist of the discussion.16:04
marunmarkmcclain: I think you'll have to make a better case than I've heard thus far.16:04
armaxisn’t it just a proxy for the other clients?16:04
mesteryhttp://youtu.be/lL2ZwXj1tXM16:04
roaetFrom my understanding and from the docs, it does what the python clients do.16:04
mestery:)16:04
armaxand the other clients need to uniform so that the life of the proxy is easy?16:04
mesteryarmax: That's what I thought it was16:05
armaxif my understanding is correct, I am not sure we can ever talk of deprecating the neutronclient16:05
armaxor any other client for that matter16:06
dougwigthere are separate sdk and cli packages, the cli is further along, and i'm guessing that the plan is to have the cli use the sdk when it's ready?16:06
roaetFrom my conversations with the SDK team the OSC will consume the SDK when it's ready16:06
markmcclaindougwig: maybe.. wish dean was online for that bit16:06
amotokiarmax: yes. openstackclient calls python-*client libraries in general. it is just a replacement of CLI16:06
roaetbut the SDK team has admitted to not being ready16:06
mesteryroaet: Yes, in the review no less16:06
briancurtin^that's the plan - OSC is currently on *clients, ideally is backed by SDK16:06
salv-orlandoI have to admit this thing about proxying has always baffled me. It was my impression too, but then dtroyer in Paris said it was self-sufficient. so yes, I'm a bit confused16:06
armaxjust because of that confusion I don’t think we can warrant the stoppage of any feature development on the client16:07
annegent_and from a docs perspective, we are interested in switching to openstack CLI16:07
annegent_install one instead of many16:07
mesteryCan anyone confirm if openstack CLI is just proxying existing clients as armax has suggested then?16:08
roaetAssuming OSC was self-sufficient, does that mean we should still abandon providers whose users require neutronclient.16:08
dougwigannegent_: what's the timing on that change?16:08
mesteryIf so, then isn't this discussion moot at this point?16:08
salv-orlandoarmax: I think if we insist in python-neutronclient vs openstackclient we won't agree on anything16:08
amotokimestery:  *client has both CLI and libs and OSC consumes libs from *client.16:08
mesteryroaet: We'd have a deprecation process16:08
markmcclainso the OSC has it's own command structure16:08
*** Piet has joined #openstack-meeting-316:08
markmcclainbut is using teh http client form our backend16:08
annegent_dougwig: we're concerned about Keystone v3 and nova not supporting domains, but that shouldn't prevent us from documenting openstack CLI, just where it's documented16:08
marunmestery: I'm not sure how it could do otherwise.  It would be quite an effort to recreate the client, as steaming a pile as it might be.16:08
salv-orlandoI think the right question to ask is whether adding features to python-neutronclient is a bad idea or not.16:08
roaetmestery: Aye. We are not prepared to immediately deprecate neutronclient.16:08
dougwigannegent_: are you planning that switch in K, L, ?16:09
markmcclainsalv-orlando: that is the real question16:09
annegent_dougwig: discussing for K16:09
salv-orlandomarkmcclain: I think it depends on the criticality of the feature. Of which I am unsure. But then roaet can add something on this.16:09
armaxsalv-orlando: correct, my take is, until we have a crystal clear clarity on the matter I don’t think we can afford stopping work from happening, especially if the work is ready to go in16:10
*** stanzgy has quit IRC16:10
*** evgenyf has quit IRC16:10
armaxand to me the sticking point here is the service-split16:10
roaetGiven our users' dependency on the client, to us it is critical for providing features they demand.16:10
markmcclainarmax: this work is not ready to go it16:10
dougwigmarkmcclain: it'll never get there with a -2.16:11
amotokii don't think it can be deprecated in K, and exnteison mechanism helps services implement their commands.16:11
markmcclainarmax: there are techical changes required16:11
armaxmarkmcclain: agreed, but it would be nice once it is, that the adv services side of the client would follow the same structure16:11
mesteryamotoki: Right, we are not deprecating the client in Kilo, though it sounds like we can do that in Liberty.16:11
amotokimestery: agree for L.16:12
armaxso that the adv service folks can innovate on the client side at the same speed they can do on the server side16:12
*** jcoufal has quit IRC16:12
*** jcoufal_ has joined #openstack-meeting-316:12
marunmarkmcclain: the issue is 'can it go in once ready', not 'in its current form'16:12
markmcclainarmax: well that's another reason to put the impetus behind the OSC16:12
armaxmarkmcclain: or at least this is mine of whishful thinking16:12
roaetI believe we can live with deprecation in L.16:12
mesteryroaet: Excellent!16:12
markmcclainuntil we contrib resources towards it will never be there16:12
marunmarkmcclain: the +2's on the patch were more an indication of dissent around your view that it shouldn't go forward at all16:12
armaxmarkmcclain: right, but we gotta be realistic that the split is well under way, whereas OSC is nowhere near16:12
salv-orlandoI think the only problem with roaet's work is that it should have been available 2 years ago16:12
mesteryroaet: Because that means it will be there in L, and removed in M16:12
roaetsalv-orlando: It took me 6 months to get a 1 line change into the client.16:12
mesterysalv-orlando: lol16:12
armaxmarkmcclain: so to me roaet’s efforts sound like a good compromise, or bridge-solution16:13
mesteryroaet: How did you get that merged so quickly? ;)16:13
roaetmestery: hahaha16:13
* mestery beat salv-orlando to the punch there16:13
dougwigmestery: way to pour salt in the wounds, there.  :)16:13
mesterydougwig: I recently attended sensitivity training, can you tell? :D16:14
roaetmestery: with extensibility added to the client even if we cannot handle deprecation, we can at least bridge the gap between missing features.16:14
mesteryroaet: Makes sense16:14
salv-orlandoseriously, my opinion is that unless there are technical flaws it is a feature that should be in the client if we're planning to use it at least for 6 more months.16:14
marun+116:14
mestery+116:14
dougwig+116:14
amotoki+116:14
salv-orlandoand for technical flaws I end to trust my peers who +2'ed the patch...16:14
mestery+116:15
salv-orlandobut since another very respected peer -2'ed and is claiming technical flaws we might better discuss those16:15
markmcclainit re-implements entrypoints16:15
marunsalv-orlando: I think there are things that need to be fixed in the patch, as per markmcclain's most recent comment16:15
armax+116:15
mesterymarun: Right!16:15
marunsalv-orlando: but once those are fixed it should be mergeale16:15
dougwigthat's -1 worth for sure, let's get it fixed.16:15
roaetmarkmcclain and amotoki have brought up technical issues, I will gladly fix.16:15
marunmergeable16:15
salv-orlandoand stop talkign python-neutronclient vs openstackclient. That discussion is not useful for this release cycle.16:15
mesteryroaet: Awesome!16:15
mesterysalv-orlando: The voice of reason16:15
mestery;)16:16
amotokiwe are discussng two things: client lib and CLI. I am not sure which migration should happen first.16:16
markmcclainso fixing the technical issues is fine, but the bigger issue that we'll never get off our crappy client16:16
salv-orlandomestery: If I could speak reason without typos it would be even better ;)16:16
markmcclainuntil we as a team work better with the SDK/OSC folks16:16
amotoki at least regarding on service split, we have client lib implementation as an extension and it makes the migration  easier16:16
mesterymarkmcclain: In parallel, I think we can start doing better on that front for sure. Certainly we'll all agree to that I think.16:16
roaetmarkmcclain: I have been speaking to my product folks to prioritize support into SDK16:16
salv-orlandomarkmcclain: so your vote is to deprecate client in Kilo and move this work to the openstackclient?16:16
markmcclainroaet: awesome16:17
roaetmarkmcclain: that should hopefully give a lot more resources from rax.16:17
briancurtinmarkmcclain: i'm going to write up some status on SDK+OSC so this whole story is a bit more clear16:17
dougwigmarkmcclain: that argues for a transition plan, not a full stop.16:17
markmcclainyeah.. I'd be ok making this the last bigger feature we put in our client :)16:17
salv-orlandobriancurtin: yes, this will help a lot lazy people like me16:17
mesterysalv-orlando: Not deprecate in Kilo, but in Liberty.16:17
markmcclaindougwig: transition plan is a perfect outcome here16:17
salv-orlandomarkmcclain, roaet, mestery: it seems we're starting to see a consensus then. We can address technical comments, merge this feature.16:18
roaetmarkmcclain: mestery: with a deprecation schedule we can assess the risks and appropriate resources to make the transition16:18
salv-orlandoAnd then freeze python-neutronclient16:18
marunmarkmcclain: agreed that we need to focus attention on it.16:18
mestery++16:18
markmcclainmestery: I think we can announce the lib as deprecated at the kilo release and say it will be supported for at least 12mos16:18
marunmarkmcclain: it needs to be identified as a priority and have resources dedicated to it16:18
mesterymarkmcclain: I'm fine with that to be honest, but lets make that call near Kilo-3.16:18
marunmarkmcclain: we should make sure to talk about that in vancouver16:18
mesterymarun: ++16:18
mesteryResources are key16:18
*** carl_baldwin_ has joined #openstack-meeting-316:19
mesteryExcellent!16:19
amotokimarkmcclain: agreed. at least we need to annoucen to dev community.16:19
*** carl_baldwin has quit IRC16:19
*** carl_baldwin_ is now known as carl_baldwin16:19
mesteryI think we have a way forward.16:19
mesteryAnd with 10 minutes left even! ;)16:19
armaxand with 10 minutes to spare :)16:19
mesteryAnything else on the client to discuss?16:19
roaetdid dougwig have something?16:19
marunI'm not really clear on setting a deprecation schedule ahead of having resources to do the work...16:19
dougwigroaet: not on the client. i think we're good there.16:20
mesterymarun: We'll reevaluate deprecation near Kilo-3, we're not saying it will be deprecated in Kilo at this point. Fair enough?16:20
marunmestery: fair enough16:20
*** rhagarty has joined #openstack-meeting-316:20
roaetmarkmcclain: offline I would appreciate technical direction for how you'd want me to replace the entrypoint things16:21
mesteryOK16:21
mestery#topic Open Discussion16:21
*** openstack changes topic to "Open Discussion (Meeting topic: neutron_drivers)"16:21
roaetamotoki: same.16:21
mestery9 minutes left folks16:21
mesteryAnything else today?16:21
dougwigdrivers (and others), I'd appreciate any early feedback on this spec: https://review.openstack.org/#/c/154736/16:21
markmcclainroaet: sure.. will follow up with email later today16:21
dougwigsplitting a lib out of neutron.16:21
roaetmarkmcclain: thanks16:21
dougwigthe current state of affairs is... painful.16:21
*** marg7175 has quit IRC16:22
markmcclaindougwig: painful is too nice of a word16:22
salv-orlandodougwig: bottom line for me is that it is really painful to have a dependency on something which is not stable at all.16:22
mesterylol16:22
salv-orlandoon the other hand I suspect this task is far from being simple16:22
*** marg7175 has joined #openstack-meeting-316:22
marundougwig: I'll comment on the review, but my concern is that stable interfaces and separating things out don't necessarily need to be conflated.16:22
salv-orlandoone risk that I see is that we'll just push the problem from neutron to neutron-lib16:22
marun+116:23
salv-orlandomaking neutron development painful as well16:23
marunwell, that's the point16:23
dougwigkyle wanted to wait for the summit, but if there's any chance that I can get a hint at if that's the right direction, I can start doing some of the early work.  if it's a 90 degree tangent, then I don't want to waste my time.16:23
salv-orlandobut at least we'll share the pain ;)16:23
marunsalv-orlando: so that we have skin in the game too16:23
marunyeah16:23
dougwigmarun: it can't be a mindless split, which is why we can't do it in one-step.  agree.16:23
marundougwig: I don't think it's a tangent, something needs to be done.16:23
marundougwig: I think focusing on stable interfaces as the goal is important.16:23
marundougwig: if splitting things out aid in that, yay.16:23
marundougwig: if not, well...16:24
dougwigevery piece that's moved is going to have to be evaluated with, "is this a library module?  does it need new tests?"16:24
*** bpokorny has joined #openstack-meeting-316:24
marundougwig: we can as easily separate things in the tree16:24
dougwignot and put the results in pypi, so requirements.txt can be sane.16:24
marundougwig: we discussed that early in the cycle and got worn down by what the wsgi refactor might imply16:24
dougwigseparate repos means that in one we can say, "thou shalt not break method signatures", and in the other, "refactor, go nuts."16:25
marundougwig: I don't think that's enough.16:25
marundougwig: the only way that would work would be with co-gating.16:25
marundougwig: but i digress... let's discuss offline and in gerrit16:26
dougwigok, i'll find you later today.16:26
marundougwig: sounds good16:26
markmcclainI think we might have to wait because if we discuss spining out the ref impl into a separate project it radically changes things16:26
marunmarkmcclain: that suggests we wait on the split, and I'm ok with that16:26
marunmarkmcclain: I don't think we need to avoid working on interface stability for things that are used out of tree, though.16:27
dougwigif we agree in concept, and the first step is easy stuff like base exceptions, that let's us get through the weeks of paperwork to do things like the new repo, jenkins, etc...  that's the part that might be fast-trackable.16:27
mesterymarkmcclain: The discussion of the spinning out of ref implementation needs to happen in Vancouver for sure16:27
mesterydougwig: ++16:27
*** david-lyle_afk is now known as david-lyle16:28
markmcclaindougwig: should be fairly easy once we get direction on librarization16:28
markmcclainmaybe back burner this until K3 deadline passes?16:28
markmcclainit's really not that long of a wait16:28
mesterymarkmcclain: I'm fine with tabling it a bit, though I encourage folks to comment on the review as well, keeping in mind it's WIP16:28
dougwigas long as we keep talking about this.  that infra stuff has a tendency to take awhile, even when easy.16:29
markmcclainyeah.. comments are good on it16:29
*** mrmartin has quit IRC16:29
mesteryCool.16:29
roaetAre we at time? I had one more tiny thing to add about the client. <_<   >_>16:29
mesteryOK, we're at time now in a bit16:29
mesteryroaet: Lets move it to #openstack-neutron since we're at the end, ok?16:29
roaetmestery: ok16:29
roaetthank you all16:29
mesteryThanks to all for joining!16:29
mesteryGood discussion16:29
mestery#endmeeting16:30
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:30
openstackMeeting ended Wed Feb 18 16:30:05 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:30
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-02-18-15.31.html16:30
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-02-18-15.31.txt16:30
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-02-18-15.31.log.html16:30
*** pc_m has left #openstack-meeting-316:30
amotokithanks all16:30
salv-orlandoadieuuuu16:31
ihrachyshkao/16:31
*** armax has quit IRC16:32
*** armax has joined #openstack-meeting-316:33
*** peristeri has quit IRC16:34
*** sarob has joined #openstack-meeting-316:37
*** peristeri has joined #openstack-meeting-316:37
*** Yi has quit IRC16:39
*** roaet has left #openstack-meeting-316:40
*** jcoufal_ has quit IRC16:40
*** jtomasek has quit IRC16:42
*** mrmartin has joined #openstack-meeting-316:46
*** banix_ has joined #openstack-meeting-316:46
*** scheuran has quit IRC16:49
*** insequent has left #openstack-meeting-316:49
*** sarob has quit IRC16:55
*** sarob has joined #openstack-meeting-316:56
*** banix_ is now known as banix17:01
*** s3wong has joined #openstack-meeting-317:02
*** coolsvap is now known as coolsvap_17:03
*** Yi has joined #openstack-meeting-317:03
*** egallen has joined #openstack-meeting-317:03
*** seizadi has joined #openstack-meeting-317:04
*** mwang2 has joined #openstack-meeting-317:04
*** belmoreira has quit IRC17:05
*** megm_ has quit IRC17:05
*** annegent_ has quit IRC17:06
*** SridharRamaswamy has joined #openstack-meeting-317:06
*** megm has joined #openstack-meeting-317:06
*** egallen has quit IRC17:08
*** amotoki has quit IRC17:10
*** MaxV has quit IRC17:12
*** JeanBriceCombebi has quit IRC17:12
*** MaxV has joined #openstack-meeting-317:12
*** MaxV has quit IRC17:13
*** SridharRamaswamy has quit IRC17:13
*** MaxV has joined #openstack-meeting-317:13
*** JeanBriceCombebi has joined #openstack-meeting-317:14
*** SridharRamaswamy has joined #openstack-meeting-317:16
*** devvesa has quit IRC17:16
*** sarob has quit IRC17:17
*** MaxV has quit IRC17:18
*** ihrachyshka has quit IRC17:18
*** sarob has joined #openstack-meeting-317:18
*** MarkAtwood has quit IRC17:18
*** melwitt has joined #openstack-meeting-317:20
*** armax has quit IRC17:24
*** sahid has quit IRC17:31
*** bknudson has joined #openstack-meeting-317:33
*** matrohon has quit IRC17:34
*** JeanBriceCombebi has quit IRC17:35
*** marg7175 has quit IRC17:36
*** ivar-lazzaro has joined #openstack-meeting-317:37
*** seizadi has quit IRC17:38
*** seizadi1 has joined #openstack-meeting-317:38
*** ivar-laz_ has joined #openstack-meeting-317:39
*** alexsyip has joined #openstack-meeting-317:41
*** ivar-lazzaro has quit IRC17:42
*** seizadi1 has quit IRC17:43
*** seizadi has joined #openstack-meeting-317:44
*** alexsyip has quit IRC17:44
*** alexsyip has joined #openstack-meeting-317:46
*** alexsyip has quit IRC17:46
*** s3wong has quit IRC17:47
*** tosky has joined #openstack-meeting-317:47
*** Sukhdev has quit IRC17:50
*** Rockyg has joined #openstack-meeting-317:54
*** annegentle has joined #openstack-meeting-317:55
*** annegentle has quit IRC17:56
*** mattgriffin has quit IRC17:56
*** annegentle has joined #openstack-meeting-317:56
*** SumitNaiksatam has joined #openstack-meeting-318:00
*** bpokorny_ has joined #openstack-meeting-318:01
*** bpokorny has quit IRC18:04
*** pkoniszewski has joined #openstack-meeting-318:06
*** absubram has joined #openstack-meeting-318:06
*** mattgriffin has joined #openstack-meeting-318:07
*** sarob has quit IRC18:07
*** ivar-laz_ has quit IRC18:10
*** ivar-lazzaro has joined #openstack-meeting-318:10
*** tosky has left #openstack-meeting-318:11
*** yamahata has quit IRC18:12
*** vishwanathj has joined #openstack-meeting-318:15
*** lazy_prince is now known as killer_prince18:17
*** dboik_ has joined #openstack-meeting-318:18
*** dboik_ has left #openstack-meeting-318:18
*** haleyb has quit IRC18:19
*** Salman_ has joined #openstack-meeting-318:19
*** seizadi1 has joined #openstack-meeting-318:24
*** seizadi has quit IRC18:24
*** SridarK has joined #openstack-meeting-318:27
*** badveli has joined #openstack-meeting-318:29
*** eghobo has joined #openstack-meeting-318:30
vishwanathjHi all18:30
SumitNaiksatamvishwanathj: SridarK badveli: hi18:30
vishwanathjSumitNaiksatam, Hi18:30
SumitNaiksatam#startmeeting Networking FWaaS18:30
openstackMeeting started Wed Feb 18 18:30:45 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.18:30
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:30
*** openstack changes topic to " (Meeting topic: Networking FWaaS)"18:30
openstackThe meeting name has been set to 'networking_fwaas'18:30
SridarKSumitNaiksatam: , vishwanathj badveli hi18:30
SumitNaiksatam#info metting agenda https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting18:31
vishwanathjSridarK, badveli, Hi18:31
SumitNaiksatam#info we are in Kilo-3 (last milestone to get features merged)18:31
badvelihello all18:32
SumitNaiksatam#info kilo-3 is March 19th18:32
SumitNaiksatamanything else anyone wants to share?18:33
vishwanathjSumitNaiksatam, I thought it was March 5th, maybe I mistaken18:33
SumitNaiksatamvishwanathj: you might as well treat it as March 5th ;-)18:33
SridarK:-)18:33
vishwanathj:)18:34
SumitNaiksatampatches have to posted by march 5th18:34
vishwanathjoh, I see18:34
SumitNaiksatamand merged by march 19th (barring exceptions)18:34
SumitNaiksatam#topic Bugs18:35
*** openstack changes topic to "Bugs (Meeting topic: Networking FWaaS)"18:35
SumitNaiksatami just noticed this: #lik https://bugs.launchpad.net/neutron/+bug/141819618:36
openstackLaunchpad bug 1418196 in neutron "fwaas: driver base class is stale" [Undecided,In progress] - Assigned to yalei wang (yalei-wang)18:36
SumitNaiksatamand i think there is a patch: #link https://review.openstack.org/#/c/153930/18:36
SridarKSumitNaiksatam: hmm - i saw the bug18:37
SridarKSumitNaiksatam: but missed the review18:37
SridarKSumitNaiksatam: i am not sure we need to do this18:37
SridarKSumitNaiksatam: i will comment18:38
*** haleyb has joined #openstack-meeting-318:38
SumitNaiksatamSridarK: okay18:38
*** pc_m has joined #openstack-meeting-318:38
SumitNaiksatamthere is a new doc bug: #link https://bugs.launchpad.net/openstack-manuals/+bug/141949818:38
openstackLaunchpad bug 1419498 in openstack-manuals "Networking services in OpenStack Security Guide - FWaaS Section Updates" [Undecided,New]18:38
SumitNaiksatamany takers?18:39
vishwanathjI can take it18:39
SumitNaiksatamvishwanathj: thanks!18:39
vishwanathjShould I assign it to myself or are you going to assign it?18:40
SumitNaiksatamvishwanathj: yes sure18:40
SumitNaiksatamvishwanathj: i think you should be able to assign it18:40
SumitNaiksatamSridarK: badveli: I dont see any other high priority issues18:40
vishwanathjSumitNaiksatam, I was able to, thanks18:40
SridarKSumitNaiksatam: yes - there was another review u pointed me to18:41
SumitNaiksatamvishwanathj: great18:41
SridarK#link https://review.openstack.org/#/c/147396/18:41
SumitNaiksatamSridarK: yeah, i have not been able to get back to that either18:41
SridarKSumitNaiksatam: i commented on that, i am okay with that - waiting for Jenkins issues to get fixed18:42
SridarKSumitNaiksatam: i requested some additional validation which the author has added18:42
SumitNaiksatamSridarK: right, seems to be failing UTs18:42
SridarKSumitNaiksatam: yes also had some pep818:43
SridarKearlier18:43
*** SridharRamaswamy has quit IRC18:43
SumitNaiksatamSridarK: true18:43
*** s3wong has joined #openstack-meeting-318:43
SumitNaiksatamlets wait for it to pass Jenkins18:43
badveliyes i am not able to check any other bugs18:43
SridarKSumitNaiksatam: when i have a bit more cycles will work with him too18:43
SumitNaiksatami believe the author’s claim is that its not breaking the cases we had mentioned18:44
SumitNaiksatamthere is this general packaging bug: #link https://bugs.launchpad.net/neutron/+bug/142237618:44
openstackLaunchpad bug 1422376 in neutron "enable package test suites: dependency on generated egg from git.openstack.org" [Undecided,Incomplete]18:44
SumitNaiksatamand there was some discussion in the ML around it18:44
SumitNaiksatami think at this point we are not changing anything18:45
SumitNaiksatamanything else in terms of bugs?18:45
SridarKSumitNaiksatam: none that i am aware of18:46
SumitNaiksatamSridarK: okay, thanks18:46
SridarKnp at all18:46
SumitNaiksatam#topic Firewall Insertion18:46
*** openstack changes topic to "Firewall Insertion (Meeting topic: Networking FWaaS)"18:46
SumitNaiksatam#link https://review.openstack.org/15269718:46
SumitNaiksatamSridarK: over to you18:46
SridarKSumitNaiksatam: thx18:46
SridarKSome basic things begin to work18:47
SridarKI am able to do an end to end test with a single router insertion for CRUD. Update is a bit more tricky now as we need to selectively delete or add FW to specific routers. Some cleanup to push patch up.18:47
SridarKI am doing testing with a single router insert, update, delete18:47
SumitNaiksatam#chairs SridarK vishwanathj badveli18:47
SumitNaiksatam#chair18:47
openstackCurrent chairs: SumitNaiksatam18:47
SumitNaiksatam#chair SridarK vishwanathj badveli18:48
openstackCurrent chairs: SridarK SumitNaiksatam badveli vishwanathj18:48
SumitNaiksatamsorry, anticipating network issues18:48
SridarKthus far i have these things working18:48
SridarKok i figured18:48
SridarKWhat remains is to support list of routers on the db side for the access methods.  And UT. And i am sure small things here and there.18:48
SumitNaiksatamSridarK: nice18:48
vishwanathjSumitNaiksatam, what does that mean?  Current chairs? pardon my ignorance18:48
SumitNaiksatamvishwanathj: in case i drop off, you can close the meeting18:49
vishwanathjgot it, thanks18:49
SumitNaiksatamSridarK: sorry for the distraction18:49
SridarKSumitNaiksatam: i have hacks all over the place - want to clean that out and push a patch up18:49
SridarKnp18:49
SumitNaiksatamSridarK: okay, i noticed some comments from other cores18:49
SridarKhacks - meaning more debug logs18:49
*** seizadi1 has quit IRC18:50
*** seizadi has joined #openstack-meeting-318:50
SumitNaiksatamSridarK: okay18:50
SridarKSumitNaiksatam: yes on the tempest front, Nikolay will be working on that18:50
SridarKi wanted to touch base with pc_m before but today has been mtg day from early am18:51
SumitNaiksatamSridarK: awesome, i noticed his patch was abandoned18:51
SridarKwe can cover the agent refactor here18:51
SridarKSumitNaiksatam: yes he will pick this18:51
pc_mSridarK: We can chat later, jsut ping me18:52
SumitNaiksatampc_m: thanks18:52
SridarKSumitNaiksatam: perhaps some synchronization has to happen with api tests18:52
SumitNaiksatamSridarK: can you request him to update: #link https://wiki.openstack.org/wiki/Neutron/FWaaS/KiloPlan as well?18:52
SridarKSumitNaiksatam: i think i added him18:52
SridarKpc_m: sure18:52
SumitNaiksatamSridarK: yeah, i meant gerrit patch18:53
SridarKSumitNaiksatam: ok will do18:53
SumitNaiksatamreference18:53
SumitNaiksatamSridarK: any blocking issues?18:54
SridarKSumitNaiksatam: nothing now18:54
SridarKSumitNaiksatam: more neurons will help ;-)18:54
SumitNaiksatamSridarK: nice18:54
SumitNaiksatamSridarK: :-)18:54
SumitNaiksatamin my case, its - some neurons will help18:54
SridarKLets discuss a bit on the L3 agent refactor implications18:54
vishwanathjSridarK, let me know if there is any way that I can help or contribute to your efforts18:54
SridarK:-)18:54
SridarKthx vishwanathj18:55
SridarKi will discuss more with pc_m also18:55
SumitNaiksatam#topic FWaaS L3 agent refactoring/restructuring18:55
*** openstack changes topic to "FWaaS L3 agent refactoring/restructuring (Meeting topic: Networking FWaaS)"18:55
SumitNaiksatamSridarK: go ahead18:55
SridarKok18:55
SridarKso with the new model since router insert and del is driven from the plugin18:56
SridarKit simplifies the agent side as we had discussed18:56
SridarKso router add/del notification may not be needed on the agent18:56
SridarKthe plugin can take care of that side18:56
SridarKnot sure if we want to put a FK constraint18:56
*** seizadi has quit IRC18:57
*** seizadi1 has joined #openstack-meeting-318:57
SridarKbut that will kind of happen on the plugin18:57
SridarKthe other thing on i/f add/del18:57
SridarKsince we install the rules on qr*18:57
SridarKwe may not need to worry about this18:57
SridarKthis is my current thought18:58
SridarKby saying "we need not have to worry"18:58
SridarKi have probab jinxed it already :-)18:58
SumitNaiksatamSridarK: :-)18:58
SridarKsorry too much typing18:58
SridarKwill discuss this more with pc_m18:58
*** armax has joined #openstack-meeting-318:58
SumitNaiksatamokay so on the FK, this will be on router?18:59
SridarKand also once i update the patch it will become easier for folks to see18:59
SridarKSumitNaiksatam: i am thinking if we need to do that18:59
SridarKyes18:59
SumitNaiksatamSridarK: i am thinking it might be better to avoid FK constraints18:59
SridarKSumitNaiksatam: yes exactly what i started typing19:00
SumitNaiksatamSridarK: since they are not always supported across DBs19:00
*** stevelle has left #openstack-meeting-319:00
SridarKSumitNaiksatam: and if a router is deleted then the fw for that is gone19:00
SridarKother routers should still have the fw19:00
SridarKSumitNaiksatam: and this should work automatically19:00
SridarKSumitNaiksatam: thats all i had19:01
SumitNaiksatamSridarK: okay, to the extent we can lets implement those constraints in the code19:01
SridarKSumitNaiksatam: ok19:01
badveli Sridark, i am not able to follow you, could you please help what are we doing19:01
*** beagles is now known as beagles_brb19:02
SridarKbadveli: sure this is with router insertion and l3 agent refactor implications19:02
SridarKbadveli: with the router insertion model we are changing the fundamental behavior in the agent19:03
SridarKbadveli: the agent no longer tries to determine the routers on a tenant19:03
SridarKbadveli: the plugin tells the agent19:03
SridarKthis becomes part of the fw dict we send from the plugin to the agent19:03
SridarKbadveli: so we can remove some of that old code19:04
badvelithanks sridark, ok the plugin directly sends the fw dict19:04
badvelithanks19:04
SridarKbadveli: yes as before, but now it also send the routers the fw is to be inserted on19:05
SridarKbadveli: pls ping me if u other questions19:05
SridarK*have19:05
pc_mWith the refactoring... before the device drivers were talking directly to the agent (to get router info)19:05
*** stanzgy has joined #openstack-meeting-319:06
pc_mIf you no longer have that need, then may not have refactoring to do.19:06
pc_m(need to get router info from device driver)19:06
*** megm_ has joined #openstack-meeting-319:06
SridarKpc_m: no change on the agent - device driver interface19:06
SridarKthe agent will still call into the device driver (iptables) with the router list19:07
*** megm has quit IRC19:07
SridarKpc_m: the changes are confined to the agent and the agent - plugin interaction19:07
pc_mSridarK: Will device driver need to access the router (calling back to the agent to get router info)?19:07
SridarKpc_m: no the device driver is given the router19:08
*** annegentle has quit IRC19:08
badveli sridark, the agent will not longer be able to access the router info?19:08
*** VW_ has quit IRC19:08
SridarKbadveli: it will get the router-id - using the router-id it gets the ri list19:09
SridarKno change there either19:09
*** SridharRamaswamy has joined #openstack-meeting-319:09
SridarKthe only change is the agent used to get the list of all routers on the tenant19:09
SumitNaiksatamSridarK: pc_m: accessing the router info works the same way as before (after the l3 agent refactor)?19:10
badveliok, this change is needed only to update where is the firewall applied, correct?19:10
SridarKthe plugin did not provide this before now it does19:10
*** stanzgy has quit IRC19:10
SridarKbadveli: yes19:10
SridarKSumitNaiksatam: yes i believe so19:10
SridarKas we are in the inheritance hierarchy19:11
SridarKwe can access router-info19:11
SridarKno change there19:11
*** carl_baldwin has quit IRC19:11
pc_mSridarK: We can chat off-line to see if there is any refactoring needed for FWaaS. For VPN we needed to break the coupling between driver and agent.19:11
SridarKpc_m: yes lets do that19:12
SridarKSumitNaiksatam: i think that all i had19:13
SumitNaiksatampc_m: SridarK: it might be good to get the summary of that conversation for the rest of the team19:13
SridarKSumitNaiksatam: yes i will do that19:13
SumitNaiksatamperhaps an email summary will be good (i think there is some concern here with some of the vendor drivers which are currently leveraging this interaction)19:14
*** bknudson has quit IRC19:14
SumitNaiksatamalso general comment - i am pretty lonely on #openstack-fwaas19:14
SumitNaiksatamso might be a good place to have offline conversations ;-)19:14
SridarKSumitNaiksatam: yes on the vendor implications19:14
*** clu_ has joined #openstack-meeting-319:14
vishwanathjSumitNaiksatam, I did visit you there once :)19:15
SridarKSumitNaiksatam: :-)19:15
SumitNaiksatamvishwanathj: SridarK: ;-)19:15
SumitNaiksatamSridarK: thanks much for those two updates19:15
SridarKSumitNaiksatam: some rewiring is needed to get to the IRC :-)19:15
SridarKSumitNaiksatam: i never ever thought i would ever do anything on a db in my previous life :-)19:16
SridarKso i can also hang out on IRC19:16
SridarK:-)19:16
SumitNaiksatamSridarK: totally understand, i was just joking, please feel free to communicate in whichever is convenient and most effective!19:16
SumitNaiksatamSridarK: :-)19:16
SridarK:0)19:16
*** beagles_brb is now known as beagles19:17
SumitNaiksatam#topic Service Objects19:17
*** openstack changes topic to "Service Objects (Meeting topic: Networking FWaaS)"19:17
SumitNaiksatambadveli: over to you19:17
*** marg7175 has joined #openstack-meeting-319:17
badveli yes sumit19:17
badvelinot yet uploaded the patch, at least i will try to upload the neutron patch19:18
SumitNaiksatambadveli: okay19:18
badveli should it be accompanied by neutron client patch also?19:19
badveli python neutron client patch?19:19
SumitNaiksatambadveli: ideally yes19:20
SumitNaiksatambadveli: but “accompanied” is pretty subjective19:20
SumitNaiksatami believe it should be posted in a reasonable frame of time so as to allow reviewers an easy way to test19:21
badveli ok, thanks sumit19:21
SumitNaiksatambadveli: thanks for the update19:22
badveli hopefully still my old patches19:22
SridarKbadveli: so we will have one for neutron (extensions), one for fwaas (backend) and cli19:22
badveli yes sumit19:22
badvelibut planning to start on extensions first19:22
SumitNaiksatam#topic FWaaS gate jobs19:22
*** openstack changes topic to "FWaaS gate jobs (Meeting topic: Networking FWaaS)"19:23
SumitNaiksatampc_m: fwaas team owes you another big one for getting this enabled19:23
vishwanathj+119:23
SridarK+119:23
badvelithanks pcm19:24
pc_mnp guys!19:24
SridarKI will need some guidance on patches with api changes and interaction with gate jobs19:24
SridarKi see a chicken and egg type of problem unless i am missing something19:25
SridarKSumitNaiksatam: pc_m: i will ping u guys later on this19:25
SumitNaiksatamSridarK: sure19:25
pc_msure19:26
SumitNaiksatamSridarK: you anticipate tempest tests breaking?19:26
SridarKSumitNaiksatam: yes, as we now provide router ids19:26
SridarKSumitNaiksatam: or rather have to provide router-ids19:26
SridarKearlier was not needed19:26
SridarKso on the old test we will be in PENDING_CREATE19:27
SridarKwe can talk later - as we are running out of time19:27
SumitNaiksatamSridarK: okay19:27
SumitNaiksatam#topic Open Discussion19:27
*** openstack changes topic to "Open Discussion (Meeting topic: Networking FWaaS)"19:27
SumitNaiksatamAnything else we missed today?19:28
SumitNaiksatamwe have 2 mins19:28
*** marun has quit IRC19:28
SumitNaiksatamthe proposed talks for the Vancouver summit are now public19:28
vishwanathjWell, the Intel McAfee FWaaS patch needs to be reviewed once they upload a new patch which passes all jenkins test19:29
SumitNaiksatampc_m: and me along with doug have proposed a talk on *aaS19:29
*** annegentle has joined #openstack-meeting-319:29
SumitNaiksatamvishwanathj: yes19:29
vishwanathjcool19:29
SridarKSumitNaiksatam: on the cisco patch we are sorting out our vendor repo implications19:30
SumitNaiksatamSridarK: okay19:30
SumitNaiksatamfyi on the talk - #link https://www.openstack.org/vote-paris/presentation/neutron-mitosis-and-the-l7-services-roadmaps19:30
*** ttrifonow has joined #openstack-meeting-319:30
SumitNaiksatamplease let the team know if there are any other related talks so that we can express our interest accordingly19:31
SumitNaiksatamwe are out of time19:31
SumitNaiksatamthanks all!19:31
vishwanathjbye19:31
SumitNaiksatambye19:31
SridarKthanks all19:31
*** sreshetnyak has quit IRC19:31
SridarKbye19:31
SumitNaiksatam#endmeeting19:31
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:31
openstackMeeting ended Wed Feb 18 19:31:28 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:31
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-02-18-18.30.html19:31
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-02-18-18.30.txt19:31
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-02-18-18.30.log.html19:31
*** annegentle has quit IRC19:31
*** zz_ttrifonov has quit IRC19:31
*** eghobo has quit IRC19:31
*** SridharRamaswam1 has joined #openstack-meeting-319:31
*** pc_m has left #openstack-meeting-319:31
badvelibye19:32
*** ivar-lazzaro has quit IRC19:32
*** SridharRamaswamy has quit IRC19:32
*** ivar-lazzaro has joined #openstack-meeting-319:33
*** Rockyg has quit IRC19:35
*** MarkAtwood has joined #openstack-meeting-319:36
*** johnthetubaguy is now known as zz_johnthetubagu19:40
*** sarob has joined #openstack-meeting-319:41
*** bpokorny has joined #openstack-meeting-319:43
*** bpokorny_ has quit IRC19:46
*** sarob has quit IRC19:46
*** MarkAtwood has quit IRC19:51
*** Yi has quit IRC19:52
*** ivar-laz_ has joined #openstack-meeting-319:55
*** marg7175 has quit IRC19:56
*** marg7175 has joined #openstack-meeting-319:56
*** sarob has joined #openstack-meeting-319:56
*** ivar-lazzaro has quit IRC19:58
*** bknudson has joined #openstack-meeting-319:59
*** MaxV has joined #openstack-meeting-320:02
*** ivar-laz_ has quit IRC20:04
*** ivar-lazzaro has joined #openstack-meeting-320:05
*** vishwanathj has quit IRC20:06
*** sarob has quit IRC20:25
*** sarob has joined #openstack-meeting-320:25
*** Salman_ has quit IRC20:26
*** devlaps has quit IRC20:27
*** Sukhdev has joined #openstack-meeting-320:27
*** sarob has quit IRC20:29
*** kashyap has joined #openstack-meeting-320:30
*** Yi has joined #openstack-meeting-320:31
*** Yi has quit IRC20:33
*** marun has joined #openstack-meeting-320:33
*** marun has quit IRC20:39
*** yamahata has joined #openstack-meeting-320:40
*** devlaps has joined #openstack-meeting-320:44
*** Yi has joined #openstack-meeting-320:54
*** qwebirc13590 has joined #openstack-meeting-320:55
*** VW_ has joined #openstack-meeting-321:00
*** marg7175_ has joined #openstack-meeting-321:02
*** banix has quit IRC21:03
*** marg7175 has quit IRC21:04
*** matrohon has joined #openstack-meeting-321:08
*** GavinPratt has joined #openstack-meeting-321:10
*** VW_ has quit IRC21:12
*** VW_ has joined #openstack-meeting-321:13
*** SumitNaiksatam has quit IRC21:21
*** SumitNaiksatam has joined #openstack-meeting-321:22
*** seizadi has joined #openstack-meeting-321:26
*** seizadi1 has quit IRC21:26
*** marg7175_ has quit IRC21:28
*** eghobo has joined #openstack-meeting-321:30
*** marg7175_ has joined #openstack-meeting-321:31
*** carl_baldwin has joined #openstack-meeting-321:31
*** banix has joined #openstack-meeting-321:32
*** baoli has quit IRC21:38
*** seizadi has quit IRC21:41
*** seizadi has joined #openstack-meeting-321:41
*** eghobo has quit IRC21:49
*** robcresswell has left #openstack-meeting-321:53
*** sergef has quit IRC21:55
*** peristeri has quit IRC21:58
*** marg7175_ has quit IRC21:59
*** marg7175 has joined #openstack-meeting-321:59
alaski#startmeeting nova_cells22:00
openstackMeeting started Wed Feb 18 22:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.22:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.22:00
*** openstack changes topic to " (Meeting topic: nova_cells)"22:00
openstackThe meeting name has been set to 'nova_cells'22:00
alaskiAnyone around today?22:00
bauzasmornooning22:00
melwitthi22:00
alaskicool22:01
alaski#topic Testing22:01
*** openstack changes topic to "Testing (Meeting topic: nova_cells)"22:01
bauzaslots of people eh22:01
alaskibauzas: yep :)22:01
alaskihttps://bugs.launchpad.net/nova/+bug/142032222:01
openstackLaunchpad bug 1420322 in OpenStack Compute (nova) "gate-devstack-dsvm-cells fails in volumes exercise with "Server ex-vol-inst not deleted"" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)22:01
alaskimelwitt: I believe you had a patch for this?22:01
dansmitho/22:02
alaskimelwitt: apparently it did not have that bug number on it, or the bug didn't update22:02
melwittalaski: just looked at it, I don't think so. my patch was for the DetachedInstanceError22:03
alaskimelwitt: yep, that's this one22:03
alaskiyou have to expand the comment from mriedem to see it though22:04
melwittoh, sorry I didn't make the connection22:04
alaskijust looked at logstash real quick and it seems to have dissapeared since the 12th22:04
alaskiso I think we can mark that fixed for now22:04
melwittah, okay. I can close it out with a link to the merged review22:04
alaskimelwitt: that would be great, thanks22:05
alaskinext is https://bugs.launchpad.net/nova/+bug/142323722:05
openstackLaunchpad bug 1423237 in OpenStack Compute (nova) "check-tempest-dsvm-cells fails with: "AttributeError: 'dict' object has no attribute 'host' in hypervisor.py"" [High,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza)22:05
alaskiwhich bauzas is working on22:05
bauzasmy turn22:05
bauzasso, the problem is that I had to provide a primitive when calling the compute node object22:05
bauzasso, when going to the Host API, it was either an object if it wasn't for cells, but a dict if it was using the cells api22:06
bauzashence the dot notation not working22:06
*** alexsyip has joined #openstack-meeting-322:06
bauzasso, by discussing with alaski, I'm working on providing a ComputeNodeProxy for the Cells API methods around compute_node_get_all() and cn_get()22:07
alaskiit should just be hydrating a ComputeNode object in the api and then wrapping it with a Proxy, right?22:07
bauzasit should take the dict, then uploading it to an object and then running the computenodeproxy22:07
bauzasalaski: exactly, like you did22:08
alaskibauzas: cool22:08
alaskiplease add me to that when it's ready, and ping me22:08
bauzasalaski: I thought first it wasn't good to provide a primitive on the messaging system and then rehydrating it, but that seems to be the only one solution22:08
alaskibauzas: I won't say that it's good, but it's how a lot of things work in cells currently22:09
bauzasalaski: sure thing, my fingers are working on it22:09
alaskicool22:09
alaski#topic Database migrations22:10
*** openstack changes topic to "Database migrations (Meeting topic: nova_cells)"22:10
alaskiSo I've proofed out two methods now22:10
alaskialembic https://review.openstack.org/#/c/153666/22:10
alaskisqla-migrate https://review.openstack.org/#/c/157156/22:10
alaskiI personally like alembic much better22:11
bauzascool, starring them22:11
alaskithere's a more clear separation between the two dbs, and it's much nicer to use22:11
alaskibut johannes brought up a good point about requiring devs to know two systems22:11
bauzasalaski: yeah, but my main problem is that it means that the patch is very huge22:11
alaskiso I'd like to get some additional feedback22:12
alaskibauzas: I can probably split the patch22:12
bauzasalaski: agreeing with jerfeldt, that's something I'm thinking22:12
alaskiit's 590 lines vs 273 right now22:12
bauzasalaski: remember a previous comment I made, that means that we will have 2 migration tools for 2 distinct DBs22:12
alaskibut I probably have some tests to fix with sqla-migrate22:12
alaskibauzas: right.  so I don't love that it's two tools, but I like that they're separate22:13
alaskisome of the sqla-migrate code is a bit unclear right now as to which db it's working on22:13
bauzasalaski: mmm, as I said previously, I know that johannes is working on alembic for Nova, right22:13
bauzas?22:13
alaskiyes22:14
alaskibut it's not at a point where I can get away with not writing migrations22:14
bauzasmmm22:14
bauzasthat's a priority problem then22:14
*** seizadi has quit IRC22:14
alaskiwell, we asked him to make it optional22:15
*** seizadi has joined #openstack-meeting-322:15
*** mrmartin has quit IRC22:15
alaskiand there are still some bits to merge22:15
bauzasI mean, we can support an alembic provision for the Cells DB, but that's something huge22:15
alaskiI don't think it is really22:15
*** seizadi1 has joined #openstack-meeting-322:15
bauzasbecause then, the port to Alembic makes it mandatory to the Cells DB22:15
*** seizadi has quit IRC22:15
alaskia user has no exposure because it's behind nova-manage22:16
bauzasalaski: at least, you have to work on nova-manage22:16
bauzaseg22:16
bauzaseh22:16
bauzasthat's the point22:16
bauzasnew CLI22:16
alaskiit's new either way22:16
bauzasagreed22:16
edleafe /me walks in late22:16
edleafe<sigh>22:16
bauzasso, maybe my problem is that's you're providing a new CLI for alembic in the same patch for the Cells DB22:17
bauzasmaybe that's just a split problem22:17
alaskibauzas: right, I can split that out22:17
alaskiI should add this to the agenda for the Nova meeting to get some additional feedback22:17
bauzasalaski: agreed, that's maybe having more impact than just us22:18
bauzasand also operators could be interested in it22:18
alaskiI have a preference for alembic, but I can see the argument for using sqla-migrate22:18
*** mrunge has quit IRC22:18
alaskibauzas: it shouldn't matter for an operator though22:18
bauzasalaski: I mean, if your Cells patch is agnostic to the migration tool, that's not a problem22:19
bauzasalaski: because if you're splitting, then you could just say that's optional22:19
bauzasI need to review again your patch for seeing how we could have an agnostic migration tool22:20
*** baoli has joined #openstack-meeting-322:20
alaskian operator will see 'nova-manage db api_sync'22:20
alaskithe arguments are slightly different, but they shouldn't care what's behind that22:20
*** cbader has quit IRC22:20
alaskiit's more a change for devs22:21
bauzasalaski: well, you're right22:21
alaskibut I'll add it to the Nova agenda and we can discuss there as well22:21
alaskifeedback welcome on the reviews in the meantime22:22
bauzasalaski: sure thing22:22
alaski#topic Multiple database support22:22
*** openstack changes topic to "Multiple database support (Meeting topic: nova_cells)"22:22
alaskihttps://review.openstack.org/#/c/150381/22:23
alaskijust bringing attention to this mainly22:23
alaskithe patch has evolved a bit so getting more reviews would be helpful22:23
dansmithI need to look at that again22:23
dansmithsorry for being lazy22:23
alaskiwe'll call it busy22:24
alaskihe added in the context manager22:24
dansmithah, cool22:24
bauzasalaski: yeah, I saw22:24
alaskiit could still use some example of using it, but I think the direction is good22:24
bauzasalaski: sure, I can review it again, but it needs some rebase22:24
bauzasalaski: agreed22:25
bauzasalaski: some high-level unittests could cover this22:25
alaskibauzas: yeah, that would be good to see22:25
alaski#topic Neutron discussion22:26
*** openstack changes topic to "Neutron discussion (Meeting topic: nova_cells)"22:26
alaskiI've been in touch with some networking folks at Rackspace who are helping me to understand more about neutron and nova and cells22:26
alaskiand I have some volunteers to help with some discussions22:26
alaskinow I'm trying to get everyone together to get started22:27
*** Sukhdev has quit IRC22:27
dansmithnice22:28
bauzascool22:28
alaskiyeah.  they've been thinking about this for a long time and have some ideas they haven't been able to bring to fruition22:28
alaskiso I'm going to at least get those out in the open22:29
alaskibut that's all I have for now22:29
bauzassounds like a new etherpad manifesto eh ? :)22:29
alaskibauzas: that might be good22:30
bauzasat least it would be async :)22:30
alaskionce I have a better handle on the scope of it I'll see how that can be documented for discussion22:30
*** cbader has joined #openstack-meeting-322:30
bauzasso if the Rackspace guys are willing to put some draft, I would be glad to sneak peek on it22:30
alaskiat this point it seems to me that there are solutions for specific things, not a wholistic solution yet22:31
*** jckasper has quit IRC22:31
bauzasalaski: so, I remember our last call, and it was about wondering if Neutron can scale22:32
*** pkoniszewski has quit IRC22:32
bauzasbecause if we assess that we'll support Neutron, it should scale on the same pace than Nova22:32
*** marun has joined #openstack-meeting-322:32
alaskibauzas: apparently it scales, but has some challenges22:33
alaskiso having them thinking about cells might be good22:33
bauzasalaski: good to know, I'm looking forward knowing the challenges :)22:33
alaskidb related from what I know, as everything seems to be22:35
alaski#topic Open Discussion22:35
*** openstack changes topic to "Open Discussion (Meeting topic: nova_cells)"22:35
alaskiI had one topic I wanted to bring up, related to cells v122:36
alaskimelwitt and I were looking at how to pass instance objects up during cell updates22:36
alaskiwhere I stopped was when that caused a loop of updates22:37
*** tonyb has joined #openstack-meeting-322:37
alaskiinstance.save cause an update to go up/down which triggers an instance.save on the other end22:37
alaskiso in order to get this to work we need to make updates one way only22:37
alaskiI'm not sure of a good way to do that without modifying the save api22:38
melwittI thought the same, something akin to the update_cells=True/False thing in the db api22:39
*** Yi has quit IRC22:40
bauzasalaski: you mean that updating an instance means that you will call twice the DB save ?22:40
melwittit just seemed like we need a way to indicate we don't want it to sync back22:40
alaskibauzas: it will loop forever currently22:41
alaskimelwitt: right22:41
alaskiI was thinking we would need to tell the object when we call save, but now I don't think we do22:41
*** cbader has quit IRC22:41
melwittI was thinking the same thing. all it does is detect whether it's at the top cell or not and sync to the other side depending22:42
bauzasoic22:42
*** baoli has quit IRC22:43
alaskihmm, just looked a bit closer and might have a thought22:43
bauzasany pointer I could look at it ?22:43
dansmithalaski: I really hate that :(22:44
*** banix has quit IRC22:44
alaskibauzas: instance_update_from_api, instance_update_at_top in messaging.py22:44
dansmithalaski: that being "update_cells=True"22:44
dansmithalaski: can we break the chain by looking to see if the updates being made are already in the db?22:45
alaskidansmith: what would you say to a context manager for save()?  @dont_update_cell save22:45
melwittdansmith: the notes near that say that once everything calls Instance.save, it could go away. but I think we'd still have this ping pong syncing unless I'm missing something22:45
dansmithor even something simple like a TTL to prevent it from running after X hops?22:45
dansmithmelwitt: I didn't write that stuff (AFAIK), so I'm not sure22:45
dansmithalaski: how would that work? save happens at the conductor side, not the caller side22:45
melwittdansmith: heh yeah, I know. comstud wrote the notes22:46
*** qwebirc13590 has quit IRC22:46
alaskidansmith: in instance_update_at_top it would call save in a way that neuters to cells sync22:46
dansmithalaski: how about we catch up tomorrow morning and look at the details?22:46
alaskiand same for isntance_update_from_api22:46
alaskidansmith: sure22:46
dansmithalaski: well, I know, but I mean, how would the context manager communicate it to the remoted call?22:46
alaskimelwitt: it would still have the ping pong22:46
*** matrohon has quit IRC22:47
alaskidansmith: ahh, I see22:47
alaskistopping the sync if there are no writes could work, but it would require an extra trip and would be prone to races22:48
*** bpokorny_ has joined #openstack-meeting-322:48
dansmithyeah22:48
dansmithcan we calculate a TTL from the cell path?22:48
bauzascan we add something in the context that we're passing ?22:48
dansmithlike if we're in the first child cell, TTL would be 1, so it only ever gets updated once, parent cell or child cell?22:48
bauzaslike a proximity direction22:48
dansmithbauzas: maybe22:49
bauzasdansmith: a TTL is a good idea because that's not cell related22:49
dansmithwell, it'd only ever be needed in cells22:49
bauzasdansmith: atm, yes22:50
alaskithe issue is still how to let the object know the ttl22:50
alaskiTTL22:50
bauzasalaski: introspecting the context it gets ?22:50
alaskicontext would work, I just hate to add something just for this22:50
*** bpokorny has quit IRC22:50
bauzasalaski: isn't the direction we're following for the cells DB connection ? :D22:51
dansmithwe're getting the loop because we're calling cells_rpc.instance_update right?22:51
*** yamahata_ has quit IRC22:51
*** isq has joined #openstack-meeting-322:51
alaskibauzas: right, but that's a more general thing for a feature.  not a hack :)22:51
bauzasalaski: agreed, it was a pun22:52
alaskidansmith: it's a loop between instance_update_at_top and instance_update_from_api22:52
alaskiin cells/messaging.py22:52
dansmithsurely seems like we can do something in there, since we have all those cells bits in between22:52
melwittdansmith: and it occurs after we convert everything to objects and call instance.save() in both places22:52
dansmithright22:53
melwittright now it's not happening because instance_update_at_top calls db.instance_update22:53
melwittyeah22:53
dansmithcan we slap something into the cell name? doesn't cell_name have foo!bar syntax or whatever?22:53
alaskihmm, we'd have to be careful that it's not persisted but that might work22:54
dansmithright22:54
dansmithlike slap a # on the end or something22:55
dansmithbut,22:55
*** baoli has joined #openstack-meeting-322:55
dansmithit also seems like we should be able to do something in the cells bits to prevent the loop22:55
alaskiI'm just coming up blank on that right now.  the cells methods are being called from instance.save() and right now don't know if it's the first time they're being called or not22:56
dansmithwait22:56
alaskisomething in instance.save had to provide some data to the cells bits22:57
alaskis/had/has/22:57
dansmithif we unset cell_name entirely before we make those calls,22:57
dansmiththen they won't match the condition on the receiving end,22:57
dansmithbut we won't have cell_name be modified either, so we won't try to update it in the DB22:58
dansmithmeaning,22:58
dansmithunset it on the clone we pass over rpc22:58
melwitthm, interesting22:58
dansmithI don't think anything else there will care that it's missing, will it?22:58
dansmithwith a big comment on top that says "remove the cell name so that we don't re-run this on the other side" and it'll half make sense even22:59
melwitthehe22:59
alaskithe cells routing uses the cell_name at some point, I'll have to refresh myself on that22:59
dansmithhmm22:59
alaskibut we could pull it off after that point22:59
dansmithmaybe modify *those* apis to do the smart thing if we pass it a flag?23:00
alaskiyeah, I'm all for that.  It's figuring out when to pass the flag that's tricky23:00
alaskioops, times up23:01
*** matrohon has joined #openstack-meeting-323:01
alaskiThanks all!23:01
alaski#endmeeting23:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"23:01
openstackMeeting ended Wed Feb 18 23:01:23 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)23:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/nova_cells/2015/nova_cells.2015-02-18-22.00.html23:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/nova_cells/2015/nova_cells.2015-02-18-22.00.txt23:01
openstackLog:            http://eavesdrop.openstack.org/meetings/nova_cells/2015/nova_cells.2015-02-18-22.00.log.html23:01
*** VW__ has joined #openstack-meeting-323:02
*** seizadi1 has quit IRC23:03
*** carl_baldwin has quit IRC23:05
*** VW_ has quit IRC23:05
*** tonyb has left #openstack-meeting-323:05
*** Yi has joined #openstack-meeting-323:07
*** dttocs has joined #openstack-meeting-323:07
*** megm has joined #openstack-meeting-323:08
*** megm_ has quit IRC23:08
*** thangp has quit IRC23:08
*** matrohon has quit IRC23:09
*** eghobo has joined #openstack-meeting-323:10
*** qwebirc86514 has joined #openstack-meeting-323:10
*** qwebirc86514 has quit IRC23:10
*** rolandchan has joined #openstack-meeting-323:10
*** bpokorny_ has quit IRC23:16
*** sarob has joined #openstack-meeting-323:17
*** SumitNaiksatam has quit IRC23:20
*** nelsnelson has quit IRC23:22
*** nelsnelson has joined #openstack-meeting-323:23
*** matrohon has joined #openstack-meeting-323:23
*** yamamoto has quit IRC23:27
*** GavinPratt_ has joined #openstack-meeting-323:27
*** etoews has joined #openstack-meeting-323:27
*** eghobo has quit IRC23:28
*** yamamoto has joined #openstack-meeting-323:28
*** bpokorny has joined #openstack-meeting-323:30
*** rbertram has left #openstack-meeting-323:31
*** Piet has quit IRC23:31
*** jpomero has quit IRC23:31
*** yamamoto has quit IRC23:37
*** Yi has quit IRC23:37
*** Yi has joined #openstack-meeting-323:40
*** VW__ has quit IRC23:42
*** marun has quit IRC23:43
*** elmiko has joined #openstack-meeting-323:47
*** lblanchard has quit IRC23:48
*** rolandchan has left #openstack-meeting-323:48
*** mattgriffin has quit IRC23:49
*** shamail has joined #openstack-meeting-323:49
*** rosmaita has joined #openstack-meeting-323:52
*** matrohon has quit IRC23:53
*** nelsnelson has quit IRC23:54
sigmavirus24o/23:55
* elmiko waves at sigmavirus24 23:56
sigmavirus24elmiko: are you at the OSSG mid-cycle?23:56
*** MaxV has quit IRC23:56
elmikounfortunately no =(23:56
elmikosigmavirus24: how about you?23:56
sigmavirus24nope23:56
sigmavirus24If I were, I suspect I'd have been kicked out23:57
elmikolol23:57
sigmavirus24No one there seems to appreciate my actually reviewing the stuff going into bandit =P23:57
elmikoouch!23:57
*** ryansb has joined #openstack-meeting-323:57
etoewshihi23:57
elmikohey23:57
sigmavirus24hi all23:57
ryansb\o23:57
rosmaitao/23:57
*** ivar-laz_ has joined #openstack-meeting-323:58
elmikosigmavirus24: i would like to have gone, but it just didn't work out this time23:58
*** ivar-laz_ has quit IRC23:58
etoewsheh OSSG==ocean state of school gymnastics23:58
sigmavirus24elmiko: Maybe next cycle I will but I'll probably be going to glance's or cinder's instead23:58
*** Piet has joined #openstack-meeting-323:58
*** ivar-laz_ has joined #openstack-meeting-323:58
elmikosigmavirus24: unfortunately the sahara team is too spread out, we don't do midcycle =(23:59
sigmavirus24etoews: Openly Seeking Security Greyhats23:59
elmikolol23:59
etoewsdidn't cinder just have their mid-cycle last month?23:59
sigmavirus24etoews: so did Glance23:59
cyeohhi23:59
etoewshiya cyeoh23:59
sigmavirus24cyeoh: o/23:59
*** ivar-lazzaro has quit IRC23:59

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