Tuesday, 2014-03-25

openstackgerritMaru Newby proposed a change to openstack/neutron: Exclude .ropeproject from flake8 checks  https://review.openstack.org/8267600:01
openstackgerritJoe Gordon proposed a change to openstack/neutron: Disable oslo.messaging debug logs  https://review.openstack.org/8261800:02
*** carlp has joined #openstack-neutron00:10
*** openstack has joined #openstack-neutron00:20
*** matsuhashi has joined #openstack-neutron00:26
*** baoli has joined #openstack-neutron00:27
*** baoli has quit IRC00:28
*** baoli has joined #openstack-neutron00:28
*** sungju has joined #openstack-neutron00:29
*** manishg has quit IRC00:30
*** singhs has quit IRC00:32
*** salv-orlando has joined #openstack-neutron00:37
*** pcm_ has joined #openstack-neutron00:39
pcm_nati_ueno: ping00:40
*** welldannit has quit IRC00:43
*** _cjones_ has quit IRC00:52
nati_uenopcm_: pong00:53
nati_uenopcm_: sorry still working on fixing ut00:53
nati_uenopcm_: can we talk tommorow?00:53
*** yamahata has joined #openstack-neutron00:55
*** yamahata_ has quit IRC00:56
*** yamahata_ has joined #openstack-neutron00:56
*** tomoe_ has quit IRC00:58
pcm_nati_ueno: OK. Let me know as soon as you can. I'll try to email my thoughts.00:58
*** armitage81 has joined #openstack-neutron01:00
*** armitage81 has quit IRC01:02
*** krtaylor has quit IRC01:07
*** thuc has quit IRC01:10
*** thuc has joined #openstack-neutron01:10
*** krtaylor has joined #openstack-neutron01:11
*** dave_tucker is now known as dave_tucker_zzz01:13
*** thuc has quit IRC01:15
*** mlavalle has quit IRC01:18
openstackgerritAbhishek Raut proposed a change to openstack/neutron: Fix segment allocation tables in Cisco N1kv plugin  https://review.openstack.org/7850601:19
*** krtaylor has quit IRC01:20
*** mwagner_lap has joined #openstack-neutron01:23
*** krtaylor has joined #openstack-neutron01:23
*** rwsu has quit IRC01:26
*** SumitNaiksatam has joined #openstack-neutron01:29
*** matsuhashi has quit IRC01:30
*** matsuhashi has joined #openstack-neutron01:30
*** carl_baldwin has joined #openstack-neutron01:35
*** Jianyong has joined #openstack-neutron01:36
*** emagana has quit IRC01:41
*** rwsu has joined #openstack-neutron01:42
*** SumitNaiksatam has quit IRC01:45
*** yamahata_ has quit IRC01:48
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194601:48
*** tomoe_ has joined #openstack-neutron01:50
*** yamahata_ has joined #openstack-neutron01:50
*** BuSerD has quit IRC01:50
openstackgerritshihanzhang proposed a change to openstack/neutron: Prevent dhcp port deletion from the API  https://review.openstack.org/8176801:52
*** tdx-ram has joined #openstack-neutron01:52
*** SumitNaiksatam has joined #openstack-neutron01:52
*** spandhe has quit IRC01:54
*** BuSerD has joined #openstack-neutron01:56
*** yonglihe_ has quit IRC01:56
*** carl_baldwin has quit IRC01:58
*** yonglihe_ has joined #openstack-neutron01:59
*** Guest3042 has joined #openstack-neutron02:00
Guest3042Hello02:00
*** baoli has quit IRC02:00
Guest3042Trying to track a request through openstack02:01
*** xuhanp has joined #openstack-neutron02:01
Guest3042I find plenty on older arch but I need better understanding of new flow with neutron02:01
*** gongysh has joined #openstack-neutron02:11
*** xianghui has joined #openstack-neutron02:12
*** carl_baldwin has joined #openstack-neutron02:14
*** carl_baldwin has quit IRC02:15
*** beagles has quit IRC02:16
*** armitage81 has joined #openstack-neutron02:19
*** carl_baldwin has joined #openstack-neutron02:19
*** armitage81 has quit IRC02:19
*** armitage81 has joined #openstack-neutron02:19
*** thuc has joined #openstack-neutron02:21
*** xianghui has quit IRC02:22
*** carl_baldwin has quit IRC02:23
*** xianghui has joined #openstack-neutron02:25
*** thuc has quit IRC02:26
*** carl_baldwin has joined #openstack-neutron02:27
*** oda-g_ has joined #openstack-neutron02:29
*** HenryG has joined #openstack-neutron02:29
*** oda-g has quit IRC02:30
*** sbalukoff has quit IRC02:31
*** carl_baldwin has quit IRC02:31
openstackgerritshihanzhang proposed a change to openstack/neutron: Prevent dhcp port deletion from the API  https://review.openstack.org/8176802:31
*** tomoe_ has quit IRC02:33
*** mestery has joined #openstack-neutron02:34
*** tomoe_ has joined #openstack-neutron02:36
*** Sukhdev has joined #openstack-neutron02:40
*** rkukura has joined #openstack-neutron02:43
*** mestery has quit IRC02:46
*** thuc has joined #openstack-neutron02:46
*** banix has joined #openstack-neutron02:46
*** mestery has joined #openstack-neutron02:46
*** salv-orlando_ has joined #openstack-neutron02:49
*** salv-orlando has quit IRC02:50
*** salv-orlando_ is now known as salv-orlando02:50
*** banix has quit IRC02:51
*** thuc_ has joined #openstack-neutron02:51
*** thuc has quit IRC02:54
*** tomoe_ has quit IRC02:58
*** banix has joined #openstack-neutron03:01
*** carlp has quit IRC03:10
*** matsuhashi has quit IRC03:12
openstackgerritPaul Michali proposed a change to openstack/neutron: Cisco VPN driver correct reporting for admin state chg  https://review.openstack.org/8230603:15
*** pcm_ has quit IRC03:16
*** devlaps has quit IRC03:19
*** sweston has joined #openstack-neutron03:21
*** oda-g_ has quit IRC03:27
*** oda-g has joined #openstack-neutron03:28
*** matsuhashi has joined #openstack-neutron03:30
*** thuc has joined #openstack-neutron03:31
*** chandankumar_ has joined #openstack-neutron03:32
*** thuc_ has quit IRC03:34
*** armitage81 has quit IRC03:34
*** thuc has quit IRC03:35
*** matsuhashi has quit IRC03:36
*** chandankumar_ has quit IRC03:40
*** Sukhdev has quit IRC03:43
*** sridhar has joined #openstack-neutron03:45
openstackgerritshihanzhang proposed a change to openstack/neutron: Prevent dhcp port deletion from the API  https://review.openstack.org/8176803:47
*** BuSerD has quit IRC03:49
*** harlowja_ is now known as harlowja_away03:49
*** banix has quit IRC03:54
*** chandankumar_ has joined #openstack-neutron03:55
*** banix has joined #openstack-neutron03:56
*** tomoe_ has joined #openstack-neutron04:00
*** Longgeek has joined #openstack-neutron04:10
*** banix has quit IRC04:11
*** nati_ueno has quit IRC04:13
*** tomoe_ has quit IRC04:13
*** tomoe_ has joined #openstack-neutron04:14
*** thuc has joined #openstack-neutron04:18
*** tomoe_ has quit IRC04:18
*** thuc_ has joined #openstack-neutron04:18
*** devlaps has joined #openstack-neutron04:21
*** tdx-ram has quit IRC04:21
*** thuc has quit IRC04:22
*** dfarrell07 has joined #openstack-neutron04:23
*** Guest3042 has quit IRC04:23
*** spandhe has joined #openstack-neutron04:23
*** matsuhashi has joined #openstack-neutron04:23
*** chandankumar_ has quit IRC04:23
*** spandhe has quit IRC04:28
*** spandhe_ has joined #openstack-neutron04:28
*** tomoe_ has joined #openstack-neutron04:29
*** jecarey has quit IRC04:30
*** Sukhdev has joined #openstack-neutron04:32
*** thuc_ has quit IRC04:40
*** nati_ueno has joined #openstack-neutron04:40
*** thuc has joined #openstack-neutron04:41
*** pasquier-s has quit IRC04:41
*** ramishra_ has joined #openstack-neutron04:45
*** thuc_ has joined #openstack-neutron04:45
*** thuc has quit IRC04:45
*** sphoorti has joined #openstack-neutron04:52
sphoortiihrachys: are you around ?04:53
*** pasquier-s has joined #openstack-neutron04:54
*** tomoe_ has quit IRC04:54
*** tomoe_ has joined #openstack-neutron04:54
*** yamahata has quit IRC04:58
*** yamahata has joined #openstack-neutron04:58
*** tomoe_ has quit IRC04:59
*** yamahata has quit IRC04:59
*** yamahata has joined #openstack-neutron04:59
openstackgerritMike Kolesnik proposed a change to openstack/neutron: Allow unsharing a network used as gateway  https://review.openstack.org/8235205:03
*** thuc has joined #openstack-neutron05:03
*** thuc_ has quit IRC05:06
*** tomoe_ has joined #openstack-neutron05:07
*** thuc has quit IRC05:08
*** yfried has quit IRC05:10
*** matsuhashi has quit IRC05:14
*** pasquier-s has quit IRC05:16
*** matsuhashi has joined #openstack-neutron05:18
*** skraynev_afk is now known as skraynev05:19
*** emagana has joined #openstack-neutron05:27
*** tomoe_ has quit IRC05:28
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194605:30
*** zhipeng has quit IRC05:34
*** dguitarbite has quit IRC05:37
*** dguitarbite has joined #openstack-neutron05:41
*** irenab has joined #openstack-neutron05:44
*** nati_ueno has quit IRC05:47
*** chandan_kumar has quit IRC05:48
*** nati_ueno has joined #openstack-neutron05:51
*** tomoe_ has joined #openstack-neutron05:55
*** otherwiseguy has quit IRC05:59
*** pradipta_away is now known as pradipta06:00
*** Jabadia has joined #openstack-neutron06:03
*** Sukhdev has quit IRC06:04
*** ramishra_ has quit IRC06:06
*** sridhar has quit IRC06:11
*** thuc has joined #openstack-neutron06:14
*** raies has joined #openstack-neutron06:15
*** rotbeard has joined #openstack-neutron06:15
raieshi06:15
raiesI am trying to add firewall create API test in tempest06:16
raiesbut when I create a firewall it goes in "PENDING_CREATE" status for infinite long06:16
raiesI read some help here https://bugs.launchpad.net/neutron/+bug/122347206:16
raiesI created a router using that tenant with which firewall is being created06:17
raiesbut still it does not get Active06:17
raiesany help on this ?? ^^^06:17
*** mestery has quit IRC06:18
*** thuc has quit IRC06:19
*** spandhe_ has quit IRC06:30
*** yfried has joined #openstack-neutron06:31
*** sungju has quit IRC06:32
openstackgerritJenkins proposed a change to openstack/neutron: Imported Translations from Transifex  https://review.openstack.org/8243506:32
SumitNaiksatamraies: is your l3 agent active?06:33
*** djoreilly has joined #openstack-neutron06:41
*** gdubreui has quit IRC06:41
openstackgerritMike Kolesnik proposed a change to openstack/neutron: Allow unsharing a network used as gateway  https://review.openstack.org/8235206:42
raiesSumitNaiksatam: Yes I am using devstack and I have set q-l3 in enable services06:45
raiesSumitNaiksatam: Actually when I try using netron CLI then status gets ACTIVE. But during implementation in tempest status is PENDING_CREATE06:46
raiesSumitNaiksatam: As I read https://bugs.launchpad.net/neutron/+bug/1223472 which tells that one router should be there with associated tenant06:46
raiesSumitNaiksatam: I first created a router with that tenant and with same tenant a firewall is created06:47
openstackgerritshihanzhang proposed a change to openstack/neutron: Prevent dhcp port deletion from the API  https://review.openstack.org/8176806:47
*** Longgeek has quit IRC06:49
*** iwamoto has joined #openstack-neutron06:50
*** ramishra has joined #openstack-neutron06:51
*** ramishra_ has joined #openstack-neutron06:53
*** ramishra has quit IRC06:54
*** Longgeek has joined #openstack-neutron06:55
*** ramishra_ has quit IRC06:55
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Restore NOT NULL constraint lost by earlier migrations  https://review.openstack.org/7859106:57
*** sridhar has joined #openstack-neutron06:58
openstackgerritMaru Newby proposed a change to openstack/neutron: Add preliminary support for in-tree api tests  https://review.openstack.org/8223707:00
*** jlibosva has joined #openstack-neutron07:06
*** dfarrell07 has quit IRC07:06
*** sphoorti has quit IRC07:09
*** ramishra has joined #openstack-neutron07:13
*** oda-g has quit IRC07:15
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Set correct columns' length  https://review.openstack.org/8053907:15
raiesSumitNaiksatam: Any answer ??07:15
*** devvesa has joined #openstack-neutron07:16
*** devlaps has quit IRC07:17
*** dvorkinista has joined #openstack-neutron07:21
*** Longgeek has quit IRC07:22
*** saju_m has joined #openstack-neutron07:30
*** Longgeek has joined #openstack-neutron07:31
*** nati_ueno has quit IRC07:37
*** sacharya has joined #openstack-neutron07:37
openstackgerritBerezovsky Irena proposed a change to openstack/neutron: Add L2 Agent side handling for non consistent security_group settings  https://review.openstack.org/8272907:38
*** luqas has joined #openstack-neutron07:45
*** sungju has joined #openstack-neutron07:46
*** pasquier-s has joined #openstack-neutron07:48
*** rkukura has quit IRC07:48
*** dvorkini_ has joined #openstack-neutron07:56
*** dvorkinista has quit IRC07:56
*** sungju has quit IRC08:03
openstackgerritMaru Newby proposed a change to openstack/neutron: Add support for retargetable functional api testing  https://review.openstack.org/7258508:06
*** jprovazn has joined #openstack-neutron08:10
*** dvorkini_ has quit IRC08:11
openstackgerritenikanorov proposed a change to openstack/neutron: Fix namespace exist() method  https://review.openstack.org/8153708:13
*** sphoorti has joined #openstack-neutron08:15
openstackgerritMaru Newby proposed a change to openstack/neutron: Add support for retargetable functional api testing  https://review.openstack.org/7258508:16
*** sungju has joined #openstack-neutron08:20
*** bashok has joined #openstack-neutron08:20
*** pasquier-s has quit IRC08:22
*** sungju has quit IRC08:23
*** pasquier-s has joined #openstack-neutron08:25
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Fix 'server_default' parameter usage in migrations and models  https://review.openstack.org/8207308:25
*** bashok_ has joined #openstack-neutron08:29
*** bashok has quit IRC08:29
*** sphoorti has quit IRC08:33
*** jgallard has joined #openstack-neutron08:35
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Add 2-leg configuration to Radware LBaaS Driver  https://review.openstack.org/6900908:36
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Cancelling thread start while unit tests running  https://review.openstack.org/8132308:36
*** sphoorti has joined #openstack-neutron08:36
*** sphoorti_ has joined #openstack-neutron08:38
ihrachyssphoorti: yeah, what's up?08:40
*** leseb has joined #openstack-neutron08:40
openstackgerritSphoorti proposed a change to openstack/neutron: Add unit test for add_vxlan in test_linux_ip_lib  https://review.openstack.org/8055408:42
*** sphoorti has quit IRC08:42
sphoorti_ihrachys: I was having some troubles earlier with tox tests. fixed them Have a look. I have submitted a fresh patch08:43
ihrachyssphoorti_: link?08:47
ihrachyssphoorti_: ah, I see08:47
*** matsuhashi has quit IRC08:49
*** jistr has joined #openstack-neutron08:49
*** roeyc has joined #openstack-neutron08:50
*** saju_m has quit IRC08:50
*** roeyc has quit IRC08:51
*** saju_m has joined #openstack-neutron08:52
*** iwamoto has quit IRC08:53
*** jistr is now known as jistr|training08:54
ihrachyssphoorti_: done08:54
*** ygbo has joined #openstack-neutron08:55
*** matsuhashi has joined #openstack-neutron08:56
*** sungju has joined #openstack-neutron08:59
*** sacharya has quit IRC09:00
sphoorti_ihrachys: I had got a comment which suggested that I should add docstrings09:00
*** jpich has joined #openstack-neutron09:02
sphoorti_and about the port numbers, they are passed as two args . have a look https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_lib.py#L17509:02
ihrachyssphoorti_: self-evident docstrings are worthless. If you still think it's a must, you may elaborate on test intention09:02
ihrachyssphoorti_: yes, they are. still, the programmer assumed it should be a tuple of min:max, not a string09:02
ihrachyssphoorti_: as I told before, this may be a bug in add_vxlan too. but we should discuss details in review, not in irc09:03
openstackgerritCedric Brandily proposed a change to openstack/neutron: Replace a usage of the deprecated root_helper option  https://review.openstack.org/8274609:03
sphoorti_ihrachys: about the docstring I think I should remove them, since when I had elaborated them I received comments to modify them09:03
*** yfried has quit IRC09:04
sphoorti_ihrachys: what do you suggest for the port tuple ?09:07
ihrachyssphoorti_: it's not that you elaborated too much; instead, you could describe the intention, like 'Test add_vxlan function with valid arguments.' But really, I don't even think this is a major issue anyway.09:07
*** rkukura has joined #openstack-neutron09:07
ihrachyssphoorti_: whatever is valid as per add_vlan function? but again, let's discuss details in gerrit.09:08
sphoorti_ihrachys: sure09:09
*** sbalukoff has joined #openstack-neutron09:12
*** chandan_kumar has joined #openstack-neutron09:13
*** matsuhashi has quit IRC09:14
*** safchain has joined #openstack-neutron09:15
*** irenab has quit IRC09:17
*** matsuhashi has joined #openstack-neutron09:18
*** bashok has joined #openstack-neutron09:20
*** bashok_ has quit IRC09:20
*** yfried has joined #openstack-neutron09:21
*** dvorkinista has joined #openstack-neutron09:22
*** pradipta is now known as pradipta_away09:24
*** tomoe_ has quit IRC09:24
*** pradipta_away is now known as pradipta09:24
*** luqas has quit IRC09:25
sphoorti_ihrachys: I replied on gerrit.09:25
sphoorti_however I see them as drafts rather than comments ihrachys09:26
ihrachyssphoorti_: you need to post them first09:26
ihrachyssphoorti_: Review button will do the job09:27
openstackgerritOleg Bondarev proposed a change to openstack/neutron: LBaaS: haproxy driver should do undeploy when needed  https://review.openstack.org/8274909:27
openstackgerritOleg Bondarev proposed a change to openstack/neutron: LBaaS: make device driver decide whether to deploy instance  https://review.openstack.org/8251409:27
*** dvorkinista has quit IRC09:27
sphoorti_thanks a lot ihrachys09:29
*** luqas has joined #openstack-neutron09:29
*** Longgeek has quit IRC09:29
*** sungju has quit IRC09:35
*** dave_tucker_zzz is now known as dave_tucker09:36
*** saju_m has quit IRC09:38
sphoorti_ihrachys: when I declare port as a tuple and pass them as two args, the tox tests work fine. single argument raises AssertionError for passing wrong number of parameteres09:38
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Add 2-leg configuration to Radware LBaaS Driver  https://review.openstack.org/6900909:41
*** rkukura has quit IRC09:41
*** Longgeek has joined #openstack-neutron09:43
*** sungju has joined #openstack-neutron09:45
ihrachyssphoorti_: that's probably expected, as per add_vxlan code09:46
*** bvandenh has quit IRC09:47
sphoorti_so should I just resolve the docstring comment ? and  also, should the port be a tuple ? ihrachys ?09:47
ihrachyssphoorti_: yes, as per comments in add_vxlan. Have you really checked the function that you're testing?09:48
sphoorti_yes ihrachys , I posted it in the comments too09:49
*** sungju has quit IRC09:51
*** gongysh has quit IRC09:55
*** saju_m has joined #openstack-neutron09:56
openstackgerritSphoorti proposed a change to openstack/neutron: Add unit test for add_vxlan in test_linux_ip_lib  https://review.openstack.org/8055409:59
sphoorti_ihrachys: made those changes.10:00
sphoorti_also should checking the port arguments be filed as a bug ? ihrachys ?10:01
sphoorti_ihrachys: sorry for that one :(10:03
ihrachyssphoorti_: if I were you, I would do it for sure :) and probably I would send a patch for this, this should be easy. [if not isinstance(...): ...]10:04
*** pcm__ has joined #openstack-neutron10:04
*** morganfainberg is now known as morganfainberg_Z10:05
openstackgerritBerezovsky Irena proposed a change to openstack/neutron: Add L2 Agent side handling for non consistent security_group settings  https://review.openstack.org/8272910:06
*** pcm__ has quit IRC10:07
*** pcm__ has joined #openstack-neutron10:08
*** matsuhashi has quit IRC10:08
*** networkstatic has joined #openstack-neutron10:09
*** sungju has joined #openstack-neutron10:09
*** matsuhashi has joined #openstack-neutron10:10
*** yfried has quit IRC10:10
*** bvandenh has joined #openstack-neutron10:10
*** emagana has quit IRC10:13
*** salv-orlando has quit IRC10:14
*** jp_at_hp has joined #openstack-neutron10:16
openstackgerritSphoorti proposed a change to openstack/neutron: Add unit test for add_vxlan in test_linux_ip_lib  https://review.openstack.org/8055410:16
sphoorti_ihrachys: finally made that last change too.10:17
sphoorti_also I didnt follow your :-  [if not isinstance(...): ...].10:17
ihrachyssphoorti_: I meant the probable fix for the missing check in add_vxlan() - checking that the port argument is a tuple/list/...10:19
*** overlayer has joined #openstack-neutron10:21
sphoorti_thank you ihrachys for the +1 and helping me out :)10:22
*** xuhanp has quit IRC10:23
sphoorti_ihrachys: I have a question though. The parameters of the port tuple could be strings too right ?10:24
sphoorti_so accessing the port[0] and port[1] is possible.10:24
ihrachyssphoorti_: it's accepted by the current validation code, but I think it was not an intent of the developer who implemented it10:24
*** yfried has joined #openstack-neutron10:24
*** sungju has quit IRC10:24
ihrachyssphoorti_: the problem is that string is also an iterable, with __len__ method, so it passes thru the check. But I guess this is not expected.10:25
*** overlayer has quit IRC10:26
*** gdubreui has joined #openstack-neutron10:27
*** overlayer has joined #openstack-neutron10:28
sphoorti_ihrachys: true. How can we confirm the expected behavior of the function ?10:28
*** overlayer has quit IRC10:31
ihrachyssphoorti_: what do you mean?10:31
*** pradipta is now known as pradipta_away10:32
sphoorti_ihrachys: how can the expected behavior of add_vxlan be confirmed?  since the current test checks for the add_vxlan function10:32
*** overlayer has joined #openstack-neutron10:32
*** sungju has joined #openstack-neutron10:33
ihrachyssorry, I don't understand your question. your test is designed to check that proper command is passed to the system, right? what else do you need?10:33
*** sungju has quit IRC10:33
sphoorti_ihrachys: true. sorry I got confused between checking the port argument as tuple/list10:35
*** markmcclain has joined #openstack-neutron10:39
*** sungju has joined #openstack-neutron10:40
*** emagana has joined #openstack-neutron10:44
*** Jianyong has quit IRC10:49
*** Longgeek has quit IRC10:49
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Set correct nullable parameter for columns  https://review.openstack.org/8208910:49
*** sungju has quit IRC10:50
*** emagana has quit IRC10:52
openstackgerritMaru Newby proposed a change to openstack/neutron: Refactor plugin setup helpers out of test.base  https://review.openstack.org/8277510:58
openstackgerritMaru Newby proposed a change to openstack/neutron: Add support for retargetable functional api testing  https://review.openstack.org/7258511:01
marunsphoorti_: there is little value in that type of testing11:06
marunsphoorti_: recommended reading: http://googletesting.blogspot.com/2013/03/testing-on-toilet-testing-state-vs.html11:07
*** saju_m has quit IRC11:07
marunsphoorti_: if you want to do useful testing, consider adding a functional test that actually interacts with the system11:07
*** saju_m has joined #openstack-neutron11:08
*** saju_m has quit IRC11:09
marunsphoorti_: and I'd be happy to assist you in making that happen.11:09
*** ramishra has quit IRC11:11
markmcclainmarun: I would argue that the unit test case added is necessary from a UT perspective11:11
marunmarkmcclain: disagree entirely11:11
markmcclainwe also need functional tests too11:12
marunmarkmcclain: if you can test it in a unittest, great11:12
marunmarkmcclain: but did you look at the addition?11:12
marunmarkmcclain: there is zero need to check that a method was called with a given set of arguments11:12
*** Longgeek has joined #openstack-neutron11:12
markmcclainthis? https://review.openstack.org/#/c/80554/10/neutron/tests/unit/test_linux_ip_lib.py11:12
marunyes11:12
marunthat first test is bs11:12
*** mwagner_lap has quit IRC11:12
marunwhenever I see that, I think "someone doesn't know the value of functional testing"11:13
markmcclainverifies that we're constructing the shell correctly11:13
marunit does nothing at all11:13
marunnot without a functional test11:13
marunmost of our unit testing is like that11:13
marunmock, mock, mock11:13
*** gdubreui has quit IRC11:13
markmcclainso this test validates the logic we have for constructing the system call11:13
markmcclainthe functional test validates that the call actually does what we want on the dataplane11:14
marunit duplicates the internal logic of the code under test11:14
marunit's a waste of time11:14
marunif we're wrong, we're just as likely wrong twice11:14
marundouble-entry bookkeeping was only useful pre-computer.  we're past that11:14
marunyou may want to review: http://googletesting.blogspot.com/2013/03/testing-on-toilet-testing-state-vs.html11:14
markmcclainok then for ip_lib was the proper unit of work boundary?11:14
markmcclainspecifically for .add_vxlan()?11:15
*** saju_m has joined #openstack-neutron11:15
maruni'm afraid I don't follow 'proper unit of work boundary'?11:15
markmcclainso unit tests need to test a unit of work11:16
markmcclainis the proper unit not the resulting call to .execute()?11:16
marununit tests need to test what is reasonable to test in a unit test11:16
markmcclainseems that command construction fits your definition11:16
marunif all the test is going to do is duplicate the logic of the code under test, that's a sign that you have to go up a level11:16
marunvalidate the actual system interaction11:17
marunif it's possible to test without the duplication, then a unit test is appropriate11:17
markmcclainif we're modifying the dataplane we're no longer a unit test and have moved into functional testing11:17
markmcclainwe should be doing both11:17
marunwe should be doing both, but they don't have to duplicate each other11:17
maruncoverage should be a measure of both functional and unit testing execution11:18
maruntest at the lowest level possible, but no lower11:18
sphoorti_marun: I would like to work on functional tests too. The https://review.openstack.org/#/c/80554/ was my first patch which was a prerequisite for my OPW application. My mentor rossella_ had suggested that I could start with a unit test. Hence the patch11:18
*** ramishra has joined #openstack-neutron11:19
marunsphoorti_: I know you're just following the testing convention already in use.  unfortunately it's flawed.11:19
*** leseb has quit IRC11:19
markmcclainoh see I don't see this duplicating the functional test11:19
marunmarkmcclain: really?11:20
markmcclainthe unit test validates the construction of the shell command11:20
*** leseb has joined #openstack-neutron11:20
markmcclainfor functional you'll be inspecting the dataplane11:20
marunhave you been working on neutron that long?11:20
*** xianghui has quit IRC11:20
markmcclainstate and not the system call right?11:20
marunthe second test I can see the point of, validating logic in the code11:20
markmcclainso in theory if iputils were to change the command line interface the functional test11:20
marunthe first, no11:20
markmcclainwould not need to be altered, but the UT would11:21
sphoorti_but marun , arent unit tests supposed to check the commands are being passed ?11:21
marunI think so, yes.11:21
*** rkukura has joined #openstack-neutron11:21
marunsorry, that was for mark11:21
marunsphoorti_: unit tests are supposed to validate logic, not duplicate it11:22
markmcclainnot seeing how this test duplicates logic11:22
marunsphoorti_: as per that google blog post, it's a bad sign if you have to validate interactions11:22
markmcclainif ensures that based on arguments passed the resulting executed is formed in a certain way11:22
marunmarkmcclain: it duplicates the logic of the call11:23
rossella_markmcclain: +111:23
marunmarkmcclain: it duplicates exactly the logic of the call11:23
marunmarkmcclain: have you read that google blog post?11:23
marunrossella_: http://googletesting.blogspot.com/2013/03/testing-on-toilet-testing-state-vs.html11:23
marunthis is a classic case of validating interaction11:23
marunbecause there is no state to validate11:23
rossella_marun: I am reading it :)11:23
*** dave_tucker is now known as dave_tucker_zzz11:24
markmcclainmarun I've read that post before11:24
*** leseb has quit IRC11:24
markmcclainbut not sure that fully applies11:24
marunmarkmcclain: ?!11:24
marunmarkmcclain: ok, I guess we'll just have to disagree then.11:25
markmcclainin this case .execute does not have a return value11:25
marunmarkmcclain: I'm not sure how it could be clearer.11:25
markmcclainthe system call here is basically throwing the command over the wall and hoping for the best11:25
marunmarkmcclain: the point is, you can't test the method in question without testing interactions rather than state.11:25
marunmarkmcclain: so it's a stupid thing to test11:25
openstackgerritOleg Bondarev proposed a change to openstack/neutron: LBaaS: haproxy driver should respect vip/pool admin state  https://review.openstack.org/8274911:25
marunwe can test state in a functional test, so it should be done there.11:25
markmcclainmarun: but you can validate that we construct the command correctly11:25
marunmarkmcclain: ?!11:25
sphoorti_marun I dont get how exactly the blog post applies to this patch.11:26
marunforest for the trees man, neutron is so full of this crap.11:26
marunyou're validating that a method was called correctly11:26
marunwithout actually calling the method11:26
markmcclainmarun:  it is a shell command11:26
marunffs11:26
marun"Testing interactions means you're verifying that the code under test calls certain methods properly."11:26
marunhow is that not what's happening?11:26
markmcclainUnit test should test a unit of work11:27
markmcclaincommand construction is a unit work11:27
marun-> construct the command correctly11:27
marun*sigh*11:27
markmcclainhttps://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_lib.py#L15811:27
marunok, I give up.11:27
marunYou can keep you unit tests.11:27
markmcclainlooking at the test and the actual method11:27
markmcclainI'm failing to see the duplicated logic11:27
markmcclainan argument could made that the call to as root should be checked instead of execute11:27
*** dave_tucker_zzz is now known as dave_tucker11:28
marunsure, whatever11:28
markmcclainand that the return value of add_vxlan() is an IPDevice right?11:28
sphoorti_yep11:28
marunif you don't think that's not duplication, our respective meanings of 'duplicate' clearly differ and we should just stop11:28
marunthe unit tests are full of this crap and I think it's pointless11:29
marunbut if you think it's valuable, well, you're PTL.11:29
markmcclainI'm just trying to gain a better understand of where the problem lies11:29
markmcclainunit test should test the add_vxlan() method in isolation right?11:29
markmcclainfunctional test should examine all the way down the data plane right?11:30
*** rotbeard has quit IRC11:30
marunif possible.  but the equivalent functional test does what the unit test does and one better - actual system itneraction11:30
marunergo, don't bother with the unit test.11:30
marunwriting unit tests - or any type of test - in isolation is the devils work11:30
marunconsidering how to test a feature really should require considering all the different ways it can be done.11:31
marunrather than do everything in unit, then everything in functional then everything in integration...11:31
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278711:31
marunbecause we can't.  we don't have the resources.11:31
rossella_marun: so your point is that this kind of unit tests are an useless extra check if we have functional tests that test the same11:31
marunrossella_: correct.11:31
marunrossella_: if I can write a unit test for not much more cost, then it's worth skipping the unit test11:32
marunrossella_: less cost to write, less cost to maintain11:32
marunoops11:32
marunwrite a unit test -> functional test11:32
markmcclainmarun: functional tests have cost that is always greater than unit test11:32
rossella_yes11:33
marunmarkmcclain: agreed11:33
rossella_also ramping up cost is higher11:33
marunbut we _need_ the functional test11:33
rossella_marun: agreed11:33
marunso, unit test < functional test < unit test + functional test11:33
rossella_:)11:33
marunwe get away with the least cost item11:33
markmcclainmarun: we agree that we need both, but adding the UT is a good first step11:34
marunin the case of system interaction, functional tests should be the default11:34
marunbecause we need them11:34
rossella_do we agree that for somebody that has just started looking into neutron a unit test is an achievable target while a functional test is kind of high?11:34
marununit tests are often of questionable value for code that does system interaction11:34
rossella_right now we request a UT for a patch that adds something, would you request a functional test too in future?11:34
marunrossella_: I agree only if the unit test isn't pointless11:34
marunrossella_: the test for the error -> not pointless11:35
marunrossella_: the test that validates construction of the command -> pointless11:35
marunrossella_: (though you wouldn't know it from the existing tests)11:35
markmcclainmarun: I think part of the problem is that our unit tests take too long run11:35
markmcclainunit testing should be the first bar11:36
marunmarkmcclain: uh11:36
markmcclainfunctional the next one11:36
markmcclainand integration the final hurdle11:36
marunmarkmcclain: our unit tests take too long because they are all fscking functional11:36
markmcclainthat we all agree on11:36
marunmarkmcclain: and pretending we can keep on writing stupid tests and the problem will go away doesn't really solve anything11:36
markmcclainthey are also 70-80% duplicative11:36
rossella_marun markmcclain : let's start writing the functional test then we can prune the useless UT11:37
marun+111:37
markmcclainrossella_: that I agree with11:38
rossella_:)11:38
*** saju_m has quit IRC11:38
marunrossella_: tests in the tests/functional tree can interact with the system as configured by devstack, and can use sudo11:38
markmcclainI just think we'll end up keeping this test because it does have unit value11:38
*** saju_m has joined #openstack-neutron11:38
marunmarkmcclain: 'unit value'?11:38
marunis that some kind of negative quantity? :p11:38
markmcclainyes as a valid unit tests it guards against regressions11:38
marunbs11:39
marunregressions from what?11:39
markmcclainso let's say that we find out we're passing the wrong args to iputils11:39
markmcclainwe update this test to the proper command11:39
markmcclainand then update ip_lib to construct the command properly11:39
*** jistr|training has quit IRC11:40
marunagain, functional test > unit test in this case11:40
*** irenab has joined #openstack-neutron11:40
markmcclainno the bug is in command construction11:40
marunthe interaction is all with iputils, so test there11:40
maruni'm starting to hate on mocking11:40
markmcclainmocking is necessary when you start inspecting the data plane you are testing more than one level at once11:41
marunyou're using big words like 'data plane'11:41
markmcclainmultiple levels are not unit tests11:41
*** jistr has joined #openstack-neutron11:41
markmcclainiputils modifies the data plane does it not?11:41
*** jistr is now known as jistr|training11:41
marunit doesn't if it's mocked out11:41
marunand if all that's being done is constructing a command....11:41
rossella_but if you construct it in the wrong way...how long would you need to catch this trivial flaw in a functional test and how long in a stupid, straightforward UT?11:43
marunagain, if you think validating trivial command construction is somehow not duplicative, we're simply not on the same page11:43
marun'trivial flaw'?11:43
markmcclainwell the functional test isn't going to care how the command is constructed11:43
marunif there's a flaw, how can you validate it _except_ against the damn command?11:43
markmcclainonly that the device is created and configured correctly11:44
marundoing it with mocks is utterly pointless11:44
marunmarkmcclain: isn't that the only thing that matters?11:44
marun-> results?11:44
marunif there's an error or the results are unexpected, then something is wrong...11:44
marunif things are mocked out, what are we actually testing?11:45
rossella_marun: in the end yes, results matter. But time matters too...detecting what's wrong if a functional test fails is not so trivial11:45
markmcclain++11:45
marunrossella_: what am I missing here?11:45
marunyou are both telling me that a flaw in creating the command is easier to detect in a unit test, when the unit test doesn't have any ability to tell you that _something is actually wrong_11:45
marunit's an echo chamber11:46
marun'i did it wrong according to my internal model'11:46
marunnot 'i did it wrong according to the world'11:46
marunif we were talking about something non-trivial, things would be different11:46
marunbut iplib / ovslib are just thin wrappers over cli11:46
marunthey don't deserve much in the way of unit testing, they deserve functional testing11:46
rossella_maybe you are just smarter than me...sometimes I do stupid stuff and then I run a trivial, dummy UT and I discover the problem. If I don't have a stupid UT I have to run a complex functional test and believe me it will take me hours to find out that I am just passing the wrong parameters11:47
maruni *like* unit tests11:47
marununit tests are awesome11:47
marunbut they aren't for everything11:47
marunif I can't understand an error in a functional test, it's really nice to have a unit test to isolate the problem11:47
maruneither write it or have it exist11:47
marunbut in this case, it doesn't buy us anything.11:47
marunif there's an error in constructing the command, we have just as much ability to look at that in a functional tests11:48
maruntest11:48
marunso, in general I completely agree with having test coverage at as low a level as possible to make detection and reproduction of failure easier11:49
marunbut sometimes it doesn't make sense, and this is one of those cases.11:49
* marun thinks we should just agree to disagree, in any case11:49
rossella_marun: I think we agree generally, for this specific case we don't agree11:49
marunrossella_: i've maintained way too much legacy code to want to waste my time and the time of others on pointless testing11:50
marunrossella_: but hey, whatever floats your boat11:50
* rossella_ thinks that she will buy a candy to marun just to bribe him11:50
*** leseb has joined #openstack-neutron11:50
*** vbellur has joined #openstack-neutron11:51
*** jgallard has quit IRC11:51
sphoorti_marun: markmcclain rossella_ I am a bit lost in the conversation now11:52
sphoorti_and marun I am eager to learn about functional tests too :)11:53
marunsphoorti_: just ignore my ranting11:53
rossella_marun: I mean, it's one test, we can agree to disagree. But it's important that we agree on some general principle. When we will have the functional tests and we will prune the current UT we don't want to discuss on any single test11:53
maruni'm fighting for the principle because maintaining tests isn't free11:54
marunmost of the unit tests in neutron that validate system interaction are simply pointless11:54
marunbut they have a cost nonetheless11:55
rossella_I know. So maybe we should extend the discussion to the community and write some general rules11:55
marunagree completely...11:55
rossella_:)11:55
marunhttps://blueprints.launchpad.net/neutron/+spec/neutron-testing-refactor11:55
*** leseb has quit IRC11:55
marunhttps://etherpad.openstack.org/p/neutron-testing-refactor11:55
marunthe first step was getting a functional job running, which it is11:55
rossella_great! sorry I missed that blueprint11:55
marunway down that list is developer education11:55
maruni'm working on getting examples in-tree of how to do different types of testing so there'll framework for people to work from11:56
rossella_marun: great work!11:56
marunif you want to contribute in any way, please don't hesitate to dive in11:56
marunthe section at the top is to track individual effort so we don't duplicate11:56
rossella_I am interested, I will try to contribute11:57
marunok, I must sleep.  i think i've reached my limit on crankiness, thanks for bearing with me.11:58
*** dave_tucker is now known as dave_tucker_zzz11:58
marunrossella_: also: https://review.openstack.org/#/c/72585/11:58
rossella_marun: it was a pleasure talking with you...I like people with strong opinions. Get some rest!11:59
marun:)11:59
*** networkstatic is now known as networkstatic_zZ12:01
*** skraynev is now known as skraynev_afk12:01
*** baoli has joined #openstack-neutron12:02
*** harlowja_away has quit IRC12:03
*** dave_tucker_zzz is now known as dave_tucker12:03
rossella_markmcclain: before this conversation about unit testing started I just wanted to say that sphoorti_ is an applicant of the Outreach Program for Women. She'd like to contribute to Neutron. That UT was her first patch and was required to apply for the internship. Welcome sphoorti_ !12:07
markmcclainsphoorti_: Welcome!12:08
markmcclainrossella_: awesome12:08
anteayasphoorti_: you will be lost for a good while, don't take feeling lost as a metric12:08
anteayasphoorti_: show up everyday and ask questions12:08
anteayasphoorti_: you will learn more than you think just be doing that12:08
sphoorti_thank you markmcclain rossella_ anteaya :)12:09
sphoorti_markmcclain: I have some doubts regarding your comment, would you be around if I come after sometime ?12:11
markmcclainsphoorti_: yes feel free to reach out on IRC12:12
sphoorti_and anteaya agreed with you. being on this channel did help me understand some concepts regarding unit tests. Initially my unit tests used to fail many a times. But once I followed a conversation on the channel and that helped me solve my doubt.12:13
sphoorti_:)12:13
sphoorti_markmcclain: sure :)12:13
*** julim has joined #openstack-neutron12:13
*** matsuhashi has quit IRC12:16
*** sphoorti_ has quit IRC12:19
*** jgallard has joined #openstack-neutron12:19
*** matsuhashi has joined #openstack-neutron12:23
*** markmcclain has quit IRC12:24
*** markmcclain has joined #openstack-neutron12:24
*** markmcclain1 has joined #openstack-neutron12:25
*** tomoe_ has joined #openstack-neutron12:26
*** yamahata has quit IRC12:27
*** markmcclain2 has joined #openstack-neutron12:27
*** markmcclain2 has quit IRC12:27
*** markmcclain2 has joined #openstack-neutron12:28
*** markmcclain has quit IRC12:29
*** markmcclain1 has quit IRC12:29
*** markmcclain2 has quit IRC12:30
*** markmcclain has joined #openstack-neutron12:31
*** b3nt_pin has joined #openstack-neutron12:31
*** b3nt_pin is now known as beagles12:31
*** pba2 has quit IRC12:32
*** pba2 has joined #openstack-neutron12:32
*** doude_ has joined #openstack-neutron12:33
*** doude has quit IRC12:33
*** saju_m has quit IRC12:41
*** roeyc has joined #openstack-neutron12:42
*** leseb has joined #openstack-neutron12:43
*** mwagner_lap has joined #openstack-neutron12:46
enikanorov_markmcclain: hi. could you please explain negative scoring on https://review.openstack.org/#/c/81537/ ? latest patchset adds bug-id to commit message that we believe is fixed with the patch12:47
*** dims_ has quit IRC12:52
*** irenab has quit IRC12:52
*** luqas has quit IRC12:52
*** saju_m has joined #openstack-neutron12:55
*** tomoe_ has quit IRC12:55
*** tomoe_ has joined #openstack-neutron12:56
*** dguitarbite has quit IRC12:56
*** dguitarbite has joined #openstack-neutron12:56
*** thuc has joined #openstack-neutron12:57
*** xuhanp has joined #openstack-neutron12:58
*** thuc_ has joined #openstack-neutron12:58
*** saju_m has quit IRC12:59
baoli#startmeeting PCI Passthrough13:00
openstackMeeting started Tue Mar 25 13:00:11 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.13:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
openstackThe meeting name has been set to 'pci_passthrough'13:00
*** Gil_McGrath has joined #openstack-neutron13:00
*** saju_m has joined #openstack-neutron13:00
baoliHi13:00
*** vbellur has quit IRC13:01
*** thuc has quit IRC13:01
*** heyongli has joined #openstack-neutron13:02
*** itzikb has joined #openstack-neutron13:02
*** dims_ has joined #openstack-neutron13:02
enikanorov_baoli: hi13:02
enikanorov_it's openstack-neutron, are you sure the meeting is going to be here?13:03
*** matsuhashi has quit IRC13:03
baolienikanorov_, we have weekly meeting at utc 1300 wednesday13:04
enikanorov_at which channel?13:04
baolisorry, wrong channel13:04
enikanorov_:)13:04
baolimy bad13:04
*** saju_m has quit IRC13:04
anteayabaoli: can you end the meeting please?13:04
*** saju_m has joined #openstack-neutron13:05
baoli#endmeeting13:05
openstackMeeting ended Tue Mar 25 13:05:24 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:05
openstackMinutes:        http://eavesdrop.openstack.org/meetings/pci_passthrough/2014/pci_passthrough.2014-03-25-13.00.html13:05
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/pci_passthrough/2014/pci_passthrough.2014-03-25-13.00.txt13:05
openstackLog:            http://eavesdrop.openstack.org/meetings/pci_passthrough/2014/pci_passthrough.2014-03-25-13.00.log.html13:05
baoliSorry, guys. A little rusty in the morning13:05
anteayabaoli: np13:05
*** heyongli has quit IRC13:07
*** heyongli has joined #openstack-neutron13:07
xuhanpsafchain, ping13:07
safchainxuhanp, pong13:08
xuhanpI have a question about L3 HA if you have a minute13:08
*** irenab has joined #openstack-neutron13:08
safchainxuhanp, sure13:08
xuhanpI wanted to try your patch out today and I get stuck with a problem13:08
xuhanpso I created a route today and I haven't attached any subnets to it yet.13:08
xuhanpI can find the HA ports created on both my 2 L3 agent nodes13:09
*** saju_m has quit IRC13:09
xuhanpbut I am having trouble to ping from one port's IP to the other from their namespace13:09
xuhanpI was worried about keepalived won't work under this situation.13:10
*** saju_m has joined #openstack-neutron13:10
xuhanpHave you find this problem before? any clue?13:10
safchainxuhanp, no, but I can try to redo the same test13:12
xuhanpI am using GRE so it may related to my GRE setup problem.13:12
safchainxuhanp, yes could you test the GRE setup13:12
xuhanpsafchain, any clue about how to test GRE?13:13
*** aveiga has joined #openstack-neutron13:13
safchainxuhanp, maybe without the HA patches, test to spawn 2 routers and try to do the same test13:14
safchainxuhanp, maybe between the dhcp namespace and a router namespace13:14
xuhanpyou mean ping from the qr namespace to the qr namespace on the other node?13:15
xuhanpand do the same for dhcp namespace?13:15
*** ChanServ changes topic to "the gerrit event stream is currently hung, blocking all testing. troubleshooting is in progress (next update at 14:00 utc)"13:21
*** changbl has quit IRC13:22
*** devvesa has quit IRC13:27
*** mestery has joined #openstack-neutron13:28
*** mestery has quit IRC13:28
*** mestery has joined #openstack-neutron13:29
*** ChanServ changes topic to "Discussion of OpenStack Networking || for support join #openstack"13:30
*** ramishra has quit IRC13:30
*** banix has joined #openstack-neutron13:31
*** markmcclain has quit IRC13:34
*** yamahata has joined #openstack-neutron13:38
*** nati_ueno has joined #openstack-neutron13:40
*** thuc_ has quit IRC13:41
*** luqas has joined #openstack-neutron13:42
*** thuc has joined #openstack-neutron13:42
*** thuc has quit IRC13:47
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194613:49
*** Gil_McGrath has quit IRC13:51
anteayaI'm going to test something with meetbot/openstack, please ignore me13:52
anteaya#startmeeting test_lurk13:52
openstackMeeting started Tue Mar 25 13:52:22 2014 UTC and is due to finish in 60 minutes.  The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot.13:52
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:52
*** jecarey has joined #openstack-neutron13:52
openstackThe meeting name has been set to 'test_lurk'13:52
anteaya#endmeeting13:52
openstackMeeting ended Tue Mar 25 13:52:33 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:52
openstackMinutes:        http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.52.html13:52
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.52.txt13:52
openstackLog:            http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.52.log.html13:52
anteaya#lurk13:52
anteaya#startmeeting test_lurk13:53
openstackMeeting started Tue Mar 25 13:53:21 2014 UTC and is due to finish in 60 minutes.  The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot.13:53
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:53
openstackThe meeting name has been set to 'test_lurk'13:53
anteaya#endmeeting13:53
openstackMeeting ended Tue Mar 25 13:53:33 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:53
openstackMinutes:        http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.53.html13:53
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.53.txt13:53
openstackLog:            http://eavesdrop.openstack.org/meetings/test_lurk/2014/test_lurk.2014-03-25-13.53.log.html13:53
anteaya#unlurk13:53
*** dguitarbite has quit IRC13:54
*** nati_ueno has quit IRC13:59
*** tomoe_ has quit IRC14:00
*** ramishra has joined #openstack-neutron14:00
*** tomoe_ has joined #openstack-neutron14:00
*** ramishra has quit IRC14:02
*** heyongli has quit IRC14:02
*** ramishra has joined #openstack-neutron14:04
*** peristeri has joined #openstack-neutron14:04
*** tomoe_ has quit IRC14:05
*** dvorkinista has joined #openstack-neutron14:06
*** nplanel has quit IRC14:14
*** dvorkinista has quit IRC14:19
*** flwang has joined #openstack-neutron14:20
openstackgerritArmando Migliaccio proposed a change to openstack/python-neutronclient: Show the unknown auth stratey in neutron client  https://review.openstack.org/8283414:20
openstackgerritOleg Bondarev proposed a change to openstack/neutron: Delete disassociated floating ips on external network deletion  https://review.openstack.org/5336414:21
*** mestery has quit IRC14:24
*** dvorkinista has joined #openstack-neutron14:26
*** alexpilotti has quit IRC14:28
*** dvorkinista has quit IRC14:29
*** tomoe_ has joined #openstack-neutron14:29
*** nplanel has joined #openstack-neutron14:30
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278714:30
*** markmcclain has joined #openstack-neutron14:32
*** markmcclain has quit IRC14:32
*** mestery has joined #openstack-neutron14:33
*** markmcclain has joined #openstack-neutron14:33
enikanorov_markmcclain: ping14:35
pcm__ANYONE: I'm getting a Jenkins fail on py2.6, but don't see to see the failure in log. Tried to run on my machine, but have issue w/tox saying zlib import fail. Are there instructions on setup of tox for py2.6?14:37
*** otherwiseguy has joined #openstack-neutron14:37
*** irenab has quit IRC14:38
*** leseb has quit IRC14:38
*** dvorkinista has joined #openstack-neutron14:42
openstackgerritRoey Chen proposed a change to openstack/neutron: Fixed TypeError when creating MlnxException  https://review.openstack.org/8283714:44
xuhanpamotoki, ping14:46
enikanorov_pcm__: pls give a link to jankins failure14:47
enikanorov_*e14:48
*** dvorkinista has quit IRC14:48
*** armax has joined #openstack-neutron14:49
enikanorov_pcm__: if you're talking about this one https://review.openstack.org/#/c/82306/14:50
enikanorov_pcm__: py26 job exceeded 1 hour in duration14:50
enikanorov_nothing specific to fix. it happens from time to time14:50
*** BillTheKat has joined #openstack-neutron14:52
markmcclainenikanorov_: updated the review.  The problem is the linked bugs and the actual change do not agree.14:53
*** BillTheKat has quit IRC14:53
enikanorov_markmcclain: i don't quite understand why so.  the change gets rid of running namespace listing with a root and within the namespace. also, we found out that the issue (existing behaviour causes exception on lbaas agent and respawning the haproxy) is responsible for scenario test failure14:54
*** thedodd has joined #openstack-neutron14:54
markmcclainenikanorov_: because first bug only lowers the priveledges14:55
enikanorov_markmcclain: but you can't do 'ip netns exec namespace' without root, so you need to get rid of both sudo and 'exec'14:55
*** thuc_ has joined #openstack-neutron14:57
*** tvardeman has joined #openstack-neutron14:58
*** sacharya has joined #openstack-neutron14:58
*** baoli has quit IRC14:59
openstackgerritrcurran proposed a change to openstack/neutron: ML2 Cisco Nexus MD: Remove workaround for bug 1276395  https://review.openstack.org/8283915:01
*** carl_baldwin has joined #openstack-neutron15:02
*** luqas has quit IRC15:03
*** aveiga has quit IRC15:03
enikanorov_markmcclain: so would you suggest to file a new bug for that change? or change the commit message?15:03
*** networkstatic_zZ has quit IRC15:03
*** devlaps has joined #openstack-neutron15:04
*** jobewan has joined #openstack-neutron15:05
*** baoli has joined #openstack-neutron15:05
*** leseb has joined #openstack-neutron15:05
*** ygbo has quit IRC15:06
*** carlp has joined #openstack-neutron15:07
pcm__enikanorov_: Thanks. I couldn't figure out what the issue was, seemed like a time out. Ran again and got same result.15:09
pcm__enikanorov_: Do you know how to setup environment to run tox with py26?15:09
openstackgerritMiguel Angel Ajo proposed a change to openstack/neutron: fixes broken neutron-netns-cleanup  https://review.openstack.org/8026115:10
*** ygbo has joined #openstack-neutron15:11
*** saju_m has quit IRC15:13
*** humbolt1 has joined #openstack-neutron15:14
*** networkstatic has joined #openstack-neutron15:14
*** humbolt1 has quit IRC15:14
*** packet has joined #openstack-neutron15:14
*** humbolt has quit IRC15:14
*** nplanel has quit IRC15:14
*** humbolt has joined #openstack-neutron15:15
*** humbolt has quit IRC15:15
*** humbolt has joined #openstack-neutron15:16
*** humbolt has quit IRC15:16
*** nplanel has joined #openstack-neutron15:17
*** humbolt has joined #openstack-neutron15:17
*** humbolt has quit IRC15:17
*** pcm__ has quit IRC15:18
*** tvardeman has quit IRC15:18
*** humbolt has joined #openstack-neutron15:18
*** humbolt has quit IRC15:18
*** pcm_ has joined #openstack-neutron15:19
*** humbolt has joined #openstack-neutron15:19
*** humbolt has quit IRC15:19
*** humbolt has joined #openstack-neutron15:20
*** humbolt has quit IRC15:20
*** changbl has joined #openstack-neutron15:20
*** pcm___ has joined #openstack-neutron15:20
*** humbolt has joined #openstack-neutron15:21
*** xuhanp has quit IRC15:21
*** humbolt has quit IRC15:21
*** humbolt has joined #openstack-neutron15:21
*** devvesa has joined #openstack-neutron15:21
*** humbolt has quit IRC15:21
*** tvardeman has joined #openstack-neutron15:22
*** humbolt has joined #openstack-neutron15:22
anteayahumbolt: please check your client15:22
*** humbolt has quit IRC15:22
*** rkukura has quit IRC15:23
*** humbolt has joined #openstack-neutron15:23
*** humbolt has quit IRC15:23
*** pcm_ has quit IRC15:23
*** humbolt has joined #openstack-neutron15:24
*** humbolt has quit IRC15:24
*** mestery has quit IRC15:24
jaypipesmarun: ready for a review on https://review.openstack.org/#/c/72585/ yet? (I know you've been pushing a lot of patchsets on that, just want to make sure you're ready for a review :)15:25
*** humbolt has joined #openstack-neutron15:25
*** humbolt has quit IRC15:25
*** humbolt has joined #openstack-neutron15:26
*** humbolt has quit IRC15:26
*** humbolt has joined #openstack-neutron15:27
*** humbolt has quit IRC15:27
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278715:27
*** humbolt has joined #openstack-neutron15:29
*** humbolt has quit IRC15:29
*** humbolt has joined #openstack-neutron15:30
*** dave_tucker is now known as dave_tucker_zzz15:30
*** otherwiseguy has quit IRC15:32
*** itzikb has quit IRC15:35
*** emagana has joined #openstack-neutron15:38
*** feleouet has quit IRC15:38
*** krtaylor has quit IRC15:42
*** BillTheKat has joined #openstack-neutron15:42
*** rossella_ has quit IRC15:44
*** alexpilotti has joined #openstack-neutron15:44
*** rossella_ has joined #openstack-neutron15:45
*** bashok has quit IRC15:45
*** alexpilotti has quit IRC15:46
*** markwash has joined #openstack-neutron15:46
ihrachysanyone with stable +2 rights? I have some patches that I would like to see in stable branch before the next release cut off?15:47
ihrachyss/\?$//15:47
markmcclainihrachys: stable gating for Neutron is not stable15:47
*** SumitNaiksatam has quit IRC15:47
markmcclain+2ing anything is likely to result in a gate failure15:47
*** alagalah has joined #openstack-neutron15:47
enikanorov__^^ sounds funny :)15:48
*** _cjones_ has joined #openstack-neutron15:48
*** _cjones__ has joined #openstack-neutron15:49
ihrachysmarkmcclain: hm, I didn't know that. The last time I've asked apevec about stable gate state, he said everything is fine now. :|15:49
markmcclainthe kernel bug still shows up in the gate15:50
ihrachysmarkmcclain: is it neutron only?15:50
*** krtaylor has joined #openstack-neutron15:50
markmcclainso anything that is approved for Neutron has decent chance of hitting the bug15:50
*** thuc_ has quit IRC15:51
*** luqas has joined #openstack-neutron15:51
*** thuc has joined #openstack-neutron15:51
*** _cjones_ has quit IRC15:52
*** alagalah has quit IRC15:52
openstackgerritSean M. Collins proposed a change to openstack/neutron: QoS API and DB models  https://review.openstack.org/2831315:52
openstackgerritSean M. Collins proposed a change to openstack/neutron: Quality of Service API extension - RPC & Driver support  https://review.openstack.org/5997015:52
ihrachysmarkmcclain: is there any list of known issues that I can start to work on?15:53
markmcclainso have to work altering the stable tests15:54
markmcclainto disable key injection15:54
*** apevec has joined #openstack-neutron15:56
*** thuc has quit IRC15:56
ihrachysapevec: markmcclain claims there are still issues with stable gating, related to key injection triggering kernel oops15:56
apevecmarkmcclain, hi - ihrachys says there are still stable neutron gate issues, what are examples?15:56
*** amotoki_ has joined #openstack-neutron15:56
apevecwasn't key injection disabled or somehting?15:56
markmcclainapevec: only in master15:56
markmcclainstill running for some stable tests15:57
apevecdamn15:57
*** packet has quit IRC15:57
apevecwhat prevents us to do it on stable/havana too?15:57
*** yfried has quit IRC15:57
*** devvesa has quit IRC15:58
markmcclainapevec: really just have to find the test cases where it is still being activated15:58
markmcclainI thought I had tracked them all down, but was noticing failures still15:58
*** dvorkinista has joined #openstack-neutron15:59
*** alagalah has joined #openstack-neutron15:59
*** packet has joined #openstack-neutron15:59
*** mestery has joined #openstack-neutron15:59
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278716:01
*** alagalah has quit IRC16:01
*** Sukhdev has joined #openstack-neutron16:02
*** devvesa has joined #openstack-neutron16:04
*** SumitNaiksatam has joined #openstack-neutron16:04
*** dvorkinista has quit IRC16:04
*** Sukhdev has quit IRC16:06
apevecmarkmcclain, how can I help tracking those down, do you have an example what to look for in tempest?16:07
apevecwe're supposed to freeze stable/havana for 2013.2.3 this Thursday16:08
*** baoli has quit IRC16:08
markmcclainapevec: it is not a tempest thing16:08
markmcclainthe error is in how the devstack instance is configured16:09
markmcclainI'm trying to find an example review16:09
*** mestery has quit IRC16:09
*** SumitNaiksatam has quit IRC16:10
*** mestery has joined #openstack-neutron16:10
*** SumitNaiksatam has joined #openstack-neutron16:10
*** baoli has joined #openstack-neutron16:10
*** Jabadia has quit IRC16:12
*** Jabadia has joined #openstack-neutron16:12
*** dave_tucker_zzz is now known as dave_tucker16:13
*** skraynev_afk is now known as skraynev16:14
*** rkukura has joined #openstack-neutron16:16
*** nati_ueno has joined #openstack-neutron16:17
*** Jabadia has quit IRC16:17
*** blogan has joined #openstack-neutron16:19
*** markwash has quit IRC16:20
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278716:22
*** markwash has joined #openstack-neutron16:23
openstackgerritAaron Rosen proposed a change to openstack/neutron: Who's CI is lying! :)  https://review.openstack.org/7530416:24
*** spandhe has joined #openstack-neutron16:25
*** thuc has joined #openstack-neutron16:25
*** thuc has quit IRC16:26
*** thuc has joined #openstack-neutron16:26
*** alagalah has joined #openstack-neutron16:27
*** nati_ueno has quit IRC16:30
*** catohornet__ has joined #openstack-neutron16:31
*** alagalah has quit IRC16:34
*** Longgeek has quit IRC16:35
*** Longgeek has joined #openstack-neutron16:35
*** tomoe_ has quit IRC16:38
_cjones__kevinbenton, You around today?16:38
*** Longgeek has quit IRC16:42
*** spandhe has quit IRC16:43
markmcclainapevec: http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkZpeGluZyByZWN1cnNpdmUgZmF1bHQgYnV0IHJlYm9vdCBpcyBuZWVkZWRcIiBBTkQgYnVpbGRfYnJhbmNoOlwic3RhYmxlL2hhdmFuYVwiIEFORCBidWlsZF9xdWV1ZTpcImdhdGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiYWxsIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiIsInN0YW1wIjoxMzk1NzY1ODk0MzEyfQ==16:45
*** markwash_ has joined #openstack-neutron16:48
*** markwash has quit IRC16:49
*** markwash_ is now known as markwash16:49
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278716:49
kevinbenton_cjones_: yep16:53
*** rossella_s has joined #openstack-neutron16:54
*** spandhe has joined #openstack-neutron16:57
*** jistr|training has quit IRC16:58
*** dave_tucker is now known as dave_tucker_zzz17:00
*** markmcclain1 has joined #openstack-neutron17:01
*** markmcclain1 has quit IRC17:01
*** tomoe_ has joined #openstack-neutron17:01
*** markmcclain1 has joined #openstack-neutron17:02
*** markmcclain has quit IRC17:02
*** nati_ueno has joined #openstack-neutron17:02
*** roeyc has quit IRC17:02
*** harlowja has joined #openstack-neutron17:03
*** rossella_ has quit IRC17:04
*** morganfainberg_Z is now known as morganfainberg17:04
*** _cjones__ has quit IRC17:05
*** sacharya has quit IRC17:05
*** _cjones_ has joined #openstack-neutron17:05
*** zzelle has joined #openstack-neutron17:06
*** claudiub has joined #openstack-neutron17:06
_cjones_kevinbenton: I think I worked around my tox issues. HFS+ on Mac seemed to be the cause of a bunch of issues. Out of curiousity how do you go abouts debugging your unit tests? Is there a standard procedure for this in Neutron (ML2)17:07
zzellemarkmcclain1, hi17:07
markmcclain1zzelle: hi17:10
*** manishg has joined #openstack-neutron17:10
*** ramishra has quit IRC17:11
*** safchain has quit IRC17:11
*** peristeri has quit IRC17:11
zzellemarkmcclain1, i corrected a small bug about L3 agent using deprecated root_helper option, i think it could be added to the RC17:11
zzellemarkmcclain1, https://review.openstack.org/82746/17:12
zzellemarkmcclain1, without the correction extraroute could be not applied17:12
*** beagles is now known as beagles_brb17:12
apevecmarkmcclain1, so this is bug 1273386 which is worked around in master by switching to config drive but stable/havana devstack is missing support for that ?17:13
*** ramishra has joined #openstack-neutron17:13
openstackgerritKevin Benton proposed a change to openstack/neutron: (WIP) BigSwitch: hybrid routing model for plugin  https://review.openstack.org/8287317:14
*** ygbo has quit IRC17:15
kevinbenton_cjones_: is it to the point where all of the tests seem to run now?17:15
apevecdevstack-gate (which has master only) sets FORCE_CONFIG_DRIVE by default but that envvar is not present in devstack stable/havana, so ignored there17:15
_cjones_kevinbenton: Have not tried all no. Is that worth a road going down?17:15
kevinbenton_cjones_: probably not if you already have one unit test that fails. I start by running the unit test module that fails. for example. tox -v -epy27 tests.unit.ml2.drivers.test_bigswitch_mech will run the tests in neutron/tests/unit/ml2/drivers/test_bigswitch_mech.py17:17
apevecmarkmcclain1, I'll propose https://review.openstack.org/54746 for devstack stable/havana17:18
kevinbenton_cjones_: once you get failures, you should get some useful information about the failure that will tell you what your change did wrong or that the unit tests will require an update to match your change17:18
*** leseb has quit IRC17:21
*** catohornet__ has quit IRC17:24
*** zzelle has quit IRC17:25
_cjones_kevinbenton: Fair enough. I'll ensure the others are passing. I think the main issue is in the tests for the driver I wrote which is why I was hoping for a debug procedure.17:28
*** amotoki_ has quit IRC17:29
*** salv-orlando has joined #openstack-neutron17:30
openstackgerritSean M. Collins proposed a change to openstack/neutron: Ml2 QoS API extension support  https://review.openstack.org/5997117:31
*** skraynev is now known as skraynev_afk17:32
*** jprovazn has quit IRC17:32
openstackgerritMaru Newby proposed a change to openstack/neutron: Refactor plugin setup helpers out of test.base  https://review.openstack.org/8277517:34
*** Sukhdev has joined #openstack-neutron17:35
_cjones_kevinbenton: Here's the output when running tox -v -epy27 tests.unit.ml2:17:35
*** tomoe_ has quit IRC17:35
_cjones_https://gist.github.com/cjones-/bcc6fab369861b12c00a17:36
_cjones_Not really much to determine why I got those 2 failures.17:36
*** markmcclain1 has quit IRC17:36
*** spandhe has quit IRC17:37
*** devvesa has quit IRC17:39
openstackgerritKevin Benton proposed a change to openstack/neutron: Disable XML tests on Py26  https://review.openstack.org/8186517:41
*** devvesa has joined #openstack-neutron17:41
*** alagalah has joined #openstack-neutron17:41
kevinbenton_cjones_: yeah, that's not very helpful. anything useful in .testrepository/failing ?17:44
claudiubhello guys, could you take a look at a backport bug fix? Already has plenty of +1s. https://review.openstack.org/#/c/63775/17:44
_cjones_kevinbenton: Yup. https://gist.github.com/cjones-/f3fac6308462babf2b9817:45
_cjones_Pretty sure that has nothing to do with me, but I'm trying again w/o any of my changes.17:45
*** alagalah has quit IRC17:45
kevinbenton_cjones_: another thing you can do is see if that test fails by itself. tox -v -epy27 neutron.tests.unit.ml2.drivers.test_cisco_mech.TestCiscoSubnetsV2.test_create_subnet_with_two_host_routes17:46
*** markmcclain has joined #openstack-neutron17:46
_cjones_Good call17:46
*** SumitNaiksatam has quit IRC17:47
_cjones_Hah. Passed!17:47
_cjones_:| That's a little disconcerting.17:48
*** mestery_ has joined #openstack-neutron17:48
markmcclainapevec: yes need to enable config drive or metadata for test17:48
*** mestery has quit IRC17:48
markmcclainzzelle: approved17:48
*** spandhe has joined #openstack-neutron17:49
kevinbenton_cjones_: maybe try a re-run. the 'killed' part seems like something intervened but I'm not sure why17:49
*** SumitNaiksatam has joined #openstack-neutron17:50
*** mestery_ is now known as mestery17:50
*** armitage81 has joined #openstack-neutron17:50
_cjones_kevinbenton: I'm wondering if my vagrant/VBox combo is too slow and something is timing out causing subsequent failures.17:50
*** armitage81 has quit IRC17:51
*** armitage81 has joined #openstack-neutron17:51
kevinbenton_cjones_: which os are the UTs running on?17:51
*** mlavalle has joined #openstack-neutron17:51
_cjones_kevinbenton: Ubuntu Server 12.0417:52
*** sphoorti has joined #openstack-neutron17:52
*** spandhe has quit IRC17:52
*** spandhe has joined #openstack-neutron17:54
*** jgallard has quit IRC17:56
kevinbenton_cjones_: same set of tests passed in my dev VM in 240 seconds, so I don't think that's the problem17:56
kevinbenton_cjones_: have the unit tests in that folder always been run from the same VM/OS? If so, it might be worth wiping out the .tox and .testrepository directories so it starts out clean17:58
*** markmcclain has quit IRC17:58
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278717:59
nati_uenosdague: markmcclain: around?18:00
_cjones_kevinbenton: Yeah. I tried with a fresh clone (no changes by me). I get a different set in ./testrepository/failing.  I think this may be a timing thing. I'll see what I can glean. I've got enough insight to the process to keep me busy for a bit. Thanks :)18:00
sdaguelooks like we just lost mark18:00
sdaguehowever there are probably other neutron cores18:00
sdaguehttps://review.openstack.org/#/c/82880/  - is a tempest proposed patch to drop a neutron test18:00
*** changbl has quit IRC18:00
*** thedodd has quit IRC18:00
salv-orlandosdague: I can stand in for mark18:00
sdaguewhich is required by this https://review.openstack.org/#/c/21946/ neutron test18:00
sdaguein order to drop a tempest test, we have a policy of requiring a +2 on the dependant change18:01
sdagueto make sure it's not some crazy drive by18:01
sdaguebut actually a change the team in question wants18:01
*** catohornet__ has joined #openstack-neutron18:01
salv-orlandonati-ueno, sdague: we know the blocker here might be this: https://review.openstack.org/#/c/44596/18:01
sdagueso if we could get a +2 on https://review.openstack.org/#/c/21946/18:01
sdaguesalv-orlando: so we also need a +2 there then by nova18:02
salv-orlandosdague: +2'ind that will solve the tempest dependency (maybe) but that very patch should not be merged if we not have a committment from nova on 4459618:02
sdagueok, sure18:02
sdagueso I guess someone needs to chase a +2 on the nova patch as well18:02
salv-orlandoin a nutshell: if it does not make nova-rc1 then there's no game18:02
sdagueok, is this something russell is tracking for rc1?18:03
*** beagles_brb is now known as beagles18:03
nati_uenoI'll discuss with russel18:04
nati_uenoI'm also fixing 44596 now18:04
openstackgerritMaru Newby proposed a change to openstack/neutron: Add support for retargetable functional api testing  https://review.openstack.org/7258518:05
*** Matt2 has left #openstack-neutron18:06
*** packet has quit IRC18:07
*** banix has quit IRC18:08
*** peristeri has joined #openstack-neutron18:10
*** packet has joined #openstack-neutron18:11
*** emagana has quit IRC18:12
*** emagana has joined #openstack-neutron18:12
*** banix has joined #openstack-neutron18:12
*** yfried has joined #openstack-neutron18:13
*** catohornet__ has quit IRC18:15
*** Matt1 has joined #openstack-neutron18:16
*** changbl has joined #openstack-neutron18:19
*** Jabadia has joined #openstack-neutron18:22
*** Jabadia has quit IRC18:23
*** spandhe has quit IRC18:23
*** Jabadia has joined #openstack-neutron18:23
*** shakamunyi has joined #openstack-neutron18:25
*** shakamunyi has quit IRC18:25
*** shakamunyi has joined #openstack-neutron18:26
*** shakamunyi has quit IRC18:26
*** catohornet__ has joined #openstack-neutron18:27
*** spandhe has joined #openstack-neutron18:30
*** manishg_ has joined #openstack-neutron18:33
*** mlavalle_ has joined #openstack-neutron18:36
*** manishg has quit IRC18:37
*** manishg_ is now known as manishg18:37
*** sphoorti has quit IRC18:37
*** mlavalle has quit IRC18:37
*** mlavalle_ is now known as mlavalle18:37
*** alagalah has joined #openstack-neutron18:41
*** overlayer has quit IRC18:44
*** linuxgeek_ has joined #openstack-neutron18:44
*** devlaps1 has joined #openstack-neutron18:44
*** yfried has quit IRC18:45
*** yfried has joined #openstack-neutron18:45
*** alagalah has quit IRC18:46
*** devlaps has quit IRC18:46
*** peristeri has quit IRC18:46
*** crc32 has joined #openstack-neutron18:47
*** BillTheKat has joined #openstack-neutron18:47
*** BillTheKat is now known as Gil_McGrath18:48
*** thuc has quit IRC18:48
*** thuc has joined #openstack-neutron18:49
*** apevec has quit IRC18:49
*** jpich has quit IRC18:49
*** dfarrell07 has joined #openstack-neutron18:50
*** shakayumi has joined #openstack-neutron18:50
*** shakayumi has quit IRC18:50
*** thuc has quit IRC18:51
*** thuc_ has joined #openstack-neutron18:51
*** shakayumi has joined #openstack-neutron18:51
*** dave_tucker_zzz is now known as dave_tucker18:52
*** BuSerD has joined #openstack-neutron18:53
marunnati_ueno: is there a reason the proposed patch is so complicated?18:54
nati_uenomarun: vif security one?18:55
*** zzelle has joined #openstack-neutron18:55
marunnati_ueno: yes18:55
*** ramishra has quit IRC18:55
marunnati_ueno: why isn't it just fixing the regression?18:55
marunadding new capabilities would appear to just have slowed down acceptance.18:55
*** ramishra has joined #openstack-neutron18:55
marunespecially on the nova side18:55
nati_uenomarun: you are right18:55
*** singhs has joined #openstack-neutron18:55
nati_uenomarun: let's fix back to previous patch18:56
marunso is it possible to backtrack and just submit the simplest thing that could possibly work?18:56
nati_uenomarun: let's me check when this bug comes in18:56
marunif we engage the nova guys, maybe we can get this merged today18:56
marunok18:56
marundansmith: ^^18:57
linuxgeek_hi when i execute neutron net-list or any other neutron command i get authentication required18:57
linuxgeek_and the neutron-server.log has WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token xxxxxx18:57
linuxgeek_i have verified the conf files of neutron and nova, it seems ok18:58
linuxgeek_any help/pointers pls18:58
dansmithmarun:  if it's not targeted to -rc1 it's not getting looked at right now18:58
dansmithmarun: ping tjones in -nova with the bug to get it targeted if it's important for -rc118:59
*** jistr has joined #openstack-neutron18:59
*** thedodd has joined #openstack-neutron18:59
*** ramishra has quit IRC18:59
marundansmith: it's important - neutron security groups are still broken18:59
pcm___nati_ueno: ping19:00
*** jlibosva has quit IRC19:00
marunnati_ueno: who have you been engaging with on the nova side of this?19:00
dansmithmarun: if it's a regression from havana and the fix is reasonable, then it should be doable19:00
dansmithmarun: if it's not a regression, then I think it might as well wait at this point19:00
marundansmith: yes, it's a regression.  we'll work on getting a reasonable fix up in short order19:00
dansmithokay19:00
nati_uenopcm___: sorry i'm busy now..19:00
*** gdubreui has joined #openstack-neutron19:00
pcm___nati_ueno: Can you review these two... https://review.openstack.org/#/c/81124/ and https://review.openstack.org/#/c/82306/ when you can?19:01
nati_uenopcm___: I'll ping you back19:01
nati_uenomarun: This is the patch https://review.openstack.org/#/c/49660/519:01
*** jprovazn has joined #openstack-neutron19:02
nati_uenomarun: if we revert this one, we could have a valid set of configraion. But I'm not sure these drivers still works19:02
nati_uenomarun: Let's me test this19:02
marunnati_ueno: ok.19:02
marunlet me know how I can help19:02
maruni'll talk to tjones in #nova19:02
nati_uenomarun: Thanks!19:03
*** shakayumi has quit IRC19:05
claudiubWhen you have a little time, can you guys review this one? :) https://review.openstack.org/#/c/63775/19:07
*** markwash has quit IRC19:08
openstackgerritYuriy Taraday proposed a change to openstack/neutron: Abstract out root_helper calls to classes  https://review.openstack.org/8278719:08
marunnati_ueno: what about merging the complex patch on the neutron side but only a minimal patch on the nova side?19:08
marunnati_ueno: i.e. pass all the details in to nova, but nova only uses it for firewall yes/no19:09
linuxgeek_marun, neutron security groups are still broken - i'm seeing this on i3 env. is there a bug for this?19:09
marunsalv-orlando: ^19:09
nati_uenomarun: if you take the way, I think current patch is minimal https://review.openstack.org/#/c/44596/19:09
marunlinuxgeek_: we're talking about it right now.19:09
nati_uenomarun: it is just 141 ilne19:09
marun'just'19:09
nati_uenomarun: haha sorry19:09
marunnati_ueno: this isn't working19:09
marunnati_ueno: what's the simplest patch that could possibly work on the nova side?19:10
marunnati_ueno: you can submit a follow-up in juno to make more use of the details passed in by neutron19:10
marunnati_ueno: (or maybe even this cycle)19:10
linuxgeek_marun, thanks. btw do you have any thoughts on the neutron auth required issue?19:10
marunnati_ueno: but the priority is the regression19:10
nati_uenomarun: I think simplest is reverting original one19:10
marunnati_ueno: which one?19:10
nati_uenomarun: https://review.openstack.org/#/c/49660/519:10
*** SumitNaiksatam has quit IRC19:11
marunnati_ueno: so is the answer that without the old vif code we need a complex solution?19:12
nati_uenomarun: https://review.openstack.org/#/c/44596/9/nova/virt/libvirt/vif.py19:12
beaglesnati_ueno, what about taking the detail that tells nova that we need to support firewalling and push that along instead of pulling in the other details19:12
nati_uenomarun: so what's we really needs is fixing few lines19:12
beaglesnati_ueno, ie. just a flag down in the model and the vif driver?19:12
nati_uenobeagles: Ah That's one way19:12
*** SumitNaiksatam has joined #openstack-neutron19:13
marunnati_ueno: that sounds like the way to go!19:13
marunnati_ueno: -> nova inspects the port and decides firewall yes/no19:14
nati_uenomarun: sorry, let me make it clear19:14
beaglesand I guess we could do that neutronv2/api.py instead of pushing neutron details down into the nova code19:14
nati_uenomarun: (option1) current patch (neturon + nova)19:14
nati_ueno(option2) nova only with flag19:14
*** yfried has quit IRC19:14
marunnati_ueno: option2++19:14
nati_uenogotcha, I think I can push it in 2-3 hours19:15
marunnati_ueno: wait, what do you mean by flag?19:15
marunlike a config option?19:15
nati_uenomarun: yes19:15
marunor can nova figure out what to do from port details??19:15
marunwhy is this hard?19:15
nati_uenomarun: Actually, that is option119:15
marunnati_ueno: so simplify option 119:15
rkukuranati_ueno: are you still planning to have nova pass vif_details though to the VIF driver?19:15
marunnati_ueno: provide enough detail in the port, we'll get the damn patch merged asap19:16
marunrkukura: we need something simpler19:16
marunrkukura: we need something that can _merge_19:16
rkukurathat’s as simple as possible19:16
marunrkukura: the current approach of adding complexity not needed to fix the regression != simple as possible19:16
nati_uenomarun: so how we can simplify the patch?19:16
marunnati_ueno: pass in port details -> use_firewall = True19:16
marunnova checks port details, use_firewall = port_details.get('use_firewall, False)19:17
marunwould that work?19:17
nati_uenomarun: Isn't is simple as current solution?19:17
nati_uenomarun: it is almost same19:17
marunnati_ueno: 141 lines?19:17
marunin review for a year?19:17
marunreallly?19:17
nati_uenomarun: yes. Including test code19:17
*** claudiub has quit IRC19:17
beaglesnati_ueno, I think the difference is in the minimalistic changes to the data model19:17
nati_uenomarun: I believe it will be 120 line or something like that19:17
nati_uenomarun: actulal changes are really few lines19:18
*** openstackgerrit has quit IRC19:18
marunnati_ueno: if this were simple it would be merged already19:18
marunnati_ueno: and we wouldn't be having this discussion19:18
beaglesnati_ueno, so instead of several options, you only add one.. the purpose of which is pretty clear19:18
rkukurawhat if we kept the current neutron code where vif_details contains just the single item, and pass the vif_details through nova to the driver, and have the nova VIF driver just use that one flag?19:18
marunrkukura: +119:18
*** openstackgerrit has joined #openstack-neutron19:18
marunrkukura: that's what i'm suggesting (I think)19:18
nati_uenomarun: rkukura: I'm taking that option now19:18
nati_uenomarun: sorry it may confising, current code is old, I'm testing new version with Bob's sugestion localy now19:19
*** sphoorti has joined #openstack-neutron19:19
beagleswe should determine if storing the vif_details for this purpose is contentious and would be an obstacle to mergin19:19
rkukurabeagles: Any reason to think it would be contentious?19:19
marunrkukura: because we're in rc?19:20
marunrkukura: the patch on the nova side isn't even on nova's radar right now!19:20
marunrkukura: if we're doing anything more than required to fix the security group regression, we're going to have a harder time than necessary19:20
rkukurabeagles: Passing vif_details though as part of the VIF object seems to require minimal change to most of the nova code, but still lets vif_details be used for finer grained security control, and/or SR-IOV in the future19:21
beaglesrkukura, I think it might be... does it pose migration/upgrade issues, etc. it would be fine for opaque data maybe, but this isn't.. .it is being used by nova itself19:21
marunrkukura: fsck finger grained control in the future19:21
marunrkukura: the time for adding stuff was pre-rc19:21
marunrkukura: even if we could get away with it on the neutron side, we have the nova side to content with19:21
beaglesrkukura, yeah... I know we discussed this in the past and it seemed good to me at the time, but when I thought through the implications (not to mention got a good slap upside the head) I think we need to be more cautious with that kind of approach19:22
rkukuraIs the VIF object persisted by nova, or is this just used locally in the compute node?19:22
nati_uenorkukura: it is locally19:22
*** linuxgeek_ has left #openstack-neutron19:22
beaglesrkukura, the information we need right now is whether or not to enable the ovs hybrid bridge19:22
rkukuraSeems we need to add something to the VIF object - so I don’t see any different risk in adding the vif_details dict vs. adding some special-purpose flag.19:22
nati_uenoI agree19:23
marunrkukura: I see a risk19:23
maruna risk that it will complicate review19:23
marunwe don't add things now19:23
*** claudiub has joined #openstack-neutron19:23
nati_uenomarun: so IMO, revering back is a good way for now19:23
nati_uenomarun: I'm not sure why,,, but this fix get fuge discussions...19:24
marunnati_ueno: so cut out _everything_ that complicates it19:24
nati_uenomarun: ok so let's get back to previous vif driver if it is working19:24
nati_uenomarun: no generalizeation19:25
nati_uenomarun: the revering is safe, because it is adding drivers19:25
rkukuraseriously, is passing the vif_details as part of the VIF object and having the OVS vif driver look at vif_details[CAP_PORT_FILTER] that risky?19:25
marunnati_ueno: that's not safe19:26
marunnati_ueno: beagles tells me that politically on the nova side reverting that change would be an uphill battle19:26
beaglesit *could* be a battle :)19:26
*** alagalah has joined #openstack-neutron19:26
*** catohornet__ has quit IRC19:26
nati_uenomarun: In Japanese sayings, there is a tigar in front of me, and there is a wolf in the back of me..19:27
rkukuramarun: I’m not clear on what you are saying isn’t safe?19:27
beaglesrkukura, I think the issue isn't how difficult or complex the test it is the implications of storing this data... say the dictionary changes in Juno19:27
*** jp_at_hp has quit IRC19:27
beaglesrkukura, then we need some way to transform that data... in nova... isn't that weird?19:27
*** BuSerD has quit IRC19:28
rkukurathat’s the whole point of the approach - to be less brittle, easier to evolve, etc.19:28
beaglesbut but but but19:28
rkukurawhy is anything but null transform needed?19:28
beagleswho transforms the data?19:28
nati_uenoIF revering is a risk19:28
beaglesall the old vif details would be .. broken?19:28
nati_uenosimplest is19:28
nati_uenousing flag(config)19:28
nati_uenoThis needs only nova side fix19:28
rkukuratransforming the data is what makes this so difficult - that’s why I’ve been advocating just passing vif_details through untouched end-to-end19:29
marunnati_ueno: find a champion on the nova side to push that and *maybe* it's an option19:29
beaglesrkukura, let's not forget that nova is using that info.. but let's back up19:29
marunnati_ueno: also not free/easy from a deployment perspective19:29
marunnati_ueno: easy for a developer using devstack, sure19:29
beagleswe need to get the security group functionality working.. how are we going to do it?19:30
nati_uenomarun: anyway, we need to have a discussion with nova guys19:30
marunnati_ueno: so, do you have someone on that side you've been working with?19:30
nati_uenomarun: yes. That's the intension of the orignal fix19:30
marunnati_ueno: the original intention, I'll believe19:30
beaglesactually nati_ueno, if you have a way you have a good feeling will get through.. man you should do it.19:31
nati_uenomarun: Brian Haley reviewed this recently19:31
marunnati_ueno: is he core?19:31
beaglesI'm coming at this kind of from left field... so I could be off-base and the last thing I want to do is lead folks astray or in circles19:31
nati_uenomarun: I'm not sure.. do you know some cores who may review this?19:32
marunnati_ueno: *sigh*19:32
*** luqas has quit IRC19:32
marunnati_ueno: the first step in merging a patch in nova should be engaging one or more nova core19:33
marunnati_ueno: right now getting attention is all but impossible19:33
marunnati_ueno: i.e. if you were serious about merging this the time to engage with nova cores was pre-rc19:33
marunnati_ueno: is there anyone you were talking to at least?19:33
nati_uenomarun: sorry I was focusing on neutron side. This nova fix depends on it19:34
nati_uenomarun: Without neutron fix, tempest won't success on nova side19:34
nati_uenomarun: even if neturon side isn't merged yet19:34
marunnati_ueno: ok19:34
*** baoli has quit IRC19:35
*** Sukhdev has quit IRC19:35
nati_uenomarun: I'm keep working on this, and requested ton's of mails..19:35
nati_uenobut it causes new discussion..19:35
*** BuSerD has joined #openstack-neutron19:35
nati_uenoso reverting the patch is only realistic way for me19:37
*** jecarey has quit IRC19:37
marunnati_ueno: reverting/adding a new flag19:37
marunnati_ueno: so we need nova buy-in19:37
nati_uenoI'm not sure the patch will be merged even if it is neutron side19:37
nati_uenook19:38
nati_uenorussellb: Can we have a quick discussion?19:38
*** baoli has joined #openstack-neutron19:38
marunrussellb: double plus important19:38
* russellb perks up19:39
russellbo/19:39
nati_uenorussellb: Thank you for taking time for this such a busy time19:39
nati_uenorussellb: sorry I should inform you this more earlier, but actually security group fro neturon + nova + ovs19:39
nati_uenois broken now19:39
russellbi saw the patches just a couple minutes ago19:40
russellblooked like they started way back in Havana dev19:40
russellbhas it been broken that long (or longer) ?19:40
marunrussellb: it's been broken as of icehouse (removal of hybrid vif driver)19:40
nati_uenorussellb: yes. We are working on fixing neutron side fix, and it takes long time19:40
nati_uenorussellb: neutron side fix isn't merged yet19:40
marunrussellb: we're so late in the cycle that fixing things properly (neutron passing in vif details to determine firewall yes/no) seems like a hard sell19:40
russellbyes, it's very late :-)19:41
marunrussellb: the dirty fix is - nova configured to use/not use firewall19:41
marunrussellb: either by reverting removal of hybrid vif driver19:41
nati_uenoor revert the removal of hybrid vif driver19:41
marunrussellb: ...or setting an explicit flag that has the same effect19:41
russellbcan you expand on what you mean by "nova configured to use/not use firewall" ?19:41
russellbyou mean, you just have to turn it on manually?19:41
russellbinstead of determining it via info neutron passes in?19:42
marunrussellb: that's the way it used to work, per-compute host configuration19:42
nati_uenorussellb: so we should select hybrid vif plugging method when we are using OVS19:42
rkukurarussellb: note that neutron is already including a flag in the vif_details port attribute that nova could use19:42
nati_uenorussellb: Original intension was passing that information from neturon to nova19:42
nati_uenorussellb: but it is too late, so another option is configuring it by confi19:42
marunrkukura: and we've definitively worked out the details of how that will be persisted/upgraded/etc to merge so late in the cycle?19:42
russellbhow is this just coming up?19:42
russellbthis isn't tested?19:43
marunrussellb: we're asking ourselves the same question. :(19:43
marunrussellb: somehow this kept slipping and slipping and slipping...19:43
marunrussellb: trying to agree on the 'right' fix, and the fact that the regression should have priority was lost in translation19:43
russellba config option sounds reasonable i guess, if that's what we have to do19:43
nati_uenorussellb: sure I'll send the patch in 2-3 hours. I'll ping you when I push it19:44
russellbbut honestly, i'm not willing to block on this19:44
russellbOK19:44
russellbif it can be ASAP we can probably get it in19:44
russellbmake it as simple as possible to ease review19:44
nati_uenorussellb: I got it19:44
marunrussellb: we'll do everything we need to to make it happen19:44
russellbok19:44
marunrussellb: it's top priority on the neutron side19:44
*** shakayumi has joined #openstack-neutron19:45
russellbOK19:45
nati_uenorussellb: Thank you for your talking time on this19:45
marunrussellb: danke19:45
russellbsure, thanks for working on a quick fix for it19:45
*** shakayumi has quit IRC19:45
zzellemarun, rkukura, hi19:45
marunnati_ueno: so what needs to happen to get this fix in?19:46
marunnati_ueno: nova patch, check.  will a devstack patch be required?19:46
marunzzelle: hi19:46
*** jecarey has joined #openstack-neutron19:46
nati_uenomarun: In order to get tempest success, it is enough if we have nova side patch only.. (This sounds not good, but it is reality)19:47
nati_uenoI just take a look code again, and option2'19:47
marunnati_ueno: because negative tests couldn't merge so long as things were broken?19:47
nati_uenois coming up to me19:47
nati_uenomarun: yep19:47
marunnati_ueno: ah, okk.19:48
zzellemarun, could you re-approve https://review.openstack.org/#/c/82746/ which has failed gate check, a priori because of a false negative test19:48
nati_uenooption2' is add new vif driver inherits require_iptables_option19:48
marunnati_ueno: then we can coordinate with yfried to get the tempest tests merged as soon as the nova patch does19:48
nati_uenooption2' is add new vif driver inherits  LibvirtGenericVIFDriver19:48
marun?19:48
nati_uenoIn this case, there is no need to add new flag19:48
*** sphoorti has quit IRC19:48
nati_uenoso code will be more simple19:48
zzellemarun, the change is only replacing the deprecated root_helper by the "next" one and passed others tests19:49
marunnati_ueno: so we go back to the old way of specifying a vif driver?19:50
zzelles/next/new/19:50
marunnati_ueno: I think that makes sense.19:50
marunzzelle: right, test timeout.  i'll reapprove19:50
nati_uenomarun: I'll push wip code soon, let's discussion on code19:50
zzellemarun, thanks :)19:51
marunnati_ueno: ok i'll be online until 2:30 pst, then back at 4:3019:52
*** shakayumi has joined #openstack-neutron19:54
*** emagana has quit IRC19:55
*** ramishra has joined #openstack-neutron19:56
*** shakamunyi has joined #openstack-neutron19:56
*** shakayumi has quit IRC19:58
*** leseb has joined #openstack-neutron19:58
nati_uenomarun: do you like this change? https://review.openstack.org/#/c/82904/1/nova/virt/libvirt/vif.py19:59
nati_uenomarun: my bad give me some sec20:00
*** changbl has quit IRC20:00
*** armax has quit IRC20:00
*** armax has joined #openstack-neutron20:01
*** alagalah has quit IRC20:01
nati_uenomarun: https://review.openstack.org/#/c/82904/3/nova/virt/libvirt/vif.py20:02
nati_uenomarun: so 12L20:02
*** leseb has quit IRC20:03
openstackgerritA change was merged to openstack/neutron: Add enable_security_group to BigSwitch and OneConvergence ini files  https://review.openstack.org/8228720:03
*** shakamunyi has quit IRC20:03
openstackgerritA change was merged to openstack/neutron: ML2 Cisco Nexus MD: Remove workaround for bug 1276395  https://review.openstack.org/8283920:03
beaglesum20:03
beagleswhat20:03
*** dave_tucker is now known as dave_tucker_zzz20:03
*** baoli has quit IRC20:04
beaglesnati_ueno, isn't it the case that you what the ovs_hybrid bridges to get configured... so what you want to happen is to get get_firewall_required returning true20:04
beaglesnati_ueno, the nwfilter stuff is arp-spoofing, etc, which did not exist in previous versions... unless I am mistaken it is the hybrid bridges that need to get configured20:05
nati_uenobeagles: without nwfilter stuff change, it will be stuck20:05
nati_uenobeagles: because we don't initialize basic nw filter20:05
nati_uenobeagles: you mean L164?20:06
*** jistr has quit IRC20:06
*** shakamunyi has joined #openstack-neutron20:06
beaglesnati_ueno, mrmmmmm... okay let's consider one of your other proposals... that is reverting the removal of LibvirtHybridOVSBridgeDriver20:07
nati_uenohttps://review.openstack.org/#/c/82904/4/nova/virt/libvirt/vif.py sorry I found typo.20:08
nati_uenobeagles: yes20:08
beaglesnati_ueno, so .. it calls plug_ovs_hybrid()20:08
nati_uenobeagles: yes20:08
beaglesnati_ueno, so the generic driver will only do this if get_firewall_required returns true, right?20:08
nati_uenobeagles: yes20:09
beaglesnati_ueno, but for neutron to work, nova's firewall driver must be configured to be nova.virt.firewall.NoopFirewallDriver20:09
beaglesnati_ueno: so this returns false20:09
nati_uenobeagles: and conf.filtername should be None (see L180)20:09
beaglesnati_ueno, oh bugger...sorry missed the override below20:10
beaglesfor the firewall thing20:11
*** spandhe has quit IRC20:11
nati_uenobeagles: yes. This combination is needed20:11
*** spandhe has joined #openstack-neutron20:13
*** jprovazn has quit IRC20:15
*** dfarrell07 has quit IRC20:19
*** itzikb has joined #openstack-neutron20:21
*** yfried has joined #openstack-neutron20:23
marunnati_ueno: looking20:25
nati_uenomarun: Thanks20:25
*** banix has quit IRC20:26
*** spandhe has quit IRC20:26
*** alagalah has joined #openstack-neutron20:27
marunnati_ueno: quibble, but should the name be 'LibvirtNeutronFirewallVifDriver'?20:27
marunnati_ueno: so get_firewall_required is used elsewhere, necessitating the addition of get_nw_filter_required?20:28
nati_uenomarun: OK give me a sec. I'll change the name20:28
nati_uenomarun: yes. get_firewall_required is used20:28
nati_uenomarun: the problem is get_firewall_required used for both of nwfilter selection and vif method selection20:29
nati_uenomarun: For neturon case, it is not same20:29
marunnati_ueno: so get_firewall_required -> use hybrid plugging20:29
marunnati_ueno: get_nw_filter_required -> ??20:30
nati_uenomarun: yes20:30
marunnati_ueno: I don't know why they didn't just name it 'use_hybrid plugging' ;)20:30
nati_uenomarun: it set conf.filtername20:30
nati_uenomarun: if conf.filtername isn't none, it won't work with NoopFirewallDriver which neutron using20:30
nati_uenoso we need get_nw_filter_required to be set20:31
nati_uenoFor neutron case, it should be get_nw_filter_required=False get_firewall_required=True20:31
marunnati_ueno: the override in the new vif driver mispells the method name20:31
marunmisspells20:31
marunnati_ueno: get_filter_required -> get_nwfilter_required20:32
nati_uenomarun: ah sorry that' one is fixed in new patch set20:32
nati_uenomarun: https://review.openstack.org/#/c/82904/4/nova/virt/libvirt/vif.py20:32
marunok20:32
marunnati_ueno: so this looks fine to me.  let's get a nova core to take a look.20:33
nati_uenomarun: I'm adding UT, so could you give me few sec?20:33
marundansmith: could use your eyes for a a couple minutes. no longer, promise! https://review.openstack.org/#/c/82904/4/nova/virt/libvirt/vif.py20:33
marunnati_ueno: I'd like to make sure we're good on the approach before UT are required20:34
salv-orlandomarun, nati_ueno: so are we cool with both patches?20:34
salv-orlandomarun: ok, then20:34
marunsalv-orlando: we're reverting20:34
marunsalv-orlando: or what did you mean by 'both patches'?20:34
nati_uenomarun: no, we are selecting small patch in nova side only in Icehouse20:34
salv-orlandook. I missed a part of the conversation as I was away for dinner.20:35
nati_uenosalv-orlando: I gave up to merge original one, and I have a discussion with Russel20:35
marunsalv-orlando: too late in cycle to push nova-side change through20:35
salv-orlandoso it looks like we're going to push for a small change that selects the appropriate VIF driver if neutron is going to do sec groups?20:35
marunsalv-orlando: so we simplify - go back to old way of requiring explicit vif driver20:35
salv-orlandomarun: I see. I'm not sure this will go down well in nova, if we're moving away from the generic driver20:36
marunsalv-orlando: if by 'select' you mean 'nova has to be configured to use the appropriate driver'20:36
marunsalv-orlando: it's either this or we add a config flag that has the same effect in the generic vif driver20:36
nati_uenosalv-orlando: no we aren't moving away from generic one, we have generic one'20:36
marunsalv-orlando: the effect is the same - explicit config20:36
nati_uenosalv-orlando: please take a look https://review.openstack.org/#/c/82904/5/nova/virt/libvirt/vif.py20:36
dansmithmarun: ...and we swap this subclass in how/when?20:37
*** spandhe has joined #openstack-neutron20:37
openstackgerritHareesh Puthalath proposed a change to openstack/neutron: Include cisco plugin in migration plugins with ovs  https://review.openstack.org/8040620:37
marundansmith: i'm presuming it has to be set per compute node in nova.conf, same as the old hybrid vif driver needed to be configured20:37
marundansmith: if that's not acceptable, the alternative is adding a new config option that has the same effect on the generic driver20:37
marundansmith: i.e. if set, control whether hybrid vif plugging is used.20:38
dansmithmarun: I'm pretty sure we're not merging any new config variables at this point :)20:38
marundansmith: so is the new vif driver an option?20:38
nati_uenodansmith: we are not going add new config option. Adding new driver20:38
marunrusselb agreed in principle to the idea of explicit configuration, but we didn't get into the specifics20:38
*** otherwiseguy has joined #openstack-neutron20:39
nati_uenodansmith: could you take a look https://review.openstack.org/#/c/82904/5 ?20:39
russellbin meeting so hard to talk detail now20:39
marundansmith: you might be able to scroll back or eavesdrop20:39
marunrussellb: no worries, I'm invoking your name in vain20:39
russellbbut basically what i want is: 1) not the big thing where we're trying to read data from neutron, too late.20:39
russellband 2) as simple as possible to fix the regression20:39
russellbwhatever that is20:39
dansmithnati_ueno: yeah, I'm looking at it right now20:39
nati_uenodansmith: Thanks20:40
marunrussellb: https://review.openstack.org/#/c/82904/5/nova/virt/libvirt/vif.py20:40
nati_uenoI'm still testing it with devstack, but hopuly I can get direction now20:40
marunnati_ueno: you could probably drop the Libvirt prefix off the name of the subclass since in config the fully qualified path has to be specified20:41
maruni.e. nova.virt.libvirt.vif.NeutronFirewallVifDriver20:41
nati_uenomarun: sure! I'll do it right now20:41
beaglesum... this is still something that needs tob e configured though right?20:41
beaglesie in nova.conf20:41
salv-orlandoBut if nova sets as firewall driver the NoOp driver, isthe hybrid driver used and sec groups correctly work with neutron?20:41
salv-orlandoor is there something else?20:41
marunbeagles: it used to, back when the hybrid vif driver still existed20:42
marunoops, salv-orlando ^20:42
dansmithoh, I see vif driver is pluggable right now,20:42
dansmithbut I don't know why20:42
marunbeagles: is it still possible to specify vif driver?20:42
salv-orlandomy understanding of the logic is that if nova specifies the Noopdriver20:42
beaglesoic .. we are adding a value not a variable20:43
marunsalv-orlando: easy enough to check20:43
salv-orlandothen the generic vif driver does hybrid plugging20:43
beaglesmarun %20:43
marunsalv-orlando: if that was the case, why are security groups borked?20:43
beaglesmarun sorry that was supposed to be ^20:43
salv-orlandomarun: that's what I've done again now, but I'm usually bad in that case20:43
salv-orlandoso, I remember from what I discussed in yfried that a devstack patch restored the default value of firewall_driver to iptables20:43
salv-orlandoregardless of whether neutron was in place or not.20:44
marunhmmm20:44
salv-orlandoBut this looks to easy to be true20:44
nati_uenosalv-orlando: The issue is L180. Neutron don't want to config.filtername20:44
dansmithmarun: nati_ueno can we not choose to do the right thing if is_neutron() is true?20:44
salv-orlandomeaning that if it's there everthing is broken?20:44
nati_uenosalv-orlando: if we set require_firewall=True, current code set  config.filtername20:44
yfriedsalv-orlando: ?20:44
nati_uenodansmith: It will break VMWare plugin20:44
salv-orlandoyfried: the thing about security groups not enforced in the gate20:44
nati_uenoyfried: We are lack of negative test20:45
dansmithnati_ueno: how?20:45
nati_uenodansmith: so VMWare plugin don't need iptables20:45
marunyfried: was there a devstack-only fix for that or are your test additions still awaiting merge?20:45
dansmithnati_ueno: use more words20:45
nati_uenodansmith: and they need to use NoopDriver20:45
marundansmith: it needs to be configurable depending on the selected plugin20:45
marundansmith: not all plugins want hybrid plugging20:46
yfriedsalv-orlando: nati_ueno: I have a patch ready for this. https://review.openstack.org/#/c/62702/20:46
nati_uenodansmith: ok, so vmware isn't using iptables for realizing security group functionalists. They are using OVS for that. They don't wan't to use Nova side firewall too.20:46
dansmithI don't even know what hybrid plugging means20:46
yfriedmarun: this should verify secgroup enforcemnt20:46
marundansmith: hybrid plugging is when there is a linux bridge between vif and ovs so that iptables filtering can be done (e.g. for security groups)20:46
yfriedmarun: nati_ueno: salv-orlando: ^ is that what you were looking for?20:46
nati_uenodansmith: hybrid plugging is needed to use iptables + OVS. Basically, OVS didn't support iptables. so for that case, we are using linuxbridge and OVS combination. And  This is called Hybridplugging20:47
salv-orlandoyfried: yes.20:47
marunyfried: we were debating whether there was a devstack workaround to enable security groups, but I'm assuming a real fix is needed before we can merge your patch20:47
nati_uenoyfried: nice!20:47
nati_uenomarun: +120:47
dansmithso, I'm not sure I can reasonably grok all of this in time to make a good decision, personally20:47
*** ramishra has quit IRC20:47
dansmithrussellb: ^20:47
yfriedmarun: "devstack workaround to enable security groups"?20:47
yfriedmarun: shouldn't they be on by default?20:48
*** ramishra has joined #openstack-neutron20:48
marundansmith: It's pretty simple actually, but it's a hectic time.20:48
russellbshould we jump on the phone to talk through it?20:48
russellbmaybe tomorrow better for me though20:48
dansmithyes, today is not good for me20:48
marunrussellb: +120:48
russellbk, let's sync tomorrow then20:48
marunrussellb: ok.20:49
marunnati_ueno: you're up for that?20:49
russellbmaybe proposed workaround will be settled by then20:49
*** markwash has joined #openstack-neutron20:49
nati_uenoyeah, I can join20:49
marunnati_ueno: I think you can probably add UT and test with devstack prior.  I think the proposed solution is about as simple as we're going to get.20:49
nati_uenomarun: Sure20:49
marunrussellb, dansmith: I think the only alternative is adding a config variable that has the same effect as a new vif driver, but I understand we're too late for that.20:50
marunwe can discuss tomorrow20:50
salv-orlandodansmith, russellb: if the proposed vif driver workaround is fine for you, I'm fine either (obviously) I raised the concern just because I recall the direction is to use Hybrid Driver for everything20:50
salv-orlandosorry Generic20:50
dansmithright, I'm not even sure why we have this plug point20:51
marundansmith: fortuitous luck?  :)20:51
*** changbl has joined #openstack-neutron20:51
dansmithmarun: no, definitely not that.20:51
russellbdansmith: pretty sure it should be set on fire20:51
dansmithyes20:52
nati_uenosalv-orlando: dansmith: I agree. But we need some workaround on this20:52
russellband all automatic based on talking to neutron20:52
russellbi think that was the point of the generic driver right?20:52
*** ramishra has quit IRC20:52
marunagreed that is the way forward20:52
russellbto move away from having to configure this crap20:52
nati_uenorussellb: right20:52
dansmithyes20:52
marunbut in the absence of support for dynamic config, we need security groups to work.20:52
russellband there's something nova doesn't know from neutron right now?20:52
salv-orlandonati_ueno: I have said that if the nova team takes https://review.openstack.org/#/c/82904 as an acceptable workaround I am fine20:53
russellbwhat is it we're enabling or not on the nova side20:53
nati_uenosalv-orlando: gotcha20:53
nati_uenorussellb: security group with neturon + ovs20:53
salv-orlandorussellb: nati-ueno has patch 21946 where he has a few new binding attributes that would let neutron tell nova how security should be configured on a port...20:54
russellbOK20:54
russellbso, what drivers from neutron need this20:54
marunrussellb: it's simply too late to get it ready to merge for icehouse20:54
russellbjust OVS?20:54
salv-orlandoI was more of the opinion that neutron should just tell straight nova how to plug a port, without too many attributes20:54
marunrussellb: a whole bunch of plugins use the same path20:54
nati_uenorussellb: yes just OVS20:54
marunrussellb: it's not just one20:54
salv-orlandoand assume that if neutron is there, neutron does security groups.20:54
marunrussellb: ah, sorry.  yes.  just the ovs vif driver.20:54
russellbwhat's broken, just OVS?20:54
russellbok.20:54
russellbdoes nova know if ovs is used on the neutron side?20:54
russellbif so, can nova just "do the right thing" ?20:55
russellbinstead of having to configure junk?20:55
marunno20:55
russellbeven if it's special casing OVS20:55
russellbah, boo.20:55
salv-orlandorussellb: do you know the trick the ovs agent does for making sec groups work on ovs? the "shim bridge20:55
russellbno20:55
marunthat's why we need to pass vif details with the port to configure dynamically20:55
marun(or failing that, statically config)20:56
salv-orlandobasically when using the ovs agent (either ovs or ml2 plugin), neutron actually needs a linux bridge to attach iptables rules, otheriwse they're not enforced20:56
nati_uenorussellb: so ML2+OVSDriver is using iptables + OVS. VMWare plugin is using OVS only20:56
salv-orlandoas ovs does not send packets to netfilter for processing when they come in/out of their interface20:56
marunlong term solution is to filter in ovs directly...20:57
marunbut until then we're stuck with a hybrid solution20:57
salv-orlandoto address that a tap from a VM is actually plugged into a LB instance, and that LB instance then has another port on OVS20:57
salv-orlandorussellb: I hope you're not puking after hearing this ;)20:57
russellbno, in IRC meeting at the same time, so behind20:57
kevinbentonsalv-orlando: isn't this the same limitation that nova security groups have been dealing with as well?20:59
salv-orlandooh I think you're in the TC meeting now. I'll be around later if you have time20:59
kevinbentonrussellb: i.e. why would russelb be puking? :-)20:59
salv-orlandokevinbenton: I've not been following nova network development. I recall it always used bridges21:00
russellbi'm mostly puking that this has been broken so long and we're hearing about it 2 days before cutting a RC21:00
*** manishg has quit IRC21:00
*** spandhe has quit IRC21:01
salv-orlandorussellb: this is not one of the bugs I've kept closely on my radar. to me it was always a regression introduced by a devstack patch; but only recently I'm hearing it's a deeper problem.21:01
*** singhs_ has joined #openstack-neutron21:02
kevinbentonsalv-orlando: is the LB strategy the same as this one? https://github.com/openstack/nova/blob/stable/havana/nova/virt/libvirt/vif.py#L41021:02
dansmiththat makes me less willing to take a ninja patch, personally :/21:02
*** singhs has quit IRC21:02
kevinbentonsalv-orlando: veth with ovs21:02
*** singhs_ is now known as singhs21:02
*** spandhe has joined #openstack-neutron21:03
*** manishg has joined #openstack-neutron21:04
*** banix has joined #openstack-neutron21:04
marundansmith: ninja patch?21:05
dansmithyeah21:05
marundansmith: What qualifies as a ninja patch?21:05
dansmithmarun: fast, last minute, minimal consideration, under-duress21:06
marundansmith: some of those are true21:06
marundansmith: but the solution is basically to use the old proven way of configuring nova to use hybrid plugging21:06
marundansmith: it's a regression from moving towards entirely dynamic configuration21:07
marundansmith: but it isn't doing anything new - this approach as pretty much proven (if cumbersome)21:07
dansmithweren't we going to table this until tomorrow when we can all concentrate on the proposal?>21:07
marundansmith: fair enough :)21:07
salv-orlandoyeah let's get back at this tomorrow. It's also late my time, and tomorrow we'll have also markmcclain around21:07
*** leseb has joined #openstack-neutron21:08
*** shakayumi has joined #openstack-neutron21:08
*** mlavalle has quit IRC21:09
*** shakayumi has quit IRC21:09
nati_uenoso which time we will have the meeting?21:09
*** shakamunyi has quit IRC21:11
*** sridhar has quit IRC21:12
marunnati_ueno: I think the timing was indeterminate21:13
nati_uenomarun: indeterminate ?21:14
*** tvardeman has quit IRC21:15
salv-orlandoyeah, like in the heisenberg principle ;)21:17
*** dave_tucker_zzz is now known as dave_tucker21:19
nati_uenorussellb: salv-orlando: marun: dansmith: kevinbenton: about UTC 17:00?21:20
kevinbentonnati_ueno: i'm just an innocent bystander :-)21:20
nati_uenokevinbenton: sure :)21:20
dansmiththat should be okay for me21:21
kevinbentonnati_ueno: which channel is this meeting in?21:21
nati_uenokevinbenton: #openstack-neturon21:22
nati_uenokevinbenton: I'll post conf call url on here21:22
kevinbentonnati_ueno: ok21:22
nati_uenokevinbenton: Thanks21:22
salv-orlandonati_ueno: this might sound silly but I have to take the cat to the vet21:23
salv-orlandogo ahed without me!21:23
nati_uenosalv-orlando: sure! Take care your cat :)21:24
*** carlp has quit IRC21:28
marunnati_ueno: wfm21:34
*** banix has quit IRC21:35
*** Jabadia has quit IRC21:35
nati_uenomarun: ?21:36
marun17:00utc - works for me21:36
nati_uenomarun: sure21:36
*** BuSerD has quit IRC21:36
*** Apsu has quit IRC21:37
*** dave_tucker is now known as dave_tucker_zzz21:39
*** carlp has joined #openstack-neutron21:41
*** humbolt has quit IRC21:42
*** alexpilotti has joined #openstack-neutron21:44
*** Diopter has joined #openstack-neutron21:45
*** russellb has quit IRC21:47
*** metral has quit IRC21:47
*** Diopter has quit IRC21:47
*** zigo has quit IRC21:47
*** wendar has quit IRC21:47
*** russellb has joined #openstack-neutron21:48
*** Apsu has joined #openstack-neutron21:48
*** mwagner_lap has quit IRC21:49
*** metral has joined #openstack-neutron21:49
*** wendar has joined #openstack-neutron21:49
*** zigo has joined #openstack-neutron21:49
*** catohornet__ has joined #openstack-neutron21:50
*** BuSerD has joined #openstack-neutron21:50
*** Gil_McGrath has quit IRC21:50
*** dave_tucker_zzz is now known as dave_tucker21:54
*** claudiub has quit IRC21:58
*** spandhe has quit IRC21:58
*** dave_tucker is now known as dave_tucker_zzz22:00
*** djoreilly has quit IRC22:01
*** leseb has quit IRC22:02
*** spandhe has joined #openstack-neutron22:02
*** networkstatic is now known as networkstatic_zZ22:04
*** armax has quit IRC22:05
openstackgerritKyle Mestery proposed a change to openstack/neutron: Correct OVS VXLAN version check  https://review.openstack.org/8293122:10
*** catohornet___ has joined #openstack-neutron22:11
*** markwash_ has joined #openstack-neutron22:12
*** markwash has quit IRC22:14
*** markwash_ is now known as markwash22:14
*** catohornet__ has quit IRC22:15
*** devlaps1 has quit IRC22:17
*** changbl has quit IRC22:17
*** dave_tucker_zzz is now known as dave_tucker22:17
*** devlaps has joined #openstack-neutron22:17
*** dims_ has quit IRC22:18
*** catohornet____ has joined #openstack-neutron22:19
*** catohornet____ is now known as catohornet__22:19
*** catohornet___ has quit IRC22:21
*** itzikb has quit IRC22:23
*** jobewan has quit IRC22:23
*** catohornet__ has quit IRC22:32
*** dims_ has joined #openstack-neutron22:34
*** banix has joined #openstack-neutron22:54
*** WackoRobie has joined #openstack-neutron22:57
openstackgerritKyle Mestery proposed a change to openstack/neutron: Correct OVS VXLAN version check  https://review.openstack.org/8293122:58
*** _1_overlayer has joined #openstack-neutron23:01
*** mwagner_lap has joined #openstack-neutron23:02
openstackgerritA change was merged to openstack/neutron: Replace a usage of the deprecated root_helper option  https://review.openstack.org/8274623:02
*** _1_overlayer has quit IRC23:04
*** blogan has quit IRC23:10
*** markmcclain has joined #openstack-neutron23:10
*** overlayer has joined #openstack-neutron23:10
*** markmcclain1 has joined #openstack-neutron23:11
*** overlayer has quit IRC23:12
*** otherwiseguy has quit IRC23:13
*** _cjones_ has quit IRC23:14
*** _cjones_ has joined #openstack-neutron23:14
*** markmcclain has quit IRC23:15
*** thedodd has quit IRC23:17
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Cancelling thread start while unit tests running  https://review.openstack.org/8132323:18
*** thuc_ has quit IRC23:18
*** thuc has joined #openstack-neutron23:18
*** thuc has quit IRC23:23
*** krtaylor has quit IRC23:23
*** jgrimm has quit IRC23:25
*** networkstatic_zZ is now known as networkstatic23:25
*** gdubreui has quit IRC23:27
*** overlayer has joined #openstack-neutron23:28
*** julim has quit IRC23:30
*** markmcclain1 has quit IRC23:30
*** overlayer has quit IRC23:31
*** overlayer has joined #openstack-neutron23:31
*** banix has quit IRC23:33
*** spandhe has quit IRC23:33
*** overlayer has quit IRC23:34
*** dave_tucker is now known as dave_tucker_zzz23:36
*** spandhe has joined #openstack-neutron23:39
openstackgerritRobert Kukura proposed a change to openstack/neutron: ML2: Bind ports outside transactions  https://review.openstack.org/8294523:40
*** zzelle has quit IRC23:44
*** baoli has joined #openstack-neutron23:46
*** pcm___ has quit IRC23:47
*** devlaps1 has joined #openstack-neutron23:50
*** devlaps has quit IRC23:53
*** mwagner_ has joined #openstack-neutron23:54
*** carlp has quit IRC23:55
openstackgerritDaniel Gollub proposed a change to openstack/neutron: Validate local_ip when ovs-agent starts  https://review.openstack.org/7710023:56
*** carl_baldwin has quit IRC23:57
alexpilottirkukura: hi23:58
rkukuraalexpilotti: hi23:59
alexpilottirkukura: I have a question on a backporting procedure23:59

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