Friday, 2016-02-26

*** thorst_afk has quit IRC00:01
*** chlong_ has quit IRC00:03
*** jckasper has quit IRC00:04
*** mickeys has quit IRC00:04
*** Aish has quit IRC00:05
*** Aish has joined #openstack-neutron00:06
*** ivar-lazzaro has quit IRC00:06
*** ivar-lazzaro has joined #openstack-neutron00:07
*** abhiraut has quit IRC00:09
*** manuel112 has quit IRC00:09
*** krtaylor has joined #openstack-neutron00:12
*** abhiraut has joined #openstack-neutron00:14
openstackgerritKevin Benton proposed openstack/neutron: Make agent interface plugging utilize network MTU  https://review.openstack.org/28379000:14
*** yamamoto_ has joined #openstack-neutron00:18
*** banix has quit IRC00:20
*** Sukhdev has joined #openstack-neutron00:20
openstackgerritRitesh Anand proposed openstack/neutron: Avoids logging error on OVS agent start.  https://review.openstack.org/28149800:23
*** yamamoto_ has quit IRC00:23
openstackgerritRitesh Anand proposed openstack/neutron: Added test cases for DVR L3 schedulers.  https://review.openstack.org/18815700:24
*** sdague has quit IRC00:26
*** daneyon has quit IRC00:28
*** SumitNaiksatam has joined #openstack-neutron00:29
*** Sukhdev has quit IRC00:29
*** sridhar_ram has joined #openstack-neutron00:30
*** eil397 has joined #openstack-neutron00:32
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: ADD API tests for network ip availability  https://review.openstack.org/28335700:33
*** sridhar_ram has quit IRC00:33
*** mickeys has joined #openstack-neutron00:34
*** sridhar_ram has joined #openstack-neutron00:35
openstackgerritReedip proposed openstack/python-neutronclient: Change try..except to assertRaises in UT  https://review.openstack.org/28218400:36
*** mfuruta has joined #openstack-neutron00:40
openstackgerritDavid Bingham proposed openstack/neutron: Add API extension for reporting IP availability usage statistics  https://review.openstack.org/21295500:41
*** salv-orlando has joined #openstack-neutron00:45
openstackgerritZhaoBo proposed openstack/neutron: Add timestamp for neutron core resources  https://review.openstack.org/21358600:45
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: ADD API tests for network ip availability  https://review.openstack.org/28335700:52
*** SumitNaiksatam has quit IRC00:54
*** gongysh has joined #openstack-neutron00:54
*** eil397 has quit IRC00:57
*** RichardRaseley has quit IRC00:57
*** madhu_ak has quit IRC00:58
openstackgerritDavid Bingham proposed openstack/neutron: Add API extension for reporting IP availability usage statistics  https://review.openstack.org/21295500:58
*** vilobhmm11 has quit IRC00:59
*** thorst_afk has joined #openstack-neutron00:59
*** madhu_ak has joined #openstack-neutron00:59
*** Aish has left #openstack-neutron01:00
*** john-davidge has quit IRC01:01
*** ivar-lazzaro has quit IRC01:01
*** rotbeard has joined #openstack-neutron01:01
*** ijw has quit IRC01:01
*** ajmiller has quit IRC01:01
*** ijw has joined #openstack-neutron01:02
*** manuel112 has joined #openstack-neutron01:03
*** hoangcx has joined #openstack-neutron01:04
*** minwang2 has quit IRC01:04
*** thorst_afk has quit IRC01:05
*** thorst_afk has joined #openstack-neutron01:05
openstackgerritSongming Yan proposed openstack/neutron: Adds trunk api of server.  https://review.openstack.org/28172301:05
*** thorst_afk has quit IRC01:06
*** salv-orlando has quit IRC01:07
*** thorst_afk has joined #openstack-neutron01:07
*** vilobhmm11 has joined #openstack-neutron01:10
*** thorst_afk has quit IRC01:12
*** ivar-lazzaro has joined #openstack-neutron01:14
*** gangil has quit IRC01:16
*** EinstCrazy has joined #openstack-neutron01:16
*** ivar-lazzaro has quit IRC01:16
*** ivar-lazzaro has joined #openstack-neutron01:17
*** gangil has joined #openstack-neutron01:17
*** gangil has quit IRC01:17
*** gangil has joined #openstack-neutron01:17
*** john-davidge has joined #openstack-neutron01:20
*** yamamoto_ has joined #openstack-neutron01:20
*** stanzgy has joined #openstack-neutron01:20
*** gangil has quit IRC01:22
*** shivrao has quit IRC01:22
*** tfukushima has joined #openstack-neutron01:25
*** shashank_hegde has quit IRC01:25
*** yamamoto_ has quit IRC01:26
*** baohua has joined #openstack-neutron01:26
*** daneyon has joined #openstack-neutron01:28
*** tfukushima has quit IRC01:28
*** daneyon_ has joined #openstack-neutron01:30
*** skamithi has joined #openstack-neutron01:31
*** daneyon has quit IRC01:33
*** manuel112 has quit IRC01:34
*** madhu_ak has quit IRC01:34
*** mickeys has quit IRC01:37
*** shivrao has joined #openstack-neutron01:37
*** abhiraut has quit IRC01:37
*** tfukushima has joined #openstack-neutron01:38
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: ADD API tests for network ip availability  https://review.openstack.org/28335701:38
*** tfukushima has quit IRC01:40
*** EinstCrazy has quit IRC01:40
openstackgerritOpenStack Proposal Bot proposed openstack/neutron: Updated from global requirements  https://review.openstack.org/28399101:41
*** EinstCrazy has joined #openstack-neutron01:42
*** ijw has quit IRC01:43
*** ijw has joined #openstack-neutron01:46
kevinbentonZZelle: still there?01:46
*** shivrao has quit IRC01:46
*** ijw has quit IRC01:48
*** ijw has joined #openstack-neutron01:48
*** vilobhmm11 has left #openstack-neutron01:48
*** dims has quit IRC01:49
*** chlong_ has joined #openstack-neutron01:49
openstackgerritOpenStack Proposal Bot proposed openstack/neutron: Updated from global requirements  https://review.openstack.org/28399101:49
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-fwaas: Updated from global requirements  https://review.openstack.org/28504101:50
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-lib: Updated from global requirements  https://review.openstack.org/28275301:50
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-vpnaas: Updated from global requirements  https://review.openstack.org/28504301:50
openstackgerritLujin Luo proposed openstack/neutron: This patch avoids duplicate port records in routerport table  https://review.openstack.org/28504801:51
*** s3wong has quit IRC01:53
*** tfukushima has joined #openstack-neutron01:55
*** thorst_afk has joined #openstack-neutron01:57
*** hoangcx has quit IRC02:01
*** liuyulong has joined #openstack-neutron02:02
liuyulongHi there02:03
openstackgerritLIU Yulong proposed openstack/neutron: Clean up l3 agent side HA router stuffs  https://review.openstack.org/26567202:04
*** yamamoto has joined #openstack-neutron02:04
openstackgerritLIU Yulong proposed openstack/neutron: ML2: catch router HA ports update DB error after race conditions  https://review.openstack.org/26567602:05
*** manjeets has left #openstack-neutron02:05
openstackgerritLIU Yulong proposed openstack/neutron: Ensure HA router can be synced after HA router race conditions  https://review.openstack.org/26568002:07
*** banix has joined #openstack-neutron02:07
*** banix has quit IRC02:09
*** hichihara has joined #openstack-neutron02:09
openstackgerritLIU Yulong proposed openstack/neutron: Catch exceptions during the delete of tenant last HA router  https://review.openstack.org/26568202:10
*** gvrangan_ has joined #openstack-neutron02:11
*** ZZelle_ has quit IRC02:14
*** tiswanso has joined #openstack-neutron02:15
*** yamamoto has quit IRC02:15
*** tiswanso has quit IRC02:16
*** tiswanso has joined #openstack-neutron02:17
*** emagana has quit IRC02:24
*** annp has joined #openstack-neutron02:26
*** emagana has joined #openstack-neutron02:27
*** manuel112 has joined #openstack-neutron02:27
*** emagana has quit IRC02:31
openstackgerritLIU Yulong proposed openstack/neutron: Catch DB error after HA router race conditions  https://review.openstack.org/26568502:34
*** jckasper has joined #openstack-neutron02:35
*** vhosakot has joined #openstack-neutron02:35
*** baoli has joined #openstack-neutron02:36
*** DevonBoatwright has joined #openstack-neutron02:37
*** DevonBoatwright has quit IRC02:37
*** fzdarsky|afk has quit IRC02:37
*** yamahata has quit IRC02:39
*** iyamahat_ has quit IRC02:39
*** gvrangan_ has quit IRC02:40
*** gvrangan has quit IRC02:40
*** emagana has joined #openstack-neutron02:44
*** s3wong has joined #openstack-neutron02:45
openstackgerritBrandon Logan proposed openstack/neutron: Pecan routing for agent schedulers  https://review.openstack.org/26798502:45
*** tbachman has quit IRC02:46
*** fzdarsky has joined #openstack-neutron02:46
*** tbachman has joined #openstack-neutron02:47
*** rkukura has quit IRC02:47
*** shashank_hegde has joined #openstack-neutron02:47
*** fawadkhaliq has joined #openstack-neutron02:48
*** emagana has quit IRC02:49
*** wolverin_ has quit IRC02:49
openstackgerritKevin Benton proposed openstack/neutron: Deprecate segment_mtu and add global_physnet_mtu  https://review.openstack.org/28481402:53
*** minwang2 has joined #openstack-neutron02:55
*** hanchao has joined #openstack-neutron02:59
*** manuel112 has quit IRC03:00
*** yamamoto has joined #openstack-neutron03:01
*** thorst_afk has quit IRC03:09
*** s3wong has quit IRC03:09
*** thorst_afk has joined #openstack-neutron03:09
*** dims has joined #openstack-neutron03:10
*** intr1nsic has quit IRC03:10
*** tfukushima has quit IRC03:11
*** tfukushima has joined #openstack-neutron03:11
*** neelashah has joined #openstack-neutron03:12
*** singhj has joined #openstack-neutron03:14
*** tfukushima has quit IRC03:15
*** ianw has quit IRC03:16
*** singhj has quit IRC03:16
*** ivar-laz_ has joined #openstack-neutron03:17
*** intr1nsic has joined #openstack-neutron03:17
*** thorst_afk has quit IRC03:18
*** shwetaap has joined #openstack-neutron03:19
*** ianw has joined #openstack-neutron03:19
*** shwetaap1 has joined #openstack-neutron03:20
*** ajmiller has joined #openstack-neutron03:20
*** ivar-lazzaro has quit IRC03:20
*** ivar-laz_ has quit IRC03:21
*** tbachman has quit IRC03:22
*** shwetaap has quit IRC03:23
openstackgerritLi Ma proposed openstack/python-neutronclient: Add popular IP protocols for security group  https://review.openstack.org/28262103:23
*** ijw has quit IRC03:24
*** boris-42 has quit IRC03:24
*** links has joined #openstack-neutron03:26
*** tfukushima has joined #openstack-neutron03:29
*** baohua has quit IRC03:30
*** baohua has joined #openstack-neutron03:31
*** emagana has joined #openstack-neutron03:32
*** fawadkhaliq has quit IRC03:32
*** ajmiller has quit IRC03:34
*** ajmiller has joined #openstack-neutron03:34
*** ijw has joined #openstack-neutron03:35
openstackgerritKevin Benton proposed openstack/neutron: Make L3 HA interface creation concurrency safe  https://review.openstack.org/28287603:37
openstackgerritKevin Benton proposed openstack/neutron: Get rid of unnecessary _ha_routers_present check  https://review.openstack.org/28509303:37
*** emagana has quit IRC03:37
*** Kennan has quit IRC03:39
*** Kennan has joined #openstack-neutron03:39
*** ijw has quit IRC03:40
*** amotoki has joined #openstack-neutron03:41
*** cappetta has quit IRC03:41
*** rickyrem has quit IRC03:43
*** fedexo has joined #openstack-neutron03:45
*** kriskend has joined #openstack-neutron03:48
*** hanchao has quit IRC03:50
*** markvoelker has quit IRC03:51
*** manuel112 has joined #openstack-neutron03:52
*** ajmiller_ has joined #openstack-neutron03:54
*** daneyon_ has quit IRC03:54
*** hoangcx has joined #openstack-neutron03:55
*** azbiswas has joined #openstack-neutron03:55
*** wolverineav has joined #openstack-neutron03:57
*** ajmiller has quit IRC03:57
*** Marga_ has quit IRC03:57
*** Marga_ has joined #openstack-neutron03:58
*** Marga_ has quit IRC04:03
*** amotoki has quit IRC04:05
*** sridhar_ram has quit IRC04:05
*** vhosakot has quit IRC04:06
*** baoli has quit IRC04:07
Sam-I-Ammoo.04:07
*** tbachman has joined #openstack-neutron04:09
*** baoli has joined #openstack-neutron04:09
*** armax has joined #openstack-neutron04:11
*** azbiswas has quit IRC04:12
*** kriskend has quit IRC04:12
*** thorst_afk has joined #openstack-neutron04:15
*** jckasper has quit IRC04:16
*** jckasper has joined #openstack-neutron04:17
russellbquack04:18
*** jckasper has quit IRC04:18
*** baoli has quit IRC04:18
*** jckasper has joined #openstack-neutron04:19
*** Marga_ has joined #openstack-neutron04:19
Sam-I-Amrussellb: whats up?04:19
*** baoli has joined #openstack-neutron04:20
russellbfalling asleep trying to hack ovn code04:20
*** amotoki has joined #openstack-neutron04:20
*** Marga_ has quit IRC04:21
Sam-I-Amsounds dazzling04:21
Sam-I-Ami'm falling asleep writing docs04:21
*** Marga_ has joined #openstack-neutron04:21
*** thorst_afk has quit IRC04:23
*** gongysh has quit IRC04:23
Sam-I-Amthe soothing sounds of config file updates04:24
*** manuel112 has quit IRC04:24
russellb:)04:26
Sam-I-Amso apparently nova uses 2 dbs now04:27
*** amotoki has quit IRC04:30
*** amotoki has joined #openstack-neutron04:35
*** fedexo has quit IRC04:35
*** skamithi has left #openstack-neutron04:38
*** wolverineav has quit IRC04:39
*** shashank_hegde has quit IRC04:40
*** tfukushima has quit IRC04:43
*** tiswanso has quit IRC04:48
*** markvoelker has joined #openstack-neutron04:51
*** akshai has joined #openstack-neutron04:52
*** mfuruta has quit IRC04:52
*** jckasper has quit IRC04:53
*** markvoelker has quit IRC04:56
*** fawadkhaliq has joined #openstack-neutron04:58
*** amotoki has quit IRC05:00
*** hdaniel has joined #openstack-neutron05:01
*** wolverineav has joined #openstack-neutron05:03
*** jamespage has quit IRC05:05
*** amotoki has joined #openstack-neutron05:07
*** jamespage has joined #openstack-neutron05:07
*** wolverineav has quit IRC05:07
*** ajmiller_ has quit IRC05:10
*** singhj has joined #openstack-neutron05:11
*** singhj has quit IRC05:13
*** gongysh has joined #openstack-neutron05:16
*** manuel112 has joined #openstack-neutron05:16
*** baoli has quit IRC05:17
*** tfukushima has joined #openstack-neutron05:18
*** wolverineav has joined #openstack-neutron05:18
*** numans has joined #openstack-neutron05:19
*** thorst_afk has joined #openstack-neutron05:20
Sam-I-Amtime to locate my bed05:22
openstackgerritMerged openstack/neutron-lib: Updated from global requirements  https://review.openstack.org/28275305:25
*** tbachman has quit IRC05:26
*** thorst_afk has quit IRC05:27
*** anilvenkata has joined #openstack-neutron05:28
*** oomichi_ has joined #openstack-neutron05:30
*** anilvenkata has quit IRC05:32
*** tbachman has joined #openstack-neutron05:34
*** mubirru has joined #openstack-neutron05:35
*** emagana has joined #openstack-neutron05:35
*** hdaniel has quit IRC05:36
*** ajo_ has joined #openstack-neutron05:38
*** neelashah has quit IRC05:38
*** emagana has quit IRC05:40
*** ajo_ has quit IRC05:41
*** ajo_ has joined #openstack-neutron05:42
*** tbachman has quit IRC05:45
*** tbachman has joined #openstack-neutron05:46
*** vthapar has joined #openstack-neutron05:46
*** reedip is now known as outofmemory05:46
*** vhosakot has joined #openstack-neutron05:46
*** tbachman has quit IRC05:47
*** anilvenkata has joined #openstack-neutron05:47
*** manuel112 has quit IRC05:48
*** dileepr has quit IRC05:49
liuyulongHi guys, I've been dealing with the HA router race condition between concurrent creation and deletion for a quite while. And All the patchs are ready for review. The main LP bug to trace this is here: https://launchpad.net/bugs/1523780 All the review patchs are already reference bug#1523780 as related.05:49
openstackLaunchpad bug 1523780 in neutron "Race between HA router create and HA router delete" [Medium,In progress] - Assigned to LIU Yulong (dragon889)05:49
openstackgerritLIU Yulong proposed openstack/neutron: Catch PorNotFound after HA router race condition  https://review.openstack.org/26568505:50
*** vthapar has quit IRC05:54
*** vthapar has joined #openstack-neutron05:59
*** Marga_ has quit IRC06:00
openstackgerritMerged openstack/neutron-fwaas: FWaaS quota registration  https://review.openstack.org/28424906:04
*** hanchao has joined #openstack-neutron06:05
*** Marga_ has joined #openstack-neutron06:17
*** javeriak has joined #openstack-neutron06:17
*** javeriak has quit IRC06:18
*** john-davidge has quit IRC06:18
*** javeriak has joined #openstack-neutron06:18
*** ajo_ has quit IRC06:18
*** ajo_ has joined #openstack-neutron06:19
*** vhosakot has quit IRC06:19
*** javeriak_ has joined #openstack-neutron06:21
*** baoli has joined #openstack-neutron06:22
*** annp has quit IRC06:22
*** lajos-katona has joined #openstack-neutron06:22
*** ajo_ has quit IRC06:22
*** ajo_ has joined #openstack-neutron06:23
*** javeriak has quit IRC06:23
*** ajo_ has quit IRC06:25
*** thorst_afk has joined #openstack-neutron06:25
*** baoli has quit IRC06:26
*** links has quit IRC06:26
openstackgerrityalei wang proposed openstack/neutron: Change the exception type from ValueError to IpamValueInvalid  https://review.openstack.org/26408606:30
*** armax has quit IRC06:31
*** thorst_afk has quit IRC06:32
*** gvrangan has joined #openstack-neutron06:33
*** gvrangan_ has joined #openstack-neutron06:33
*** dims has quit IRC06:37
*** baoli has joined #openstack-neutron06:37
*** gvrangan_ has quit IRC06:37
*** gvrangan has quit IRC06:38
kevinbentonrussellb: will you be at the mid-cycle at all tomorrow?06:38
*** manuel112 has joined #openstack-neutron06:41
*** baoli has quit IRC06:42
*** numans has quit IRC06:43
*** gampel has joined #openstack-neutron06:48
*** josecastroleon has joined #openstack-neutron06:48
*** wolverineav has quit IRC06:52
*** markvoelker has joined #openstack-neutron06:53
*** jckasper has joined #openstack-neutron06:54
*** sudipto has joined #openstack-neutron06:56
*** markvoelker has quit IRC06:57
*** wolverineav has joined #openstack-neutron06:58
*** numans has joined #openstack-neutron06:58
*** shwetaap1 has quit IRC06:58
*** jckasper has quit IRC06:59
*** djan_ has joined #openstack-neutron07:00
*** slaweq has joined #openstack-neutron07:01
*** djan has quit IRC07:01
openstackgerritLi Ma proposed openstack/python-neutronclient: Add popular IP protocols for security group  https://review.openstack.org/28262107:04
*** rcernin has joined #openstack-neutron07:05
*** korzen has joined #openstack-neutron07:07
*** gongysh has quit IRC07:08
*** eddima has joined #openstack-neutron07:10
*** scheuran has joined #openstack-neutron07:12
*** apuimedo has joined #openstack-neutron07:13
*** manuel112 has quit IRC07:14
openstackgerritHirofumi Ichihara proposed openstack/python-neutronclient: Add wrapper classes for return-request-id-to-caller  https://review.openstack.org/27011807:17
*** manuel112 has joined #openstack-neutron07:18
*** claudiub has joined #openstack-neutron07:22
*** chlong_ has quit IRC07:26
*** hynekm has joined #openstack-neutron07:27
*** anshul has joined #openstack-neutron07:27
*** javeriak_ has quit IRC07:27
*** neeti has joined #openstack-neutron07:28
*** apuimedo has quit IRC07:28
openstackgerritKevin Benton proposed openstack/neutron: Use network RBAC feature for external access  https://review.openstack.org/28229507:29
*** salv-orlando has joined #openstack-neutron07:29
*** mfuruta has joined #openstack-neutron07:29
*** thorst_afk has joined #openstack-neutron07:30
openstackgerritSongming Yan proposed openstack/python-neutronclient: Adds trunk api for neutronclient.  https://review.openstack.org/28340707:32
*** mfuruta has quit IRC07:33
*** thorst_afk has quit IRC07:39
*** ihrachys has joined #openstack-neutron07:39
*** rotbeard has left #openstack-neutron07:42
*** minwang2 has quit IRC07:43
*** mfuruta has joined #openstack-neutron07:44
*** ildikov has joined #openstack-neutron07:46
*** ranjithd1 has quit IRC08:01
openstackgerritLIU Yulong proposed openstack/neutron: Catch PortNotFound after HA router race condition  https://review.openstack.org/26568508:02
*** ranjithd has joined #openstack-neutron08:02
*** emagana has joined #openstack-neutron08:02
*** gvrangan has joined #openstack-neutron08:03
*** gvrangan_ has joined #openstack-neutron08:03
*** tmorin has joined #openstack-neutron08:04
*** josecastroleon has quit IRC08:05
*** emagana has quit IRC08:06
*** josecastroleon has joined #openstack-neutron08:08
*** yalie has quit IRC08:11
*** mfuruta has quit IRC08:13
*** wolverineav has quit IRC08:14
openstackgerritArtur Korzeniewski proposed openstack/neutron: Create a hook in base object to modify the fields before DB operations  https://review.openstack.org/28185008:19
*** hdaniel has joined #openstack-neutron08:19
*** jlanoux has joined #openstack-neutron08:26
*** matrohon has joined #openstack-neutron08:27
*** achanda has quit IRC08:29
*** akshai has quit IRC08:30
*** jpena has joined #openstack-neutron08:31
*** djan has joined #openstack-neutron08:31
*** djan_ has quit IRC08:31
*** feisky has joined #openstack-neutron08:32
scheuranHey good morning rossella_s08:33
*** achanda has joined #openstack-neutron08:33
rossella_sscheuran, morning08:34
scheuranrossella_s, I think I need some advice - I have a couple of options how to handle the migration I want to double check with you08:34
rossella_sscheuran, shoot :)08:34
scheuranrossella_s, #1 on in mech_driver try_to_bind_segment_for_agent I compare the interface mapping of all agents and deny any binding if one does not match08:35
scheuranrossella_s, this would force the admin to synch all its agent configs08:36
scheuranrossella_s, otherwise he can't even launch any instance08:36
scheuranrossella_s, that's the safe way...08:36
*** thorst_afk has joined #openstack-neutron08:36
*** jlanoux has quit IRC08:37
rossella_sscheuran, you need to check the  interface mapping only of the agent that is trying the binding08:37
scheuran#2 in try_to_bind_segment_for_agent I can access the port context. It has device:owner = compute:host, & binding.host = host08:37
*** jlanoux has joined #openstack-neutron08:38
scheurannow on live migration, nova set binding.host to host2 while device:owner keeps host - if the agent does not set the device up08:38
scheuranthis is how I could determine a live migration08:38
scheuranthen check the agent for the device owner host08:38
scheuranand if the mapping is equal - allow binding, if not deny08:39
rossella_sscheuran, to me it makes for sense the first option08:39
rossella_sthe second option is more complex and I am sure there could be corner cases that will bite us later08:40
scheuranbut the problem with #2 is that it does not work for a cold migration, as the device owner is compute:all :(08:40
scheuranyou're right08:40
scheuranlet me elaborate #308:40
rossella_sok08:40
*** mfuruta has joined #openstack-neutron08:41
scheuranpart of the agent status reports is a long list of macvtap mac addresses that are available on this host08:41
scheurannow on binding, I could iterate over all agents and figure out if the mac is available somewhere else as well and if so check the interface mappings08:42
rossella_sscheuran, but anyway you can tell nova to migrate the port to another host08:42
rossella_s*can't08:42
rossella_sso I don't understand why you should check all the agents...you should check only the one that is trying to bind the port, right?08:43
*** thorst_afk has quit IRC08:43
scheuranyes ideally08:43
scheuranthe problem is, before we try to establish the new portbinding, the old portbinding was cleared08:44
*** gongysh has joined #openstack-neutron08:44
scheuranso I don't know where to port originated before08:44
scheuranalso the vid_details are not available any more, as it seems they are getting deleted after unbinding08:44
scheuranrossella_s, the only piece of information that gives me a hint is the device:owner, but only in the case of a live migration...08:46
rossella_sscheuran, everything should be in context._original_port08:46
scheuranrossella_s, this is always none :(08:46
rossella_sscheuran, interesting08:47
rossella_swhy do you need to know where the port originates? you have the network and the interface binding...why is this not enough?08:48
scheuranrossella_s, this would be sufficient if nova would contact neutron before live migration start08:49
scheuranrossella_s, then I could modify the xml accordingly08:49
scheuranrossella_s, but that's not happening today08:50
rossella_sgot that scheuran08:50
rossella_sI guess the idea was refuse to bind and fail08:50
scheuranrossella_s, the agent requests the device details after the instance appeared on the target side (in paused state)08:50
scheuranright08:50
rossella_smaybe I didn't have enough coffee and I am not following :)08:51
scheuranrossella_s, hehe. ok let me try to find other words08:51
scheuranso my mech driver can easily determine the vif details that should be used on the target host08:52
rossella_sso the agent request the details, after lots of method we arrive to try_to_bind_segment_for_agent, ah I think I get i now08:52
scheuranso I need to compare this information somehow to the actual state - where the macvtap resides on08:52
scheuranthe question is, how to get to the current state information08:52
scheuran*current state on the target side08:53
scheuranor on the source side08:53
rossella_sgot08:53
scheurancause both are the same08:53
rossella_sis it stored in the vif_details?08:53
scheuranyes08:53
*** markvoelker has joined #openstack-neutron08:53
rossella_sbut it's empty you say08:53
rossella_sthat's the problem right?08:53
scheuranright08:53
rossella_sI don't understand why it's empty08:54
rossella_sif you get the port from the db, just to test...is it empty there?08:54
scheuranrossella_s, let me try to hack something to figure out the db values...08:56
hdanielajo: hey, good morning :)08:56
rossella_sscheuran, you can simply query the db I guess, even from the db console08:57
rossella_sscheuran, that's just to test if those values are written into the db. If they are there we should find the point in the code where they are cleared08:57
*** markvoelker has quit IRC08:57
scheuranrossella_s, ah ok08:58
rossella_sscheuran, it would probably require some hack...I think we clear the binding at some point, that's where you lose those values08:59
*** tfukushima has quit IRC09:00
scheuranrossella_s, yes, they are stored in the db09:01
scheuranml2-portbindings table09:01
*** tfukushima has joined #openstack-neutron09:02
scheuran2 possible places where this could happen: a) in request device_details  b) when nova updates the binding:host09:02
*** lucas-afk is now known as lucasagomes09:02
*** achanda has quit IRC09:03
rossella_sscheuran, https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L37109:06
ajohey hdaniel09:06
openstackgerritlinwei wu proposed openstack/neutron: Remove unclear built-in in subnetpool exception  https://review.openstack.org/27064909:06
ajohdaniel, any idea of what broke the policies ?09:07
rossella_sscheuran, the vif_details are not copied09:07
hdanielajo: no,09:07
ajohdaniel, may be any change in oslo_policy has broken us?09:07
hdanielajo: no, saw that you have the same issues09:07
scheuranrossella_s, cool09:07
ajoyes, I want to check the graphs and logs09:07
ajoto see when this started09:07
scheuranrossella_s, is there a reason why the original port context is not available anymore?09:08
hdanielhdaniel: cool, I just started doing so - feels like CSI scene09:08
rossella_sscheuran, that's what I am trying to find out09:08
rossella_sscheuran, it's not copied because it's not passed here https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L37109:09
rossella_sscheuran, I don't think there's a good reason for that...probably nobody needed it before. When the code was written migration was not a possibility09:10
rossella_sscheuran, I think we can modify that line to pass the original port so that you can use those data09:10
scheuranrossella_s, was that your intention to paste the same link as before?09:10
rossella_sscheuran, nope sorry, it's few lines after...https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L37409:11
rossella_sscheuran, we can pass the original port to PortContext but it's not done here...I think because usually you bind a port for the first time, so there's no original port. But that's not true for migration09:11
scheuranrossella_s, makes sense. cool - thank you! Let me try that in my test environment09:12
rossella_sscheuran, good luck!!09:12
*** mfuruta has quit IRC09:14
*** rcernin has quit IRC09:14
*** jlanoux has quit IRC09:17
*** salv-orlando has quit IRC09:19
*** salv-orlando has joined #openstack-neutron09:19
*** jschwarz has joined #openstack-neutron09:20
openstackgerritKevin Benton proposed openstack/neutron: Collect details on ARP spoof functional failures  https://review.openstack.org/28518109:24
hdanielajo: just saw some patches pass gate-neutron-dsvm-api , maybe it's worth rechecking ?09:25
ajohdaniel, yeah, try, why not :)09:26
kevinbentonhdaniel, ajo: until this merges i think you will be out of luck https://review.openstack.org/#/c/28491109:27
*** kawa2014 has joined #openstack-neutron09:27
*** jistr has joined #openstack-neutron09:27
ajokevinbenton++09:28
ajothanks, I was trying to investigate the cause, but I see it's under control09:28
openstackgerritHirofumi Ichihara proposed openstack/python-neutronclient: Add tags support  https://review.openstack.org/28236009:28
*** rcernin has joined #openstack-neutron09:28
*** djan has quit IRC09:29
*** jlanoux has joined #openstack-neutron09:30
ajokevinbenton, what's the tempest_lib / tempest.lib history09:30
* ajo looks for the db9672e3473cd chagne09:30
*** sudipto has quit IRC09:30
*** mickeys has joined #openstack-neutron09:30
hdanielkevinbenton: 10x for the head's up - I saw you patch gets the jack-pot, did you rebase on top of https://review.openstack.org/#/c/284911 ?09:31
ajooh09:31
ajodeprecated09:31
*** baohua has quit IRC09:31
*** mgoddard_ has joined #openstack-neutron09:31
kevinbentonhdaniel: which one?09:32
kevinbentonhdaniel: the one to collect failure info?09:32
hdanielKennan: rbac external access09:32
*** ihrachys_ has joined #openstack-neutron09:32
hdanielkevinbenton: ^09:32
kevinbentonhdaniel: oh yeah, i put that on top of his because mine was conflicting with it09:32
kevinbentonhdaniel: with the tempest lib changes in the API tests09:32
hdanielajo: ^ that might do the trick , then09:33
ajohdaniel, may be it's more effective to rebase yours hdaniel  (if you want to buy some time : )09:33
ajoanyway, gate seems quite pressured btw09:33
hdanielajo, kevinbenton: yeah, will do09:33
kevinbentoni must inspect the inside of my eyelids for a few hours, ttyl09:33
ajokevinbenton,  :D09:34
hdanielkevinbenton: cheers09:34
hdanielajo: gtg  - picking up em kids . ttyl09:34
*** hichihara has quit IRC09:34
*** ihrachys has quit IRC09:35
*** fzdarsky has quit IRC09:35
*** mgoddard has quit IRC09:35
*** fzdarsky has joined #openstack-neutron09:35
ajohdaniel,  ack :)09:36
* ajo eyeballs patches09:36
*** fawadkhaliq has quit IRC09:37
*** lezbar__ has joined #openstack-neutron09:37
*** lezbar has quit IRC09:38
*** gongysh has quit IRC09:39
*** gongysh has joined #openstack-neutron09:40
*** neiljerram has joined #openstack-neutron09:40
*** thorst_afk has joined #openstack-neutron09:41
*** akamyshnikova has joined #openstack-neutron09:42
*** sudipto has joined #openstack-neutron09:43
*** mickeys has quit IRC09:44
*** liuyulong has left #openstack-neutron09:44
*** davidsha has joined #openstack-neutron09:44
*** liuyulong has joined #openstack-neutron09:44
liuyulong@jschwarz here?09:44
jschwarzliuyulong, good morning09:45
jschwarz:)09:45
liuyulonghi09:45
jschwarzliuyulong, we want to get https://review.openstack.org/#/c/260303 merged asap IMO (I think you'll agree)09:46
jschwarzliuyulong, so can we move the changes to safe_creation to the patch that actually uses it (that you referenced to earlier)?09:46
liuyulongFor that safe_creation change, we need remove that change?09:46
jschwarzliuyulong, what do you mean?09:47
jschwarzliuyulong, if you move the entire change to safe_creation to https://review.openstack.org/#/c/265682/ , it shouldn't be at 26030309:47
openstackgerritMiguel Angel Ajo proposed openstack/neutron: RPC Callback rolling upgrades reporting, and integration  https://review.openstack.org/26804009:47
liuyulongremove that safe_creation change to its reference patch?09:47
*** thorst_afk has quit IRC09:48
jschwarzliuyulong, yes09:48
jschwarzliuyulong, I think this will let us focus on what really matters :)09:48
liuyulongOK, for now, add/raise the RouterNotFound will make that change no need anymore. I will remove that.09:48
jschwarzliuyulong, excellent, thank you very much09:49
jschwarzliuyulong, as to the race you said in https://review.openstack.org/#/c/257059/09:49
jschwarzliuyulong, with the router-update and create/delete - can you describe a concrete situation to reproduce it?09:49
*** tpsilva has joined #openstack-neutron09:50
jschwarzliuyulong, I agree that if we can do a router-update at the same time as router-delete, there's a possible race09:52
jschwarzliuyulong, however it will be really helpful if we have an "how to reproduce" and a traceback09:52
liuyulongFor the race I mentioned here https://review.openstack.org/#/c/257059/, I have not test it yet, but according to the multi-API workers behavior, that race may happen.09:53
jschwarzliuyulong, ok09:53
liuyulongTry to reproduce it just like I said in that patch inline comments.09:54
jschwarzliuyulong, how about this: you work on the patch to make sure we can merge it asap, and I'll try to reproduce it09:54
jschwarzliuyulong, does that sound good to you?09:54
*** EinstCrazy has quit IRC09:55
liuyulongOK, fine, try that, I am working on 260303 now : ), a new patch is coming very soon.09:55
jschwarzliuyulong, thank you09:55
*** jlibosva has joined #openstack-neutron09:55
jschwarzliuyulong, also, I strongly recommend you hang around this channel09:56
jschwarzliuyulong, Kevin for example is kevinbenton so you can also talk with him (once he's awake) and it's much easier to talk like this :)09:56
davidshaihrachys_: ping09:56
liuyulongyes, I know, thank you.09:57
liuyulongHave you guys ever discuess https://bugs.launchpad.net/neutron/+bug/1523780 and it's sub-bugs?09:58
openstackLaunchpad bug 1523780 in neutron "Race between HA router create and HA router delete" [Medium,In progress] - Assigned to LIU Yulong (dragon889)09:58
liuyulongI've been dealing with the HA router race condition between concurrent creation and deletion for a quite while.09:58
jschwarzliuyulong, not directly, but all the patches we are working on are about fixing those races that you mentioned09:58
jschwarzliuyulong, I understand that you have worked on this a while and it seems that some of kevinbenton's patches and yours try to solve the same thing09:59
ihrachys_davidsha: pong09:59
*** salv-orlando has quit IRC10:00
ihrachys_hdaniel: +2 on rbac patch. waiting for CI.10:00
jschwarzliuyulong, we need to see going forward what's the best thing to do with all of these conflicts10:00
ihrachys_ajo: do we need another core to approve the rbac patch?10:00
jschwarzliuyulong, what I'm interested in knowing is, if we take 3 specific patches - can you find any more races?10:01
davidshaihrachys_: hey, was working on the new patch and the unit tests kept failing. I don't think we can move reserved_cookies out of OVSBridge, I was using the mixin to override set_agent_uuid_stamp but it seems to default to the OVSBridge version where I needed to remove references to reserved_cookies.10:01
jschwarzliuyulong, and if so, what races? then we can fix them together :)10:01
ihrachys_davidsha: doesn't super() help?10:02
liuyulongYes all of that bugs are fired by me, and all have my patchs to solve it.10:02
*** lajos-katona has quit IRC10:02
ihrachys_davidsha: you would have the base class messing with default_cookie, and mixin would add reserved_cookies mechanics10:02
jschwarzliuyulong, so for example the ALLOCATING patch makes some of your patches not so much needed anymore I'm afraid10:02
davidshaIn the mixin? Ok, I'll try that.10:02
ihrachys_davidsha: I personally wouldn't mind either way, but I guess we want to make yamamoto happy10:03
jschwarzliuyulong, so I propose we have a look at all the patches and see what solves which problem and then it'll be easier to decide the best way going forward10:03
jschwarz(all the patches = kevin's ann's and yours)10:03
liuyulongIf the ALLOCATING do not bring new race, I'am OK with that.10:03
jschwarzliuyulong, good10:03
davidshaihrachys_: kk, I'll have it up soon, sorry for the delay.10:03
jschwarzliuyulong, I agree though that 260303 should definitely go in though10:04
*** lajos-katona has joined #openstack-neutron10:04
*** tfukushima has quit IRC10:04
jschwarzliuyulong, anyway I'm gonna try to reproduce that race you mentioned and see if there's something there10:05
openstackgerritJakub Libosvar proposed openstack/neutron: secgroup: Define hybrid plug in driver itself  https://review.openstack.org/28462010:06
*** salv-orlando has joined #openstack-neutron10:08
*** bjornar has joined #openstack-neutron10:08
bjornarIs there any work beeing done to make neutron-server/api run behind a real wsgi server? All the other api's currently run fine under mod_wsgi/uwsgi10:09
*** salv-orlando has quit IRC10:11
hdanielihrachys_: ack10:12
*** javeriak has joined #openstack-neutron10:12
*** salv-orlando has joined #openstack-neutron10:12
liuyulongjschwarz, currently the ALLOCATING status is only added to HA router, the patch title is a little inaccurate. What do you think?10:12
jschwarzliuyulong, as to the race condition you mentioned with the update/delete - I checked it and it doesn't raise any exception10:15
*** wolverineav has joined #openstack-neutron10:15
jschwarzliuyulong, the update-router code is safe and makes sure that the router exists before it tries to unbind it, etc, so no exception is raised10:15
openstackgerritLIU Yulong proposed openstack/neutron: Catch DBReferenceError in HA router race conditions  https://review.openstack.org/26030310:15
*** jckasper has joined #openstack-neutron10:15
jschwarzliuyulong, and actually an error is returned to the user to say that the router was not found10:16
jschwarzliuyulong, so no race is found. I'll comment on the review and describe what I did to try to reproduce this10:16
jschwarzso you can also try yourself :)10:16
jschwarzliuyulong, also I agree that the patch title can be expanded a bit - you can comment so on the review10:17
liuyulongIMO, that race is not easy to produce, try Rally job create_and_update_router10:17
ihrachys_hdaniel: client patch: all good, but you probably need to add a release note10:17
jschwarzliuyulong, ok. let me tell you what I did to try and reproduce this10:17
jschwarzliuyulong, I put a pdb.set_trace() right before the call to _unbind_ha_router10:18
hdanielihrachys_: sure thing - will do10:18
jschwarzliuyulong, then I called router-update --ha=False from a client and made sure the pdb.set_trace() was called10:18
jschwarzliuyulong, then, I deleted the router10:18
jschwarzliuyulong, afterwards I made the unbind_ha_router code continue and no exception was raised10:19
jschwarzliuyulong, did you have a different scenario in mind?10:19
*** jckasper has quit IRC10:20
*** wolverineav has quit IRC10:20
ajoihrachys_, I'd guess yes,10:20
ajootherwise it'd be too in-redhat IMHO10:21
ihrachys_yeah, two redhat cores + redhat author...10:21
jschwarzajo, you can temporarily quit your job, approve and then come back ;-)10:21
jschwarzI'm sure hdaniel wouldn't mind10:21
liuyulongthe race could happen in any time between l3 agents and neutron server10:22
ihrachys_jschwarz: I am not afraid of hdaniel mind :P10:22
ihrachys_kevinbenton: could you take a look for the 2nd time at hdaniel's patch for rbac? https://review.openstack.org/25008110:23
ajoihrachys_, he's looking at his own eyelids now10:23
ihrachys_kevinbenton: it should probably address your previous concerns for the most part10:23
jschwarzliuyulong, I understand it could happen any time - the trick is finding a concrete situation where it does reproduce10:23
ajoihrachys_, but he'll be back soon10:23
ihrachys_ajo: it's kevinbenton, you never know :)10:23
ajolol10:23
ajoinfinite power10:23
jschwarzliuyulong, if we can't reproduce it, I suggest we don't -1 the patch (since we can't prove it's broken) - this way in the worst case scenario we can fix this afterwards10:24
ihrachys_redbull powered review machine10:24
jschwarzajo, the other day he was awake all the way through 3pm our time10:24
jschwarzdebugging HA races with me10:24
liuyulongIf ha router was created and scheduled to l3 agent, then l3 agent try sync the router info, but a router update api just set the statues to ALLOCTIONG, the sync will got a None, then the l3 agent may directly delete the HA router10:24
liuyulong@jschwarz, 260303 is ready for review.10:26
jschwarzliuyulong, I'll look at it in a few minutes. I didn't understand your scenario completely10:26
*** sdague has joined #openstack-neutron10:27
jschwarzliuyulong, if the update API just set the router to ALLOCATING of course the agent will not see the router10:27
ajojschwarz, once upon a time I was able to do that sort of thing, now I do it and I'm dead for one week10:27
*** hoangcx has quit IRC10:27
jschwarzliuyulong, but mind you, keep in mind that changing the HA property of a router is only possible if --admin-state-up=False10:27
ajojschwarz, may be It's influcenced by the fact that I need to wake up 2-3 times every night because of kids...10:27
jschwarzliuyulong, in this case the router isn't scheduled to any agent anyway, and is deleted from them as well10:27
jschwarzliuyulong, so this acts as a safeguard to prevent the race you said10:28
jschwarzajo, aye :<10:28
jschwarzajo, how are you going to cope with our pub-crawling in Austin?!10:28
ajojschwarz, that week I won't be taking care of kids, and having good sleeps10:29
ajothat works :P10:29
jschwarzajo, XD10:29
ajojschwarz, I'll look for a good steak too :P10:29
*** emagana has joined #openstack-neutron10:30
ajohdaniel, do you need help rebasing on the tempest lib patch?10:30
jschwarzajo, oh, i can't wait to taste the infamous Texas steaks10:30
*** gampel has quit IRC10:30
ajohdaniel, it can be done from the gerrit interface itself10:30
jschwarzliuyulong, what do you think on what I said earlier?10:30
ajojust give it the tempest lib 6-digit-gerrit-code10:30
*** tfukushima has joined #openstack-neutron10:30
liuyulongok, yes, that will make sense10:31
jschwarzliuyulong, I'm happy it does. So I'll post this on the review in a minute10:32
jschwarzliuyulong, looking at your patch it looks good to me so I'll +1 it10:32
jschwarz:)10:32
liuyulongwhat about the race between updating HA to false and deleting it ?10:32
ajojlibosva, I see arp_spoof_tests failing a bit: http://logs.openstack.org/11/284911/3/check/gate-neutron-dsvm-functional/76dffe6/testr_results.html.gz10:32
liuyulongwhen its admin-state-up already in flase?10:33
ajorandomly10:33
ajomay we disable those for now ?10:33
*** baohua has joined #openstack-neutron10:33
ajoobondarev,10:33
*** achanda has joined #openstack-neutron10:33
ajothe tempest_lib change failed again10:33
ajoshall we recheck?10:33
jschwarzliuyulong, so that's the scenario I tested earlier10:33
ajoit seems unrelated10:33
jschwarzliuyulong, and as I said, the rest of the 'update-router' code is safe and no exception is raised10:33
ajoobondarev, rechecked10:34
*** emagana has quit IRC10:34
jschwarzliuyulong, also, the router-update code will return a proper 'router not found' error to the user, so even that is happening10:34
jschwarzliuyulong, in other words, no race there :)10:34
scheuranrossella_s, https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L28410:36
scheuranrossella_s, this is the place where the vif_details get removed10:36
*** stanzgy has quit IRC10:36
*** sambetts|afk is now known as sambetts10:37
scheuranbut I have not yet figured out how the binding object correlates to the context...10:37
*** achanda has quit IRC10:38
jschwarzliuyulong, have a look at what I wrote in https://review.openstack.org/#/c/257059/23/neutron/db/l3_hamode_db.py10:39
*** feisky has quit IRC10:41
liuyulongby looking deeply to the _unbind_ha_router(), seems it will delete the HA port multi-times between the updating ha status and deleting API. Nothing harms.10:41
liuyulongI will remove my -110:42
jschwarzliuyulong, thank you10:42
ajoyamamoto,  davidsha : https://review.openstack.org/#/c/267591/27/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/br_cookie.py10:42
davidshaajo: hey10:43
ihrachys_ajo: tell me, why the 8191 magic value in json field for versions?10:43
ajoihrachys_, 65k is the mysql limit10:43
ajobuuuut10:43
ajo65k is also the row limit10:43
ajoso 65k fails10:43
ajo8191 is just bigger than 409510:43
jschwarzliuyulong, I'm going off now (I don't usually work Fridays)10:43
ihrachys_ajo: why not 8192? :)10:44
jschwarzliuyulong, if you need me you can reach me at jschwarz@redhat.com - ok?10:44
ajoihrachys_, TBH, 8000 would also do10:44
ihrachys_ajo: I mean, there should be some reasoning behind the value10:44
jschwarzihrachys_, for the same reason it's not 819310:44
jschwarzdu'h10:44
ajolow level alignment I guess10:44
ajoI was following the other json field size (2^N -1  )10:44
*** bsv___ has joined #openstack-neutron10:44
ajobut  not sure if it's right,10:44
ajoanyway, we should probably not be caring about low level optimizations which are probably done by mysql if needed (alignments)10:45
*** lajos-katona has quit IRC10:45
ajoihrachys_, varchar up to 255 uses 1 byte lenght in Mysql (as far as I understood)10:45
ajothen 2 bytes10:45
*** thorst_afk has joined #openstack-neutron10:45
rossella_sscheuran, the binding should be saved in the context10:46
ajoihrachys_, but for pgsql, it's 1 byte up to 127, then 2 bytes10:46
jschwarzrighto, bb guys10:46
jschwarzhave a happy weekend10:46
*** jschwarz has quit IRC10:46
ihrachys_ajo: I prolly don't need the details :) the fact that you need to explain it to me suggests there is missing comment there.10:46
ajoihrachys_, IMO, it's random, I just picked something bigger and beautiful to my mind :)10:46
ajoprobably no reasonable explanation, it's going to work equally well or bad in any size10:47
ajoas long as data fits10:47
ajohttp://dev.mysql.com/doc/refman/5.7/en/char.html10:47
scheuranrossella_s, you're right and it's still there.. unfortunately it was not present anymore in _bind_port. Something reset the original binding before to the new empty binding...10:48
rossella_sscheuran, not sure if it's too complex to change the code so that you can get the vif_details from the old binding10:48
ajoihrachys_, IMHO we should probably start using JSON fields, but that's only available in latests mysql's10:48
ajo5.7+10:48
ajoalso in postgresql, but haven't checked which version10:48
rossella_sscheuran, either you find out how to avoid the reset...or since you need this info only if it a migration, you can check if it's a migration and get the data from the db10:49
liuyulong@jschwarz, and for the patch https://review.openstack.org/#/c/265685/, any advice? seems that the DB error was no longer existed.10:50
scheuranrossella_s, I think at that point in time it's too late to catch the data from db - but I need to verify, first. I hope I can find the place where it gets removed..10:50
rossella_sscheuran, I am sure you can find it...question is if it's going to be easy to modify the code without breaking other stuff..10:50
scheuranrossella_s, :)10:51
rossella_sscheuran, good luck!10:51
scheuranrossella_s, thanks10:51
ajoihrachys_, please also check my comments in PS14: https://review.openstack.org/#/c/268040/14/neutron/db/agents_db.py10:51
ajoI rebased and those are lost, but I believe it's probably a good strategy what I was thinking of10:51
*** hanchao has quit IRC10:51
ajobecause it buys us less changes in the plugins that use agents10:52
*** thorst_afk has quit IRC10:53
ajoihrachys_, specifically: https://review.openstack.org/#/c/268040/14/neutron/db/agents_db.py@37210:53
ihrachys_ajo: JSON type is not supported by our sqlalchemy version10:53
*** markvoelker has joined #openstack-neutron10:54
*** salv-orlando has quit IRC10:57
ajoihrachys_, hm, I thought it was already there, but I guess we don't use yet latest an greatest10:57
ihrachys_ajo: it's 1.110:57
ihrachys_and we have <1.110:57
ihrachys_we use 1.0.+ now10:57
ajoack10:58
ajothat has to wait then10:58
jlibosvaajo: yes, I saw that too. Note it has nothing to do with ovs firewall :)10:58
jlibosvaajo: I saw a patch today from kevinbenton to add some additional info to see what's going on10:58
*** markvoelker has quit IRC10:58
ajojlibosva, yes, but you wrote the test, right? :)10:58
ajoack10:59
jlibosvaajo: no10:59
*** yfried has quit IRC10:59
*** liuyulong has quit IRC10:59
ajoahh, ok, ':D10:59
jlibosva:]10:59
ajojlibosva, just curious, do you know what's the patch with extra debug?10:59
jlibosvaajo: you want link?10:59
ajojlibosva, https://review.openstack.org/#/c/285181/ I guess?11:00
ajo:)11:00
jlibosvaajo: your guess is correct :)11:00
ihrachys_ajo: agreed that moving the code into report_state handler would be the best.11:00
ihrachys_ajo: I posted some comments11:00
*** lajos-katona has joined #openstack-neutron11:01
*** vikram_ has joined #openstack-neutron11:01
ajoihrachys_, thanks, I'll finish the QoS LB review, and move back to it11:02
ajoihrachys_, was the unit conversion concern because my conversation bout burst_kbps ?11:02
ajoabou11:02
ajot11:02
ajo....... ':)11:02
ihrachys_ajo: no, it's different11:02
ihrachys_ajo: it's about tc using bytes not bits11:02
ihrachys_and slaweq realized it lately11:02
ajoihrachys_, ack11:06
*** miyagishi_t_ has joined #openstack-neutron11:12
hdanielajo: I'd like to attempt it myself at first :) , 10x11:13
slaweq__ihrachys_ ajo: yep, I have it fixed on my dev host already11:14
slaweq__but I need to fix also this problem with notifications about policy update11:14
slaweq__and then will push it all to review11:14
ajonjohnston, do we know if VXLAN/GRE linux implementation copies the DSCP flags from the inner packets to the outer frame ?11:18
ajothat'd be cool for vxlan tenant networks11:18
ajoyou'd get in-tenant packet prioritization too11:18
*** gvrangan_ has quit IRC11:21
*** gvrangan has quit IRC11:21
ajohmm http://lxr.free-electrons.com/source/drivers/net/vxlan.c#L197911:21
*** gongysh has quit IRC11:22
ihrachys_mestery: I wonder whether we could let https://review.openstack.org/#/c/263819/ going11:25
njohnstonajo: No, it does not.  There are RFCs that govern that if you want to do that, and it gets very complicated very quickly, especially if you imagine a vxlan where some of the packets should be tagged DSCP but others shouldn't, so you get different on-the-wire behavior from different packets in the same TCP sequence.11:29
njohnstonajo: So our approach for this was to avoid the entire question and not tag the encapsulating frame.11:29
ajohmm njohnston can you explain?11:30
ajowhy if every packet is individually encapsulate would be an issue?11:30
ajoor can a vxlan packet encapsulate several?11:30
ajoindividually encapsulate -> encapsulated11:30
ajoI see the vxlan support in kernel seems to have support for that (if you set the tos flag to 1, and I didn't get it wrong)11:31
ajobut ovs does not set that flag11:31
ajowe could make it optional11:32
*** armax has joined #openstack-neutron11:32
ajoadmin could deploy his net with that on or off11:32
*** EinstCrazy has joined #openstack-neutron11:32
ajonjohnston: for example an agent setting...  (I'm not talking about now, but possible future follow ups if it makes any sense at all)11:32
ajonjohnston, and of course, we'd need some setting in openvswitch to propagate that down to https://github.com/openvswitch/ovs/blob/master/datapath/vport-vxlan.c#L9111:33
njohnstonajo: Yeah, I could definitely see it in a future follow up.  It could be useful especially in cases where congestion is an issue, but it would have to be tested to make sure the vxlan wouldn't freak out if packets arrived out-of-order or with significant drops in the non-tagged packets.  FYI the governing RFC for this is https://tools.ietf.org/html/rfc298311:34
*** achanda has joined #openstack-neutron11:35
ajooh, thanks for the pointer njohnston11:35
*** armax has quit IRC11:36
*** pavel_bondar has quit IRC11:36
ajonjohnston: I understand the concern, but of course, it'd be another tool for admins to tune their networks, they can shot themselves on the foot in many different ways :D11:36
*** sudipto has quit IRC11:36
ajoI'll read the RFC11:36
*** miyagishi_t_ has quit IRC11:37
njohnston:-)11:39
*** achanda has quit IRC11:39
*** baohua has quit IRC11:50
*** thorst_afk has joined #openstack-neutron11:50
ajonjohnston, I'd say vxlan doesn't have an issue with that, I think it doesn't have any sequence number11:51
ajoit's just VNI and metadata (/me checks)11:51
*** baohua has joined #openstack-neutron11:51
ajonjohnston, I understand what you mean now, but yeah, I think VXLAN is quite sequence independent11:52
*** thorst_afk has quit IRC11:57
*** baoli has joined #openstack-neutron11:58
openstackgerritLIU Yulong proposed openstack/neutron: Catch exceptions during the delete of tenant last HA router  https://review.openstack.org/26568211:59
ajoslaweq, ping: https://review.openstack.org/#/c/236210/29   what's the issue bit/bytes that ihrachys_ comments respect to burst rate, I couldn't notice it by looking at the code11:59
ihrachys_ajo: stop mixing things :)11:59
ihrachys_ajo: burst is not related to that at all12:00
ajooh12:00
ajosorry :D12:00
ajogeneral bit/byte12:00
ajoI see they handle the conversion12:00
ihrachys_yes12:00
ajoto bytes for TC12:00
ajomay be tc works with bits ?12:00
ihrachys_burst issue is about the param having _kbps postfix12:00
ajocorrect12:00
ihrachys_iiuc tc works with bytes12:00
ihrachys_and our API is kbit based12:00
ajoihrachys_, but he handles the conversion in code12:01
ihrachys_ajo: prolly in wrong way12:01
ajohttps://review.openstack.org/#/c/236210/29/neutron/agent/linux/tc_lib.py@11212:01
ajohttps://review.openstack.org/#/c/236210/29/neutron/agent/linux/tc_lib.py@12912:02
ihrachys_ajo: iiuc tc uses 'kb' postfix for bytes12:02
ihrachys_so you don't need to convert12:02
ajohh12:02
ajohe's using "kb" postfix12:02
ajothat's it12:02
slaweq__ajo: tc is using strange (for me) notation of units12:02
ihrachys_what was the link to gate failures dashboard?12:02
*** ihrachys_ is now known as ihrachys12:03
slaweq__and I made mistake there because in tc kbps means kilobytes (not kilobits as usual)12:03
*** baoli has quit IRC12:03
slaweq__that's why in this file I configured wrong values in fact12:03
ajoahaaa12:03
ajoI see http://man7.org/linux/man-pages/man8/tc.8.html12:04
*** baoli has joined #openstack-neutron12:04
ajoacl12:04
slaweq__exactly12:04
slaweq__and I made mistake because in neutron api it is also kbps (and in ovs also) but it means something different12:05
slaweq__:)12:05
slaweq__but I found it in fullstack test when I started doing it few days ago :)12:05
slaweq__so fullstack tests are good12:05
ajofullstack++12:05
hdanielajo:  did you try rebasing your rpc patch over the 'tempest_lib' one  ?12:06
slaweq__and also in this test I found that LinuxBridge agent is not consuming "policy update" notifications12:06
ajohdaniel, I did, it's rebased12:07
hdanieland you don't get 'No module named lib.common.utils' ?12:07
ajohdaniel, where?12:07
hdanielajo: when running api tests12:07
ajohdaniel, nope12:07
ajohdaniel, : https://review.openstack.org/#/c/268040/12:08
*** yamamoto has quit IRC12:08
*** mubirru has quit IRC12:08
hdanielajo: hmmm, I was trying to run it on my env before that - it fails finding the utils module. oh well.12:09
ajohdaniel, may be you need to update your tempest repo12:12
ajohdaniel, it's probably that12:12
ajothey copied tempest_lib inside tempest12:12
ajoand your local copy of tempest os probably outdated12:12
ajocd /opt/stack/tempest; git pull12:12
ajohdaniel,  ^12:12
ajoos->is12:13
*** krotscheck_dcm is now known as krotscheck12:13
hdanielajo++12:15
ajohdaniel,  :)12:15
*** baoli has quit IRC12:15
ajodid it work?12:16
*** wolverineav has joined #openstack-neutron12:17
*** baoli has joined #openstack-neutron12:20
*** salv-orlando has joined #openstack-neutron12:20
*** zhipeng has quit IRC12:21
*** baohua has quit IRC12:22
*** wolverineav has quit IRC12:22
*** baoli has quit IRC12:23
*** baohua has joined #openstack-neutron12:24
*** sleviim has joined #openstack-neutron12:31
*** sleviim has left #openstack-neutron12:31
*** amotoki_ has joined #openstack-neutron12:32
*** claudiub has quit IRC12:34
*** amotoki has quit IRC12:34
openstackgerritHaim Daniel proposed openstack/neutron: Qos policy RBAC DB setup and migration  https://review.openstack.org/25008112:39
*** fzdarsky is now known as fzdarsky|afk12:39
*** markvoelker has joined #openstack-neutron12:40
*** markvoelker has quit IRC12:44
*** bsv___ has quit IRC12:45
*** julim has joined #openstack-neutron12:45
*** MCoLo has quit IRC12:48
*** thorst_afk has joined #openstack-neutron12:50
ajoihrachys, good catch there: https://review.openstack.org/#/c/268040/15/neutron/api/rpc/callbacks/version_manager.py@10612:53
* ajo goes for lunch12:53
*** johnbelamaric has quit IRC12:56
*** emagana has joined #openstack-neutron12:57
*** ArchiFleKs has quit IRC13:01
*** korzen_ has joined #openstack-neutron13:01
*** yamamoto has joined #openstack-neutron13:01
*** emagana has quit IRC13:01
*** korzen has quit IRC13:02
*** jpena is now known as jpena|lunch13:02
*** ArchiFleKs has joined #openstack-neutron13:02
*** claudiub has joined #openstack-neutron13:03
openstackgerritAkihiro Motoki proposed openstack/python-neutronclient: WIP: Allow to add non-CRUD methods to v2_0.client thru client extension  https://review.openstack.org/28528813:04
openstackgerritRyan Moats proposed openstack/neutron: Collector Proof of Concept  https://review.openstack.org/21347413:05
*** yamamoto has quit IRC13:05
*** jckasper has joined #openstack-neutron13:06
*** davidsha has quit IRC13:06
*** ArchiFleKs has quit IRC13:09
*** lucasagomes is now known as lucas-hungry13:09
*** ArchiFleKs has joined #openstack-neutron13:09
*** baoli has joined #openstack-neutron13:10
*** jckasper has quit IRC13:10
*** ArchiFleKs has quit IRC13:13
*** prithiv has joined #openstack-neutron13:14
*** itisha has joined #openstack-neutron13:15
*** MCoLo has joined #openstack-neutron13:15
*** banix has joined #openstack-neutron13:16
*** pavel_bondar has joined #openstack-neutron13:16
*** eddima1 has joined #openstack-neutron13:17
*** ArchiFleKs has joined #openstack-neutron13:17
*** fzdarsky|afk is now known as fzdarsky13:17
*** baoli_ has joined #openstack-neutron13:17
*** eddima has quit IRC13:17
*** eddima1 is now known as eddima13:17
*** davidsha has joined #openstack-neutron13:18
*** thorst_afk is now known as thorst13:18
*** baohua has quit IRC13:19
*** markvoelker has joined #openstack-neutron13:20
*** neeti has quit IRC13:20
*** baoli has quit IRC13:20
*** akshai has joined #openstack-neutron13:21
*** akshai_ has joined #openstack-neutron13:23
*** yamamoto has joined #openstack-neutron13:25
*** dslevin has joined #openstack-neutron13:26
*** akshai has quit IRC13:26
*** dslevin has quit IRC13:26
*** dslevin has joined #openstack-neutron13:27
*** sleviim has joined #openstack-neutron13:29
*** neelashah has joined #openstack-neutron13:29
*** sleviim has left #openstack-neutron13:29
*** akshai_ has quit IRC13:29
*** yamamoto has quit IRC13:30
*** pradk has joined #openstack-neutron13:31
*** pradk has quit IRC13:31
*** fawadkhaliq has joined #openstack-neutron13:36
*** abregman has joined #openstack-neutron13:37
*** achanda has joined #openstack-neutron13:37
ihrachysSam-I-Am: nice progress on MTU stuff13:39
*** cappetta has joined #openstack-neutron13:39
ihrachysI think I reviewed all the bits currently uploaded to gerrit. I assume that's all that we want in, right?13:40
openstackgerritHynek Mlnarik proposed openstack/neutron: Use cookies consistently in flows of all bridges  https://review.openstack.org/28463913:42
*** achanda has quit IRC13:42
*** pradk has joined #openstack-neutron13:43
*** javeriak has quit IRC13:44
openstackgerritAkihiro Motoki proposed openstack/python-neutronclient: WIP: Allow to add non-CRUD methods to v2_0.client thru client extension  https://review.openstack.org/28528813:44
openstackgerritabregman proposed openstack/neutron: DO NOT MERGE - Verfying doc gate functionalility  https://review.openstack.org/28484913:45
*** shwetaap has joined #openstack-neutron13:45
Sam-I-Amihrachys: yeah i think so13:45
*** shwetaap1 has joined #openstack-neutron13:47
*** jckasper has joined #openstack-neutron13:47
*** lnicolas has quit IRC13:49
*** shwetaap has quit IRC13:50
*** edmondsw has joined #openstack-neutron13:50
*** jckasper has quit IRC13:52
*** dims has joined #openstack-neutron13:54
*** feleouet has joined #openstack-neutron13:55
*** johnbelamaric has joined #openstack-neutron13:57
*** armax has joined #openstack-neutron13:57
*** eddima has quit IRC13:57
*** eddima has joined #openstack-neutron13:58
Sam-I-Amihrachys: i think we might need a relnote because support for larger than 1500 byte MTU is a feature13:58
ihrachysright13:58
Sam-I-Amin addition to fixing something that should have just worked13:58
*** eddima has quit IRC13:59
*** eddima has joined #openstack-neutron13:59
*** shwetaap1 has quit IRC14:00
openstackgerritArmando Migliaccio proposed openstack/neutron: Switch to using in-tree tempest lib  https://review.openstack.org/28491114:00
ajohi hynekm++ ^ nice patch :14:00
*** skamithi13 has joined #openstack-neutron14:00
*** eddima has quit IRC14:01
hynekmajo, thanks. would you mind reviewing it? :-)14:02
pc_marmax: ping14:02
armaxpc_m: pong14:02
pc_marmax: Hi. For vpnaas, I modified (and upstreamed) tox.ini so that is runs all targets with constraints.14:02
armaxpc_m: ok14:02
pc_marmax: I cherry picked to Liberty, but it fails, because vpn uses a neutron script, which in liberty does not support this.14:03
armaxon this note, I wonder where the vpn api transition effort lies14:03
armaxpc_m: forget about liberty for now, that would be my advice14:03
armaxto me the api tests for mitaka is top priority14:03
pc_mThis is running constraints w/o using -constraints name in target.14:03
*** annemccormick has joined #openstack-neutron14:04
pc_munderstood. Just trying to get the bug I was working on (constraints for *aas/Nlib) done.14:04
armaxthat’s done for mitaka though14:04
pc_mdidin't know if you wanted neutron updated (and backported) or not.14:04
armaxis it not?14:05
armaxwell ideally14:05
armaxbut if it’s too convoluted14:05
pc_myes, however, the project config job is setup for liberty and mitaka.14:05
*** korzen has joined #openstack-neutron14:05
armaxwe may want to put up with the current status for an extra cycle14:05
ajohynekm, I will as soon as I respin the rpc patch I will 'eyeball' your patch14:05
armaxit’s not like we’d be cronically broken if we don’t backport the constraints magic14:06
pc_marmax: So skip backport for Liberty?14:06
armaxpc_m: unless it’s straightforward and you can accomplish with minimal effort14:06
*** korzen_ has quit IRC14:07
pc_mIt requires updating neutron script. Which means, updating neutron for mitaka, backporting that, and then vpn is good to go.14:07
pc_mneutron still uses the -constraints named targets.14:07
pc_mvpn is the only one converted over completely so far.14:08
hynekmajo, hope that the eyeballs won't be rolling too fast :) thanks14:08
armaxpc_m: so you’re saying that vpn is not constrained in mitaka either?14:08
pc_marmax: no.14:08
*** skamithi has joined #openstack-neutron14:08
ajohynekm, lol14:08
pc_marmax: VPN is using constraints for mitaka, like all the others, only the target names (per TC's request) do not have -constraints suffix.14:09
pc_mIOW constraints is the default.14:09
armaxpc_m: right, I think I saw that somewhere14:09
pc_mSo, I went into vpn and changed tox.ini and gate hooks. Upstreamed that work.14:09
russellbkevinbenton: nope, i'm already on the way home14:10
pc_mNow there are several avenues. Leave liberty with unconstrained targets (py27,...), or cherry pick. To do the latter, we need change to neutron.14:10
*** eddima has joined #openstack-neutron14:10
armaxpc_m: I see14:10
armaxpc_m: changing neutron master to drop the -constraints labels and backport you mean?14:11
*** vhoward has joined #openstack-neutron14:11
pc_mWanting to know if I should do the neutron conversion (py-27 vs py27-constraints) for mitaka, and whether it that should be backported.14:11
pc_marmax: yas14:11
pc_myes14:11
armaxpc_m: do you have that note from the TC?14:12
armaxpc_m: I recall seeing this done somewhere in Nova14:12
armaxpc_m: but that’s all I recall14:12
pc_marmax: No. It was in meeting mins, several weeks ago.14:12
pc_mThey don't want the -constraints targets.14:12
armaxwhen it comes to touching stable branches, ihrachys should really be the one signing off on any activity like that14:13
ihrachysarmax: whatsup14:13
*** abregman is now known as abregman|nb14:13
pc_marmax: He's been on the reviews, as has doug14:13
armaxwe could pursue the venue that you suggested, but I am failing to grasp what it would happen if we dropped the -constraints label on master only14:13
armaxand leave Liberty be14:13
armaxihrachys: I was pulling you in because pcm would like to rename the gate jobs and have the -constraints job dropped14:14
pc_marmax: for VPN, it will NOT be using constraints on Liberty (as it stands today)14:14
armaxnow that would need to be done in master before it could be backported14:14
*** EinstCrazy has quit IRC14:14
ihrachysarmax: it's the issue of different names for tox targets in master vs stable?14:14
armaxihrachys: correct14:15
armaxnow, I must admit I am not up to speed with the marching orders14:15
ihrachysok. do we have a plan that I could digest?14:15
*** rtheis has joined #openstack-neutron14:15
armaxbut I would suspect that flipping the constraints suffix would require touching project-config too14:15
pc_mihrachys: VPN master done. Libery, issue w/dependency on neutron.14:16
armaxpc_m: if you could provide us with the notes14:16
*** yamamoto has joined #openstack-neutron14:16
pc_marmax: Will dig for them.14:16
armaxpc_m: that would give us better insight why the rename exercise would be necessary and its timeline14:16
*** jckasper has joined #openstack-neutron14:16
*** jpena|lunch is now known as jpena14:16
armaxat this point, I am not sure I have enough information to make a decision14:17
armaxor provide a suggestion14:17
*** tiswanso has joined #openstack-neutron14:18
*** wolverineav has joined #openstack-neutron14:19
armaxpc_m: pls let me know what the rationale for the rename is and we can review what we can do in time for the mitaka release14:19
ihrachysarmax: pc_m: I think it would be wise to have some etherpad with all details, so that we could grasp the whole picture before we go into implementation14:19
armaxin the meantime, if there’s anything I can help you with to facilitate the setup of the api job for vpnaas, feel free to ping me14:20
*** insequent has quit IRC14:20
ihrachysdavidsha: some nits in the patch. I am fine to +2 after it's handled.14:20
pc_marmax: http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-01-19-20.02.log.html14:20
pc_mThere was no mandate for a time frame14:20
* armax reads14:21
*** insequent has joined #openstack-neutron14:21
pc_marmax: They want projects to move to not using the constraints naming.14:21
davidshaihrachys: just responding, I can do the dots but not the ones in br_cookie, I'll put it in the comments14:21
*** jaypipes is now known as sicklypipes14:22
pc_mlifeless: Can you comment on constraints from a TC perspective ^^14:22
armaxpc_m: bear in mind that we don’t run two jobs in the gate14:22
armaxpc_m: so really we have already opted in14:22
pc_marmax: I'm not sure who is working on the API stuff, nor where the status is on that (I'm not working on it, nor plan to)14:22
armaxthe developer has the choice to run the unconstrained target if they wanted to14:22
*** lucas-hungry is now known as lucasagomes14:23
armaxbut from scanning through the review it doesn’t seem like dropping the unconstrained target and renaming the jobs buys us anything14:23
armaxpc_m: well, thanks!14:23
*** wolverineav has quit IRC14:24
armaxpc_m: I think the madhu is working on it14:24
davidshaihrachys: nvm I'll try it out now14:24
ihrachysdavidsha: ok ping me when done14:24
ihrachysdavidsha: ok :)14:24
armaxpc_m: I was simply suggest you’d keep an eye on it and help her where required14:24
armaxpc_m: after all you’re one of the vpn custodians14:25
armaxpc_m: are you not?14:25
pc_marmax: Have been and will continue.14:25
pc_marmax: Well, no... I moved away from that months ago... remember?14:25
*** anshul has quit IRC14:25
*** abregman|nb is now known as abregman14:26
pc_marmax: I've been trying to do reviews and address critical issues, like breakages, as much as I can.14:26
*** akshai has joined #openstack-neutron14:26
armaxpc_m: right, but there’s stuff that’s still pending14:27
armaxpc_m: it’d be nice to identify someone who could take over at full capacity14:27
pc_marmax: sure, but not any tasks I promised to complete for that repo. I completed the work I had in hand at the time I notified people I was moving off of that project.14:28
pc_marmax: There are a few people that have been helping, but no-one has stepped up.14:28
*** baoli has joined #openstack-neutron14:28
armaxpc_m: that were clearly important tasks that were not completed nor started14:28
armaxpc_m: I am not saying you should be dragged back in14:29
armaxpc_m: but if you have bandwidth to do anything with vpn14:29
*** hynekm has quit IRC14:29
armaxlike the constraints stuff14:29
pc_marmax: good, because my employer doesn't want me to continue on vpn.14:29
armaxI’d rather suggest you to work on higher priority stuff14:29
armaxnot just stuff that pleases you14:29
armaxpc_m: ok, that’s fine I get that14:29
armaxpc_m: let’s figure out together what can be done, otehrwise we’ll be forced to mark vpn as a rotten apple and move on14:30
ajoihrachys, can you have an eye on https://review.openstack.org/#/c/268040/15/neutron/api/rpc/callbacks/version_manager.py@173 , I will be working in other parts, but I'd like to check if that sounds reasonable to you.14:30
pc_marmax: Believe me constraints is not something that pleases me. I'm trying to fullfill that obligation that I committed to.14:30
armaxpc_m: where is this obligation coming from?14:31
pc_marmax: https://bugs.launchpad.net/neutron/+bug/152250314:31
openstackLaunchpad bug 1522503 in neutron "Add support for constraints based jobs for neutron-*aas and -lib" [High,In progress] - Assigned to Paul Michali (pcm)14:31
*** baoli_ has quit IRC14:31
pc_marmax: So last word on this. Please respond to that bug and indicate what you want done - continued, done on liberty too, dropped, whatever.14:32
armaxok14:32
ihrachysajo: I don't mind. let's get it in.14:32
armaxpc_m: is the job completed in master?14:32
armaxfor all repos?14:32
ajoihrachys, ack, let me fix it14:32
*** akshai has quit IRC14:33
pc_marmax: no. I completed on VPN. I had some work done on the other repos, but because of the TC recommendation, I abandoned the work, and reworked VPN to meet those needs.14:33
ihrachyspc_m: can we get the state of constraints captured somewhere, and we could then take it from there?14:34
armaxpc_m: ok, consider the job complete and move on14:34
pc_marmax: Essentially, infra didn't want changes done unless they were in line with the new method.14:34
armaxpc_m: we’ll pick it up if need be14:34
pc_marmax: Please put that in the bug.14:34
pc_marmax: Your decision on the matter.14:35
armaxpc_m: dfoner14:35
armaxdone14:35
pc_marmax: thanks.14:35
armaxpc_m: you’re good, fly high14:35
*** baoli has quit IRC14:35
*** amotoki_ has quit IRC14:36
*** dansmith is now known as superdan14:36
scheuranhi rossella_s, I figured out a way how to prevent the port binding on an invalid live migration in the plugin and I also can detect that in the agent..14:37
scheuranrossella_s, but somehow I have messed up my test systems and I'm not sure if I can point a solution by end of today14:37
scheuranrossella_s, do you see a chance to get the main part merged right before m3, and then handle the live migration thing as a bugfix?14:38
*** mlavalle has joined #openstack-neutron14:41
rossella_sscheuran, your rfe was approved for mitaka and the code is quite isolated...it shouldn't be a problem to merge it. Maybe you can specify that live migration is not supported. Regarding treating the live migration fix as bug...might be risky to merge it, it depends on how much you change14:41
rossella_sscheuran, anyway you should talk about it with the neutron drivers and the PTL...you might want to ping kevinbenton and armax14:42
*** localloop127 has joined #openstack-neutron14:42
*** sc68cal has joined #openstack-neutron14:44
Sam-I-Ammornings14:45
sc68calSam-I-Am: morning14:45
scheuranrossella_s, ok, thanks - will do14:45
*** dane_leblanc has joined #openstack-neutron14:45
rossella_sscheuran, np :)14:46
Sam-I-Amsc68cal: MOOOOOOOOOoooo14:46
*** banix has quit IRC14:46
scheuranrossella_s, FYI, it was really just passing the original port into the new context and then this information is available in the mech driver...14:47
rossella_sscheuran, then it seems safe14:47
scheuranarmax, do you have second to discuss how to continue with https://bugs.launchpad.net/neutron/+bug/148097914:48
openstackLaunchpad bug 1480979 in neutron "[RFE] Adding macvtap ml2 driver and agent" [Wishlist,In progress] - Assigned to Andreas Scheuring (andreas-scheuring)14:48
*** amotoki has joined #openstack-neutron14:48
*** gvrangan has joined #openstack-neutron14:48
*** gvrangan_ has joined #openstack-neutron14:48
armaxscheuran: only a few mins14:49
armaxscheuran: what about it?14:49
scheuranarmax, that should be sufficient14:49
scheuranarmax, the mech driver has already, merged, the agent is short before getting merged14:49
scheuranarmax, there's just one open issue14:49
scheuranthat came up the last 2 days14:49
armaxok14:49
scheuranarmax, it's about live migration14:50
scheuranarmax, it works, but if host a has an interface mapping of physnet1=eth0 and host2 a mapping of physnet1=abc14:50
scheuranarmax, the migrated instance will be placed on eth0 on host2 as well (although not specified in the mapping)14:50
*** baoli has joined #openstack-neutron14:51
scheuranarmax, this is a problem14:51
armaxscheuran: none of the patches that target the bug have release notes, vbtw14:51
armaxscheuran: am I missing something?14:51
*** crose has joined #openstack-neutron14:51
armaxcould this be captured in the release notes perhaps?14:51
*** akshai has joined #openstack-neutron14:51
scheuranarmax, https://review.openstack.org/#/c/275306/14:52
scheuranarmax, this is the last outstanding patch14:52
armaxscheuran: ah, wrong topic14:52
scheuranarmax, sorry, I changed it again by mistake...14:52
scheuranarmax, yes, it could be handled by the release notes14:52
armaxscheuran: how much of a release blocker you think this is?14:53
scheuranarmax, I can detect those missbehaviors in the agent and in the mech driver - but there's no time left to fix that before m3 I assume14:53
scheuranarmax, so my question is if we could merge the main part and handle the migration issue as a bugfix14:53
armaxscheuran: it sounds like the live migration behavior is undetermined if the compute nodes are not configured uniformly14:54
scheuranarmax, right14:54
armaxat least in the current version of the coe14:54
armaxcode14:54
*** mhickey has joined #openstack-neutron14:54
scheuranexactly14:54
armaxthis is going to be greenfield though, would it not?14:54
armaxI expect to capture this in the release notes14:54
*** fawadkhaliq has quit IRC14:55
armaxscheuran: bear in mind that I would like to see openstack-manuals content for this effort to be marked complete14:55
*** abregman is now known as abregman|nb14:55
armaxI mean the networking guide section for the openstack-manuals14:55
scheuranarmax, sorry what do you mean by " going to be greenfield though" ?14:55
scheuranarmax, the scenario guide already has a workflow14:55
scheuranit's just waiting for the agent patch to get it14:56
armaxthen we can elaborate a bit more on how this issue manifests itself and how to make sure the admin can prevent him/herselfs from shooting his/her foot14:56
armaxscheuran: what I mean is that you need deploy the mactapv agents for the first time14:56
scheuranarmax, right14:57
scheuranarmax, and yes, if the admin configures everything correctly - there is no issue!14:57
scheuranarmax, so you would be ok if I document this in more detail in the scenario guide?14:57
*** rossella_s has quit IRC14:58
scheuranarmax, I mean I still can come up with a fix for that before the final release14:58
scheuranbut probably not before m314:58
armaxscheuran: if you have time then we can figure out the extent of the fix and see if there’s time during the rc window14:58
openstackgerritSean M. Collins proposed openstack/neutron: ML2: Increase segment_mtu from 0 to 1500 bytes  https://review.openstack.org/28440714:58
openstackgerritSean M. Collins proposed openstack/neutron: Set DEFAULT_NETWORK_MTU constant to sane 1500 byte default  https://review.openstack.org/28533914:58
*** rossella_s has joined #openstack-neutron14:58
*** fishbone has joined #openstack-neutron14:58
Sam-I-Amsc68cal: pffft, sane values14:59
sc68calSam-I-Am: I know right?14:59
armaxscheuran: but I’d suggest to make sure we have at least enough doc in place and point to the issue (bug report) and if we have time to nail it down14:59
Sam-I-Ami need to write a relnote for the mtu patch...14:59
Sam-I-Amwell, one of them14:59
armaxscheuran: great, if not at least we don’t cause any unwanted surprise14:59
Sam-I-Amsolving world hunger... and mtu problems14:59
scheuranarmax, so if I got you right: let's merge this, let's udpate the docs to reflect more details and let's open a bug for it and try to resolve before the rc phase?15:00
armaxyes15:00
armaxscheuran: now to make sure I understood you right15:01
*** jreeves has quit IRC15:01
armaxscheuran: this issue is a blocker for deployments where you roll out the mactap driver alongside LB or OVS agents and compute hosts have heterogeneous physnet attachments15:01
armaxblocker as far as live migration goes15:01
armaxor any type of migration for that matter15:02
armaxlike resize or block migration15:02
scheuranarmax, ovs or lb are not in the game15:02
*** amotoki has quit IRC15:02
scheuranarmax, just assume a pure macvtap deployment15:02
scheuranarmax, on compute nodes15:02
armaxok15:02
scheuranarmax, to get around this issue, that admin needs to configure the same interface mapping on each host15:03
armaxscheuran: that’s even beter15:03
armaxbetter15:03
*** shwetaap has joined #openstack-neutron15:03
scheuranarmax, if the target runs lb or ovs - migration will fail anyhow15:03
armaxthen this is greenfield as I hinted above15:03
scheuranarmax, ok, so I will ask rossella_s to merge this last patch, and I'll take care about advanced doc and the fix, ok?15:04
*** akamyshnikova has quit IRC15:04
armaxscheuran: seems like a sound plan15:04
scheuranarmax, ok, thank you!15:04
*** rickyrem has joined #openstack-neutron15:05
rossella_sthanks armax!15:05
*** banix has joined #openstack-neutron15:05
scheuranrossella_s, is this approach ok for you?15:06
armaxrossella_s: np, can I remind you to check in on https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms15:06
armaxrossella_s: even though it’s unlikely to see this merge/complete in time for Mitaka15:06
armaxrossella_s: it’d be nice to get that in shape for N15:07
rossella_sarmax, yes I got that feeling too...I am trying to keep up but you can remind me any time15:07
armaxrossella_s: I saw you dropped some reviews..but maybe you can try and nudge the authors to respond ;)15:08
rossella_sarmax, good suggestion ;)15:08
armaxI meant dropped on by some reviews15:08
*** anilvenkata has quit IRC15:08
rossella_sarmax, btw thanks for getting the spec into shape, things got so much better when you chimed in ;)15:08
armaxrossella_s: let’s see if we find out any nonsense during the implemenation process ;)15:09
rossella_sarmax, that's our job, creating and fixing nonsenses15:10
armaxrossella_s: um, not sure that sounds right, but ok15:10
armax:)15:10
openstackgerritArtur Korzeniewski proposed openstack/neutron: Add custom SQLAlchemy type for CIDR.  https://review.openstack.org/28534915:10
*** hdaniel has quit IRC15:10
armaxin my head this reads like: “keep ourselves busy for no good reason'15:10
rossella_sarmax, :D15:10
scheuranrossella_s, when I update the release notes in the gerrit, will this cause a new patchset to be created?15:12
rossella_sscheuran, I think so15:12
rossella_sscheuran, anyway we are now kind of blocked till https://review.openstack.org/#/c/284911/ merges15:13
scheuranrossella_s, makes sense15:14
*** irenab has joined #openstack-neutron15:14
*** korzen has quit IRC15:15
*** h10_a has joined #openstack-neutron15:18
Sam-I-Amkevinbenton: working on a relnote for the mtu plugging patch15:19
*** ajmiller has joined #openstack-neutron15:20
openstackgerritRossella Sblendido proposed openstack/neutron: Improve logging for port binding  https://review.openstack.org/27630115:21
*** manuel112 has quit IRC15:21
openstackgerritMerged openstack/neutron-vpnaas: Updated from global requirements  https://review.openstack.org/28504315:22
kevinbentonSam-I-Am: ack, just post a new patch for it on top of mine15:22
*** rkukura has joined #openstack-neutron15:23
*** baoli has quit IRC15:24
*** achanda has joined #openstack-neutron15:24
openstackgerritDavid Shaughnessy proposed openstack/neutron: Added agent specific API support to L2 extensions  https://review.openstack.org/26759115:25
davidshaihrachy: ping, new PS is up.15:25
kevinbentonrossella_s: one of the downsides to logging in bind_port is that an agent not binding a port may be completely normal if you have another driver loaded15:27
kevinbentonrossella_s: left a comment on your patch15:27
*** vikram has joined #openstack-neutron15:27
rossella_skevinbenton, thanks Kevin15:27
*** emagana has joined #openstack-neutron15:28
*** amuller has joined #openstack-neutron15:28
*** singhj has joined #openstack-neutron15:31
Sam-I-Amkevinbenton: thats what i'm doing15:33
*** mubirru has joined #openstack-neutron15:33
*** apuimedo has joined #openstack-neutron15:35
mhickeyihrachys, ZZelle: Hi15:35
openstackgerritabregman proposed openstack/neutron: DO NOT MERGE - Verfying doc gate functionalility  https://review.openstack.org/28484915:36
ZZellemhickey, ave15:36
cappettais there any way to get an instance to show the floatingip via ifconfig or ip a?15:36
mhickeyihrachys, ZZelle: Looking at your comments in https://review.openstack.org/#/c/277558/9/neutron/db/sqlalchemytypes.py15:37
*** wwriverrat has left #openstack-neutron15:37
mhickeyNot sure what to do here.15:38
ZZellemhickey, ihrachys, iiuc, we allow to push invalid information in the db because we do str(value) which allows None, list, dict, integer value15:39
*** baoli has joined #openstack-neutron15:39
mhickeyZZelle: so you are saying with need some checks in this method?15:40
ZZelleimo, it's really strange not to check what we push in the db as db cannot do the check for us15:40
h10_aHi, wondering if anyone has used TAAS before.  I have been trying several different ways to get the service to work for me, but I haven’t yet.  There seems to be an unanswered question that might help me.  https://ask.openstack.org/en/question/84356/taas-any-guide-or-steps-to-implement-tap-as-as-service/  Anyone with experiece here?15:40
ZZellemhickey,  ^15:40
mhickeyZZelle: ok, makes sense. so any data can be persisted in db.15:41
*** baoli_ has joined #openstack-neutron15:41
*** kriskend has joined #openstack-neutron15:41
mhickeyZZelle: let me put in some checks for next PS. sound ok?15:41
*** mubirru has quit IRC15:42
*** abregman|nb is now known as abregman|afk15:42
*** tbachman has joined #openstack-neutron15:43
*** baoli has quit IRC15:44
ZZellemhickey, fine for me15:45
davidshaajo: ping15:46
ajodavidsha, pong, I've seen your patchset, but trying to finish the RPC one15:46
ajoI'll look at it ASAP15:46
ajo(sorry for the delay ;) :)15:47
davidshaajo: thanks, sorry to bother you! I'll put a response to your last comment then, was going to say it here.15:47
mhickeyZZelle: ok, thanks. :)15:48
ajodavidsha, say it, sorry :D15:48
openstackgerritAndreas Scheuring proposed openstack/neutron: macvtap: Macvtap L2 Agent  https://review.openstack.org/27530615:48
davidshaajo: Just on deprecating a way to change the default_cookie. The Idea is that you shouldn't because this is the bridge used by the neutron agent.15:48
ajodavidsha, but I undestood from yamamoto's comments that others can be using it15:49
ajonot the bridge itself15:49
ajobut the class15:49
ajo?15:49
ajoor did I get it wrong15:49
davidshaajo: they can but if they do they couldn't use flows anyways because of flows being deleted.15:50
*** achanda has quit IRC15:51
*** josecastroleon has quit IRC15:51
davidshaajo: So they would need to request a cookie from the api which would also provide them with the bridge to use to create them.15:51
ajodavidsha15:51
ajobut he's talking about separate bridges15:51
ajonot br-int, br-tun ...15:51
ajothey could create 'my-bridge', and do something within15:52
ajowith their own cookie15:52
ajoand be accessing the default_cookie field for that matter15:52
ajoor am I saying a nonsense?15:52
ajoam I a nonsense? :)15:52
ajo%)15:52
davidshaajo: ya, but those wouldn't have the flow deletion problem because they have entirely different flow tables.15:53
ajodavidsha, hmm, yeah, but they could be using that same mechanism to cleanup, couldn't they?15:54
ajo:)15:54
ajoor is the cleanup mechanism outside the bridge class? (I can't remember now)15:54
* ajo 's head is down in a test15:54
*** zhhuabj_ has joined #openstack-neutron15:54
openstackgerritMatthew Kassawara proposed openstack/neutron: Make agent interface plugging utilize network MTU  https://review.openstack.org/28379015:55
davidshaajo: The clean up method is inside the OVSAgentBridge class, they would need to call it themselves15:55
ajoah15:55
ajook15:55
ajodavidsha, can you comment with what we just said15:55
*** busterswt has joined #openstack-neutron15:55
ajo"as per IRC conversation... blah blah" :D15:56
ajoit's good to document this stuff in case somebody comes again asking you for the same nonsense because of me :D15:56
davidshaajo: I'll quote that exactly ;)15:56
ajolol15:56
davidshaajo: sorry for taking your time and good luck with that, is there anything I can do to help?15:56
ajodavidsha, no, but thanks, it's almost done15:57
*** zhhuabj_ has quit IRC15:57
davidshaajo: cool :)15:57
*** zhhuabj_ has joined #openstack-neutron15:57
*** hdaniel has joined #openstack-neutron15:57
openstackgerritNuman Siddique proposed openstack/neutron: Handle PortNotFound exception while creating an ipv6 auto addr subnet  https://review.openstack.org/28538815:58
*** salv-orl_ has joined #openstack-neutron15:59
*** localloo1 has joined #openstack-neutron15:59
*** localloop127 has quit IRC15:59
*** yamahata has joined #openstack-neutron16:00
*** salv-orlando has quit IRC16:01
*** eddima has quit IRC16:05
*** haplo37 has joined #openstack-neutron16:06
*** rpothier has joined #openstack-neutron16:07
*** baoli_ has quit IRC16:08
openstackgerritMartin Hickey proposed openstack/neutron: Port Extra Dhcp Opt to OVO  https://review.openstack.org/27307216:08
openstackgerritMartin Hickey proposed openstack/neutron: Integrate the Extra Dhcp Opt VersionedObject in Neutron  https://review.openstack.org/28539716:08
*** jreeves has joined #openstack-neutron16:11
*** annemccormick has quit IRC16:11
*** vikram has quit IRC16:11
*** anilvenkata has joined #openstack-neutron16:12
mhickeyrossella_s: Hi. First stacking of ovo parch ^^^^^16:12
rossella_smhickey, great16:13
mhickeyrossella_s: I will get to the other patch (address pairs_ asap16:13
*** hdaniel has quit IRC16:13
ihrachysarmax: can we get https://review.openstack.org/#/c/263819/ in?16:13
*** kriskend has quit IRC16:13
electrocucarachamhickey, congrats16:13
*** logan- has quit IRC16:14
armaxihrachys: how much are you prepared to pay?16:14
ajolol :)16:14
rossella_smhickey, cool, thanks a lot16:14
*** logan- has joined #openstack-neutron16:14
ihrachysarmax: I will pay with my loyalty ;)16:14
armaxihrachys: that’s not gonna get you far16:14
armaxihrachys: but I appreciate the sentiment16:14
ihrachysdamn16:14
armax:)16:14
armaxyou know what, I am gonna let you catch a break this time16:15
*** amuller has quit IRC16:16
ihrachysarmax: I knew you will accept my time limited offer. it does not happen every day!16:17
openstackgerritMerged openstack/neutron-specs: Agent specific API for L2 agent extensions  https://review.openstack.org/26381916:17
armaxihrachys: yeah, I had second thoughts…loyalty is most definitely better than any economic rewad16:18
armaxreward16:18
*** abregman|afk has quit IRC16:18
ihrachysarmax: right. economy gives you money; politics gives you money and power16:18
*** kobis has quit IRC16:18
ajorofl, but true.. ;)16:19
armaxihrachys: you sound like you’re a mobster16:19
* armax buckles up for landing16:19
ihrachysarmax: now you indeed appreciate the offer :P16:19
russellbarmax: in flight too, huh?16:19
armaxrussellb: yup16:19
ajohave safe flights guys ;)16:19
russellbthe future is neat16:19
ihrachyshaha16:20
*** skamithi has quit IRC16:21
*** kobis has joined #openstack-neutron16:22
ajoohh ihrachys the server_rpc in callback works like a charm :)16:22
*** skamithi has joined #openstack-neutron16:22
*** dims has quit IRC16:22
ihrachysajo: great.16:22
ajonow, addressing the other things, that alone take me 1h yikes... moving a couple of methods16:22
*** armax has quit IRC16:22
ihrachysajo: how is dscp qos piece? have you looked at it lately? is it good to go?16:22
ajotake me -> took me16:22
ajoihrachys, it probably should review it over tonight or the weekend I can't remember16:23
* ajo looks16:23
ihrachysajo: I haven't looked since eternity16:23
* ihrachys is afraid it's not good16:23
ihrachysbut I better do the review. prolly tomorrow.16:23
*** armax has joined #openstack-neutron16:25
ajoihrachys, : the spec is still there : hmm https://review.openstack.org/#/c/190285/16:25
*** scheuran has quit IRC16:25
ihrachysajo: oh16:27
ihrachysI +2 though we probably did not need the spec16:27
ajohmm16:27
*** hynekm has joined #openstack-neutron16:27
ihrachyswe'll need some driver member like armax to get it in16:27
ajoit seems that we agreed not to need a spec16:27
ajoor even RFE16:27
ajoas per bug conversation.. but the spec was left there16:28
ajoI forgot about it16:28
*** localloo1 has quit IRC16:28
dasmo/16:28
armaxihrachys: how far is the code in the pipeline16:29
kevinbentonihrachys: ping16:29
ihrachysarmax: dscp?16:29
ihrachyskevinbenton: pong16:29
armaxihrachys: you woudln’t want to push your luck too far today, would you not?16:29
*** skamithi has quit IRC16:29
armaxihrachys: :)16:29
armaxihrachys: ya that one16:29
kevinbentonihrachys: i think there is something i don't understand about oslo config deprecation warnings16:29
kevinbentonihrachys: your comment implies that we throw warnings at users even if they aren't using those options if the code references them16:30
ajoarmax, we're checking, they were blocked on the L2 API and the RPC ovo push/pull upgrade support, long ago it was looking good, but we need to recheck16:30
*** localloo1 has joined #openstack-neutron16:30
ihrachysarmax: all blockers are set to merge really quick. now, for the actual dscp patch, I can't tell because honestly I was busy with all its blockers till now. will need to check to say. but the patch is up for review for a while.16:30
*** rcernin has quit IRC16:31
ihrachyskevinbenton: the option access is probably the one that triggers a warning. but let me check the code to be sure.16:31
armaxihrachys: we can merge it but if the code is in bad shape it’ll be pulled out in https://review.openstack.org/#/c/283383/16:31
kevinbentonihrachys: that's terrible if that's the case :/16:31
kevinbentonihrachys: it means there is no way to deprecate an option without spamming operators that don't even use it16:31
*** wwriverrat has joined #openstack-neutron16:32
ihrachyskevinbenton: that's how I read the code: https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L81716:32
*** skamithi has joined #openstack-neutron16:33
ihrachysarmax: I think it's fair16:33
ihrachyskevinbenton: seems like it logs once16:33
*** thorst is now known as thorst_afk16:33
kevinbentonihrachys: ouch, that's unfortunate16:34
ihrachyskevinbenton: but I would need to write a test to check16:34
kevinbentonihrachys: ok. i'll flip all of the code around in my patch16:34
*** armax has quit IRC16:34
ihrachyskevinbenton: right. note that it changes the behavior for those who rely on network_device_mtu, so probably worth a reno16:34
ihrachysit's worth it anyhow..16:34
kevinbentonihrachys: well it will change it if you make me change the order :)16:35
kevinbentonihrachys: maybe the deprecated warning is a little safer than changing behavior to effectively disable network_device_mtu ?16:35
ihrachyskevinbenton: right :) I believe it's the right thing to impose the correct behaviour by default, irrelevant to deprecation warnings question :)16:35
kevinbentonihrachys: i think as long as we have the network_device_mtu we should honor it though16:36
ihrachyskevinbenton: how about avoiding deprecation right now and give ourselves a tiny bit more time to check whether it's safe?16:37
kevinbentonihrachys: safe to set the 'deprecated_for_removal' flag?16:37
ihrachysI would like to play with oslo.config a bit, but probably will need to wait till Mon for that16:37
ihrachyskevinbenton: yes. to validate whether it actually spams as I expect.16:38
ihrachyskevinbenton: so I would say, let's hold the deprecation patch till Mon and I will provide info on actual behaviour then16:38
ihrachysand then we decide where to go16:38
kevinbentonihrachys: i can just test it locally16:38
ihrachysother patches should be unblocked16:38
ihrachyskevinbenton: ok then do :)16:38
*** iyamahat has joined #openstack-neutron16:38
ihrachysI need to run, keep me posted16:38
kevinbentonihrachys: when i make these other changes16:39
*** ihrachys has quit IRC16:39
ajoping davidsha16:39
sc68calSam-I-Am: I found another mtu option! AGENT.veth_mtu16:39
sc68calin ovs agent16:39
sc68calyaaay!16:39
*** amuller has joined #openstack-neutron16:40
Sam-I-Amsc68cal: lols16:40
amullerkevinbenton: I have a question regarding CONF.router_auto_schedule16:40
sc68caljust why16:40
Sam-I-Amwho here was working on the OSC for neutron?16:40
Sam-I-AmHenryG: was it you?16:41
dougwigit is silent as a tomb in the mid-cycle room today.16:41
HenryGSam-I-Am: no it's rtheis16:41
Sam-I-Amdougwig: shhhhh, your typing is disturbing me16:41
*** wwriverrat has left #openstack-neutron16:41
Sam-I-Amrtheis: pssst16:41
dougwigSam-I-Am: go back into your MTU closet.16:41
Sam-I-Amdougwig: but its too small16:41
*** wwriverrat has joined #openstack-neutron16:42
amullerSam-I-Am: Too many jokes, I don't know where to begin16:42
kevinbentonamuller: shoot16:42
sc68caldoude: I keep banging my head on the low doorframe16:42
sc68calerr dougwig16:42
russellblol16:42
amullerkevinbenton: What... Is it for?16:42
amullerkevinbenton: What problem does it solve?16:43
dougwigSam-I-Am: cut yourself in half.16:43
amullerkevinbenton: (I'm asking if we can get rid of it)16:43
dougwigSam-I-Am: it's what the standard says you must do.16:43
*** lajos-katona has left #openstack-neutron16:43
* sc68cal imagines the magic trick where the magicial saws his assistant in half16:43
sc68calgod I can't type. magician16:44
wwriverratblogan: Am I the only one in the openstack-osic channel?  Or… more likely mistyped/forgot/blew-it as the the real neame16:44
kevinbentonamuller: when someone wants to micromanage how things are scheduled because of limited physnet connectivity16:44
kevinbentonamuller: same thing for 'network_auto_schedule'16:45
*** mgoddard__ has joined #openstack-neutron16:45
kevinbentonamuller: whatever their fate, they should probably share it16:45
dougwigkevinbenton: it's all just a scheduling problem.16:46
amullerkevinbenton: I'm not asking why turn it off, I'm saying why turn it on16:46
amullerkevinbenton: routers are scheduled automatically regardless16:46
amullerkevinbenton: having it set to True just adds an additional code flow / complexity and I have no ideas why we need it enabled16:47
amulleridea*16:47
kevinbentonamuller: oh, it would seem that we regressed then and broke this feature anyway :)16:47
*** dslevin has left #openstack-neutron16:48
*** numans has quit IRC16:48
*** kobis has quit IRC16:48
*** fedexo has joined #openstack-neutron16:49
*** mgoddard_ has quit IRC16:49
*** manuel112 has joined #openstack-neutron16:49
amullerkevinbenton: when you add an interface to a legacy router the server automatically schedules the router without checking value of router_auto_schedule16:49
*** yamamoto has quit IRC16:50
*** kobis has joined #openstack-neutron16:50
kevinbentonamuller: auto schedule routers prevents unscheduled routers from being rescheduled16:50
kevinbentonamuller: so if you remove a router from an l3 agent16:50
kevinbentonamuller: it will stay unscheduled until explicitly rescheduled i think with this option16:50
*** yamamoto has joined #openstack-neutron16:50
openstackgerritMartin Hickey proposed openstack/neutron: Update Neutron with temporary registry pattern from VersionedObjectRegistry  https://review.openstack.org/27030916:50
amullerkevinbenton: but HA routers are scheduled when they're created for example16:51
kevinbentonamuller: and what happens when you use the API to remove them from the agent?16:51
amullerkevinbenton: so you'd have to create the router, explicitly remove it from all L3 agents16:51
kevinbentonamuller: does another agent steal it on some periodic sync?16:51
*** rickyrem has quit IRC16:51
amullerkevinbenton: offhand no, with router_auto_schedule off it would not be rescheduled on its own16:51
*** Marga_ has quit IRC16:51
amullerkevinbenton: that's not exactly a sane user experience though16:52
amullerkevinbenton: and I'd have to check but for DVR routers the SNAT portion is probably scheduled right away as well16:52
*** Marga_ has joined #openstack-neutron16:52
kevinbentonamuller: possibly, but this option is about interferring with admins managing where routers are scheduled16:52
kevinbentonamuller: after the fact16:53
kevinbentonamuller: so if we got rid of this, we need to make sure there is still an easy way for admins to move routers16:53
kevinbentonamuller: without fighting the auto scheduling16:53
amullerkevinbenton: agreed16:53
amullerkevinbenton: note that the L3 agent doesn't sync with the server periodically, unless there was an error16:54
*** hdaniel has joined #openstack-neutron16:54
amullerkevinbenton: in fact...16:55
kevinbentonamuller: ah, since the self.fullsync optimization was snuck in...16:55
amullerkevinbenton: fullsync is set to True only if the agent enters the REVIVED state16:55
*** tmorin has quit IRC16:55
kevinbentonamuller: that's a stupid periodic task now :)16:55
hdanielajo: do you mind peeking at :  https://review.openstack.org/#/c/250081/ ?16:55
kevinbentonamuller: we should just have the thing that transitions it to the REVIVED state trigger that sync16:55
kevinbentonamuller: one other use case that this may interfere with is if operators use this to disable a tenants router16:56
Sam-I-Amdougwig: MTU16:56
kevinbentonamuller: tenant doesn't pay bandwidth bill, unschedule their router :)16:56
openstackgerritMerged openstack/neutron: Switch to using in-tree tempest lib  https://review.openstack.org/28491116:57
*** Marga_ has quit IRC16:57
ajohdaniel: checked the diff from my last check, looks good16:57
hdanielajo: hooray :)16:57
*** Marga_ has joined #openstack-neutron16:57
ajokevinbenton, hdaniel's patch is ready for eyeballing of you had any timeslot I believe he addressed your comments16:58
amullerkevinbenton: removing auto_schedule_router wouldn't mess that use case up I think?16:58
*** rickyrem has joined #openstack-neutron16:59
*** manjeets has joined #openstack-neutron17:00
*** claudiub|2 has joined #openstack-neutron17:00
*** mriedem has joined #openstack-neutron17:00
mriedemdougwig: kevinbenton: was this the api job failure? http://logs.openstack.org/35/207635/54/gate/gate-neutron-dsvm-api/424b676/logs/screen-q-svc.txt.gz?level=TRACE#_2016-02-25_03_10_38_57717:01
kevinbentonamuller: unless an l3 agent does a full sync17:01
kevinbentonmriedem: no, they were policy violations17:01
*** Marga_ has quit IRC17:02
mriedemkevinbenton: ok, was just looking at the one job failure that showed up here: http://status.openstack.org/elastic-recheck/data/uncategorized.html17:02
mriedemkevinbenton: is there an example of the policy failure? maybe it's check queue17:02
kevinbentonmriedem: yeah, one sec17:02
*** claudiub has quit IRC17:02
amullerkevinbenton: if the L3 agent does a full sync, with auto_schedule_routers set to False or the code removed, it would not schedule unscheduled routers17:03
amullerkevinbenton: so it would not mess that use case up17:03
mriedem^ still fails a hell of a lot http://goo.gl/Yf5UY217:03
kevinbentonmriedem: http://logs.openstack.org/81/285181/1/check/gate-neutron-dsvm-api/55f9bb2/console.html#_2016-02-26_11_57_08_17217:03
amullermriedem: the fix merged a few minutes ago17:03
ajohdaniel, : https://review.openstack.org/#/c/250081/ not so fast, merge conflict ;)17:03
openstackgerritHaim Daniel proposed openstack/neutron: Qos policy RBAC DB setup and migration  https://review.openstack.org/25008117:04
ajoI guess something-db merged17:04
kevinbentonamuller: oh, so you are advocating that we remove and never automatically schedule a router that isn't scheduled17:04
ajohmm or was something else17:04
amullerkevinbenton: correct17:04
*** vthapar has quit IRC17:04
amullerkevinbenton: yeah sorry if I was unclear, I meant to remove the option and all of its code, essentially defaulting to setting it to False17:04
kevinbentonamuller: ack. that makes sense. the only thing I would want to make sure is safe is the auto scheduling code17:05
kevinbentonamuller: because it unschedules and the scheduled17:05
kevinbentonschedules *17:05
*** hynekm has quit IRC17:05
kevinbentonIIRC17:05
kevinbentonso if the server explodes after one of those it could leave an orphaned router17:06
*** feleouet has quit IRC17:06
kevinbentonamuller: but that should probably be fixed orthoganally anyway if that's still the case17:06
amullerkevinbenton: Like if a router was created, commited, and before the server was able to schedule it, it crashes?17:07
kevinbentonajo: will check it out17:07
amullerkevinbenton: and then it's just never scheduled17:07
kevinbentonamuller: oh, that too17:07
ajothanks kevin17:07
amullerkevinbenton: what did you mean then?17:07
mriedemdougwig: kevinbenton: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22rule%3Acreate_port%20and%20rule%3Acreate_port%3Aport_security_enabled%5C%22%20AND%20message%3A%5C%22PolicyNotAuthorized%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d17:07
amullerkevinbenton: (the thing I just said doesn't work now too though)17:07
mriedemdougwig: kevinbenton: 1 hit in the gate queue17:07
kevinbentonamuller: i meant the auto rescheduling code that will take routers from dead agents and move them17:07
mriedem31 in check17:07
amullerkevinbenton: ohhh17:07
amullerkevinbenton: ah ha17:07
amullerautomatic_rescheduling17:07
mriedemso that's probably why isn't wasn't flaming up the uncategorized bugs page (which only shows gate queue failures)17:08
amullerkevinbenton: yeah it should continue to work17:08
amullerkevinbenton: it has tests17:08
*** jpena has quit IRC17:08
openstackgerritSean M. Collins proposed openstack/neutron: Consolidate the OVS DF and CSUM options into constants  https://review.openstack.org/28544017:08
kevinbentonamuller: yeah, my memory is coming back to me now that this is something that i fixed :)17:08
kevinbentonamuller: but you bring up a good point about the created routers17:09
kevinbentonamuller: we can fix that with maybe a 'pending_schedule' flag17:09
*** jlanoux has quit IRC17:09
*** dims has joined #openstack-neutron17:09
amullerkevinbenton: some of the L3 HA patches could be abandoned if router_auto_schedule didn't exist17:09
openstackgerritDoug Wiegley proposed openstack/neutron: Bump to neutron-lib 0.0.2  https://review.openstack.org/28544117:09
kevinbentonamuller: that's set to true immediately on the create of the record17:09
amullerkevinbenton: yeah17:09
*** achanda has joined #openstack-neutron17:10
*** dims has quit IRC17:10
kevinbentonamuller: but handling a partially formed router is probably something that needs to be more generically fixed anyway17:10
*** Leom has joined #openstack-neutron17:10
kevinbentonamuller: imagine if you pull the plug on a server now right after router db object is created but before L3 HA interfaces17:10
amullerkevinbenton: yep17:10
kevinbentonamuller: ok. if you propose a patch to remove all of that, i'm solf17:10
kevinbentonsold*17:10
amullerkevinbenton: there's probably a lot of places we don't handle multi-commits17:11
kevinbentonamuller: yeah, so i think we probably need some more general transaction log thingy17:11
amullerkevinbenton: or "partial" resources17:11
amullerkevinbenton: yeah17:11
kevinbentonamuller: that shows when something started17:11
*** michchap_ has joined #openstack-neutron17:11
kevinbentonamuller: and that it never finished17:11
amullerkevinbenton: that's what we had on some other project I worked on17:11
amullerkevinbenton: exactly17:11
amullerkevinbenton: that should probably be in oslo.db17:12
amullerkevinbenton: nothing neutron specific here17:12
Sam-I-Amkevinbenton: do my relnotes make sense?17:12
*** jklare_ has joined #openstack-neutron17:12
*** melwitt_ has joined #openstack-neutron17:12
*** pai15- has joined #openstack-neutron17:12
kevinbentonamuller: i think if we massively refactored all of neutron to use taskflow it can handle these multi-task tasks17:12
*** xek__ has joined #openstack-neutron17:13
*** wolverineav has joined #openstack-neutron17:13
*** Kennan2 has joined #openstack-neutron17:13
*** baoli has joined #openstack-neutron17:13
kevinbentonamuller: :)17:13
*** rawlin_ has joined #openstack-neutron17:14
kevinbentonSam-I-Am: haven't had a chance to look yet17:14
*** yamahata__ has joined #openstack-neutron17:14
*** manuel112 has quit IRC17:14
*** tbachman_ has joined #openstack-neutron17:15
*** j_king_ has joined #openstack-neutron17:15
*** Trident has joined #openstack-neutron17:15
*** gbraad_ has joined #openstack-neutron17:15
*** pl0pix has joined #openstack-neutron17:15
*** diegows_ has joined #openstack-neutron17:16
amullerkevinbenton: that'll happen right after the nova scheduler is split out to a separate project, the Neutron stadium replaces the OpenStack big tent and OpenStack releases wrap back from Z17:16
*** tonyb_ has joined #openstack-neutron17:16
*** kfox1111_ has joined #openstack-neutron17:16
*** sshen_ has joined #openstack-neutron17:16
*** Nakato_ has joined #openstack-neutron17:17
*** coreycb` has joined #openstack-neutron17:18
*** dkehn_ is now known as dkehn17:18
*** matrohon has quit IRC17:19
*** kawa2014 has quit IRC17:19
*** fedexo has quit IRC17:19
*** X123_ has joined #openstack-neutron17:19
slaweqajo: hello17:19
openstackgerritHirofumi Ichihara proposed openstack/neutron: Make API framework more flexible for various extensions  https://review.openstack.org/28451917:20
slaweqI found today why linuxbridge agent is not consuming notifications about policy update (in QoS)17:20
*** tbachman has quit IRC17:20
*** edmondsw has quit IRC17:20
*** pavel_bondar has quit IRC17:20
*** Kennan has quit IRC17:20
*** xek_ has quit IRC17:20
*** ekarlso- has quit IRC17:20
*** michchap has quit IRC17:20
*** Nakato has quit IRC17:20
*** anteaya has quit IRC17:20
*** krotscheck has quit IRC17:20
*** isq_ has quit IRC17:20
*** _fortis has quit IRC17:20
*** jklare has quit IRC17:20
*** j_king has quit IRC17:20
*** lucasagomes has quit IRC17:20
*** tonyb has quit IRC17:20
*** blogan has quit IRC17:20
*** sshen has quit IRC17:20
*** gbraad has quit IRC17:20
*** mkoderer__ has quit IRC17:20
*** morgabra has quit IRC17:20
*** plopix has quit IRC17:20
*** strictlyb has quit IRC17:20
*** manjeets has quit IRC17:20
*** otherwiseguy has quit IRC17:20
*** rawlin has quit IRC17:20
*** coreycb has quit IRC17:20
*** afazekas has quit IRC17:20
*** nwonknu has quit IRC17:20
*** pcarver has quit IRC17:20
*** pai15 has quit IRC17:20
*** bapalm has quit IRC17:20
*** Tridde has quit IRC17:20
*** diegows has quit IRC17:20
*** 20WAAACXB has quit IRC17:20
*** melwitt has quit IRC17:20
*** avico has quit IRC17:20
*** X123 has quit IRC17:20
*** lmiccini has quit IRC17:20
*** kfox1111 has quit IRC17:20
*** avico- has joined #openstack-neutron17:20
*** tbachman_ is now known as tbachman17:20
*** krotscheck has joined #openstack-neutron17:20
*** X123_ is now known as X12317:20
slaweqit is in fact bug in CommonAgentLoop class17:20
*** absubram has joined #openstack-neutron17:20
slaweqdiff is rather small: http://pastebin.com/8L8tzN9A17:21
*** afazekas has joined #openstack-neutron17:21
*** adjohn- has joined #openstack-neutron17:21
*** bapalm has joined #openstack-neutron17:21
*** strictlyb has joined #openstack-neutron17:21
*** blogan has joined #openstack-neutron17:21
*** mkoderer___ has joined #openstack-neutron17:21
slaweqquestion: should I fix it in patch with QoS or report new bug on launchpad and make another patch for that?17:21
slaweqprobably this second option but I want to be sure :)17:21
*** absubram_ has joined #openstack-neutron17:21
*** minwang2 has joined #openstack-neutron17:21
*** pcarver has joined #openstack-neutron17:22
*** dims has joined #openstack-neutron17:22
*** otherwiseguy has joined #openstack-neutron17:22
*** morgabra has joined #openstack-neutron17:22
*** lucasagomes_ has joined #openstack-neutron17:22
*** lucasagomes_ is now known as lucasagomes17:23
*** lmiccini has joined #openstack-neutron17:23
openstackgerritSean M. Collins proposed openstack/neutron: [WIP] Deprecate the tunnel_csum option for OVS in favor of autodetection  https://review.openstack.org/28544817:23
*** _fortis_ has joined #openstack-neutron17:23
*** baoli has quit IRC17:24
*** nwonknu has joined #openstack-neutron17:24
*** baoli has joined #openstack-neutron17:24
*** absubram has quit IRC17:25
*** absubram_ is now known as absubram17:25
*** ekarlso- has joined #openstack-neutron17:27
*** edmondsw has joined #openstack-neutron17:27
*** anteaya has joined #openstack-neutron17:28
*** yamamoto has quit IRC17:28
*** yamamoto has joined #openstack-neutron17:28
*** yamamoto has quit IRC17:28
*** pavel_bondar has joined #openstack-neutron17:29
*** cappetta has quit IRC17:30
*** wasmum has joined #openstack-neutron17:30
*** yamamoto has joined #openstack-neutron17:30
*** anshul has joined #openstack-neutron17:31
*** prithiv has quit IRC17:31
sc68calrussellb: mestery: can you think of any reason that someone would *not* want tunnel_csum equal to true if their hardware supports it?17:32
*** baoli has quit IRC17:32
*** tfukushima has left #openstack-neutron17:32
*** tfukushima has quit IRC17:32
sc68caltunnel_csum boils down to the "csum" option being set to true when creating the OVS port17:32
sc68calif I understand correctly17:32
Sam-I-Amsc68cal: does it depend on underlying interface offload?17:32
*** lezbar__ has quit IRC17:33
sc68calI'm not sure. I'm deep down in this thread http://marc.info/?l=linux-netdev&m=143527704810458&w=217:34
*** ranjithd has quit IRC17:34
sc68calwhere they talk about software vs hardware support... I think..17:34
sc68calspecifically this message - http://marc.info/?l=linux-netdev&m=143528746114050&w=217:34
sc68caland this17:35
sc68calhttp://marc.info/?l=linux-netdev&m=143529575915353&w=217:35
sc68calso I'm at the edge of my knowledge on this and could use expert opinion17:35
*** _fortis_ is now known as _fortis17:35
*** slaweq has quit IRC17:35
*** ranjithd has joined #openstack-neutron17:36
Sam-I-Ami think this is one of those cases where the operator needs to understand what the csum option does in combination with their specific kernel and nics17:37
sc68calyeah. Taking a look at this perf result now - http://marc.info/?l=linux-netdev&m=143534714030223&w=217:39
*** shashank_hegde has joined #openstack-neutron17:42
*** madhu_ak has joined #openstack-neutron17:43
Sam-I-Amthis is also not OVS?17:43
*** ranjithd has quit IRC17:44
openstackgerritSean M. Collins proposed openstack/neutron: [WIP] Deprecate the tunnel_csum option for OVS in favor of autodetection  https://review.openstack.org/28544817:44
openstackgerritHenry Gessau proposed openstack/neutron-vpnaas: Track alembic heads  https://review.openstack.org/28546017:45
sc68calah - found my mailing list thread where I ranted about this17:46
sc68calnow linked in commit message - yaay17:46
*** Aish has joined #openstack-neutron17:47
*** eil397 has joined #openstack-neutron17:48
*** Leom has quit IRC17:48
*** eil397 has left #openstack-neutron17:49
*** jistr has quit IRC17:49
*** slaweq has joined #openstack-neutron17:50
anteayamhickey: http://docs.openstack.org/infra/zuul/gating.html17:52
openstackgerritHynek Mlnarik proposed openstack/neutron: Use cookies consistently in flows of all bridges  https://review.openstack.org/28463917:54
*** manjeets_ has joined #openstack-neutron17:56
openstackgerritHenry Gessau proposed openstack/neutron-fwaas: Track alembic heads  https://review.openstack.org/28546817:57
*** abregman has joined #openstack-neutron17:58
*** slaweq has quit IRC18:00
*** mriedem has left #openstack-neutron18:01
openstackgerritManjeet Singh Bhatia proposed openstack/python-neutronclient: Add commands for Network IP Availability  https://review.openstack.org/26992618:02
openstackgerritHenry Gessau proposed openstack/neutron: Remove effectively empty directories  https://review.openstack.org/28547218:03
*** manjeets has joined #openstack-neutron18:04
*** manjeets_ has quit IRC18:04
*** abregman is now known as abregman|afk18:06
openstackgerritAssaf Muller proposed openstack/neutron: WIP: Remove auto_schedule_routers code and option  https://review.openstack.org/28548018:08
*** amuller is now known as amuller_afk18:08
*** dims is now known as dimsum__18:09
*** banix has quit IRC18:10
*** Marga_ has joined #openstack-neutron18:10
*** RichardRaseley has joined #openstack-neutron18:11
*** ijw has joined #openstack-neutron18:11
*** Marga__ has joined #openstack-neutron18:11
*** Marga__ has quit IRC18:12
*** yamamoto has quit IRC18:12
*** rtheis has quit IRC18:12
*** yamamoto has joined #openstack-neutron18:12
*** yamamoto has quit IRC18:12
*** Marga_ has quit IRC18:12
*** yamamoto has joined #openstack-neutron18:13
*** Marga_ has joined #openstack-neutron18:13
*** Marga_ has quit IRC18:13
*** ijw has quit IRC18:14
*** ijw has joined #openstack-neutron18:14
*** Marga_ has joined #openstack-neutron18:14
*** sambetts is now known as sambetts|afk18:16
*** evgenyf has joined #openstack-neutron18:17
*** mgoddard__ has quit IRC18:17
*** mgoddard has joined #openstack-neutron18:17
openstackgerritCarl Baldwin proposed openstack/neutron: Make network segment table available for standalone plugin  https://review.openstack.org/24239318:20
*** gangil has joined #openstack-neutron18:21
*** gangil has quit IRC18:21
*** gangil has joined #openstack-neutron18:21
*** thorst_afk is now known as thorst_18:23
davidshaHey, is anyone around that could answer a quick question on object versioning?18:28
*** shashank_hegde has quit IRC18:29
mhickeyanteaya: Thanks! :)18:30
*** jreeves has quit IRC18:30
mhickeydavidsha: Hey. Wahts the question?18:30
*** bjornar__ has joined #openstack-neutron18:30
mhickey*Whats18:31
davidshaI'm incrementing a versioned object, I'm just wondering is there a class I need to override to make it decrement if the new version isn't supported18:33
davidshaI'm working off this example: https://github.com/openstack/oslo.versionedobjects/blob/e6c275a3fee177afa0ec734e9b52d0e2e637c6dc/oslo_versionedobjects/tests/test_objects.py#L11418:33
*** tiswanso has quit IRC18:33
*** Aish has quit IRC18:33
davidshaclass -> method*18:33
*** tiswanso has joined #openstack-neutron18:34
*** wolverineav has quit IRC18:34
davidshamhickey: ^18:34
*** manuel112 has joined #openstack-neutron18:34
*** armax has joined #openstack-neutron18:35
kevinbentonhdaniel: ping18:36
mhickeydavidsha: not sure. maybe ask rlrossit on oslo channel?18:36
hdanielkevinbenton: pong18:36
hdanielkevinbenton: sup18:36
davidshamhickey: ack, thanks!18:36
mhickeydavidsha: np18:36
kevinbentonhdaniel: oh, nevermind. i had a question about some code in your patch but i see the reason now18:36
kevinbentonhdaniel: :)18:36
hdanielkevinbenton: sure thing ;)18:37
kevinbentonhdaniel: was wondering why you were using itertools.chain.from_iterable in _get_tenants_with_shared_access_to_db18:37
hdanielkevinbenton: I guess you figured that18:37
kevinbentonhdaniel: yeah, each row needs to be iterated over18:38
kevinbentonhdaniel: to get the one value18:38
kevinbentonhdaniel: it's the equivalent of set(r[0] for r in context.session.query...) right?18:38
hdanielhdaniel: yeah18:39
kevinbentonhdaniel: k18:39
hdanielkevinbenton: I guess that ugly itertools.chain thing could be replaced18:40
kevinbentonhdaniel: it's fine18:40
kevinbentonhdaniel: just wanted to make sure i understood what it was doing18:40
kevinbentonhdaniel: not worth another respin for that18:40
hdanielkevinbenton: cool.18:40
*** abhiraut has joined #openstack-neutron18:44
*** mickeys has joined #openstack-neutron18:44
*** jlibosva has quit IRC18:44
*** Aish has joined #openstack-neutron18:45
*** s3wong has joined #openstack-neutron18:49
*** absubram has quit IRC18:50
*** achanda has quit IRC18:51
*** abhiraut has quit IRC18:51
*** manuel112 has quit IRC18:53
*** abhiraut has joined #openstack-neutron18:53
*** manuel112 has joined #openstack-neutron18:54
*** achanda has joined #openstack-neutron18:55
*** agireud has quit IRC18:55
openstackgerritKevin Benton proposed openstack/neutron: Deprecate network_device_mtu  https://review.openstack.org/28379818:56
*** wolverineav has joined #openstack-neutron18:56
*** agireud has joined #openstack-neutron18:57
*** wolverineav has quit IRC18:57
*** wolverineav has joined #openstack-neutron18:57
*** rossella_s has quit IRC18:58
*** rossella_s has joined #openstack-neutron18:58
*** john-davidge has joined #openstack-neutron18:58
openstackgerritKevin Benton proposed openstack/neutron: Override addOnException to catch exceptions  https://review.openstack.org/28334018:59
*** vhosakot has joined #openstack-neutron19:01
*** john-davidge_ has joined #openstack-neutron19:02
*** banix has joined #openstack-neutron19:02
openstackgerritKevin Benton proposed openstack/neutron: Collect details on ARP spoof functional failures  https://review.openstack.org/28518119:03
*** john-davidge has quit IRC19:04
*** john-davidge_ is now known as john-davidge19:04
*** permalac has joined #openstack-neutron19:05
*** RichardRaseley has quit IRC19:05
*** neiljerram has quit IRC19:05
*** manjeets has left #openstack-neutron19:06
*** jwarendt has joined #openstack-neutron19:06
*** sdague has quit IRC19:06
*** john-davidge_ has joined #openstack-neutron19:11
russellbsc68cal: not that i know of19:12
*** john-davidge has quit IRC19:13
*** john-davidge_ is now known as john-davidge19:13
*** ZZelle_ has joined #openstack-neutron19:13
*** manuel112 has quit IRC19:14
*** manuel112 has joined #openstack-neutron19:14
*** melwitt_ is now known as melwitt19:14
*** wasmum has quit IRC19:15
*** baoli has joined #openstack-neutron19:15
*** afaranha has left #openstack-neutron19:16
*** dimsum__ has quit IRC19:16
*** wolverineav has quit IRC19:18
*** sridhar_ram has joined #openstack-neutron19:19
*** wolverineav has joined #openstack-neutron19:19
*** ivar-lazzaro has joined #openstack-neutron19:19
*** sbalukoff has quit IRC19:22
*** baoli has quit IRC19:22
*** baoli has joined #openstack-neutron19:23
*** wasmum has joined #openstack-neutron19:26
*** anshul has quit IRC19:26
*** ritesh has joined #openstack-neutron19:28
*** baoli has quit IRC19:28
*** baoli has joined #openstack-neutron19:28
*** skamithi14 has joined #openstack-neutron19:29
*** rickyrem has quit IRC19:29
*** hdaniel has quit IRC19:31
*** skamithi13 has quit IRC19:32
*** manuel112 has quit IRC19:33
*** baoli has quit IRC19:33
*** manuel112 has joined #openstack-neutron19:34
*** abhiraut has quit IRC19:35
*** vhosakot has quit IRC19:37
*** abhiraut has joined #openstack-neutron19:37
*** manuel112 has quit IRC19:38
*** porunov has joined #openstack-neutron19:38
*** vhosakot has joined #openstack-neutron19:39
*** emagana has quit IRC19:40
*** rickyrem has joined #openstack-neutron19:41
*** emagana has joined #openstack-neutron19:42
*** emagana has quit IRC19:44
*** emagana has joined #openstack-neutron19:44
*** rickyrem has quit IRC19:47
porunovHello everyone! I am trying install neutron like in documentation but have some troubles with understanding. What is local_ip = OVERLAY_INTERFACE_IP_ADDRESS? We have this parameter in /etc/neutron/plugins/ml2/linuxbridge_agent.ini in [vxlan] section. Which IP adress I need to wrtie insted of OVERLAY_INTERFACE_IP_ADDRESS? Is it ip address of public interface of machine where we configure this parameter?19:48
*** erhudy has joined #openstack-neutron19:48
kevinbentonporunov: it's the IP of your compute node that it will use to tunnel traffic to the other compute nodes19:49
kevinbentonporunov: so use the IP that allows it to communicate with other compute nodes19:49
porunovI have only one compute node. It's ip: 192.168.56.131. So I have to write: local_ip = 192.168.56.131 in compute and controller nodes?19:51
kevinbentonrussellb: hola19:53
*** hdaniel has joined #openstack-neutron19:53
*** absubram has joined #openstack-neutron19:53
kevinbentonporunov: no, local_ip is just the IP address of the node itself19:53
sc68calporunov: which documentation is this? can you provide a link? It probably needs some work to clarify19:53
kevinbentonporunov: so on the compute node it will be the compute nodes ip19:53
kevinbentonporunov: on the network nodes, it will be their IPs they use to communicate with the compute node19:53
porunovsc68cal: http://docs.openstack.org/liberty/install-guide-rdo/neutron-controller-install-option2.html19:54
porunovkevinbenton: Thank you)19:55
*** ranjithd has joined #openstack-neutron19:56
kevinbentonporunov: no prob19:57
*** hdaniel has quit IRC19:57
*** baoli has joined #openstack-neutron19:58
*** amuller_afk is now known as amuller19:58
*** anilvenkata has quit IRC19:58
openstackgerritEvgeny Fedoruk proposed openstack/python-neutronclient: L7 capability implementation for lbaas v2  https://review.openstack.org/21727620:00
*** gangil has quit IRC20:00
davidshanjohnston: ping20:03
njohnstondavidsha: pong20:03
davidshanjohnston: hey, you've seen ajo's comments have you?20:03
*** baoli has quit IRC20:03
njohnstondavidsha: Yep.  Would you like me to take a whack at them?20:04
davidshanjohnston: they were put on PS8 but we never put versioning on the QosPolicy class. I think I have it just don't know how to test.20:04
njohnstondavidsha: Are you specifically speaking of `neutron/objects/qos/rule.py Line 91: you need to bump the policy version, and add a method to handle downgrades, removing any QosDscpMarkRule`20:05
*** baoli has joined #openstack-neutron20:05
*** h10_a has left #openstack-neutron20:06
*** kbringard has quit IRC20:06
davidshanjohnston: that's the one, was reading the example code and just made it remove dscp_marking_rule from field['rules'] if the version was '1.0'20:07
*** kbringard has joined #openstack-neutron20:07
*** gangil has joined #openstack-neutron20:07
*** gangil has quit IRC20:07
*** gangil has joined #openstack-neutron20:07
*** pl0pix has quit IRC20:07
*** plopix has joined #openstack-neutron20:08
njohnstonRight.  It seems you can probably test the behavior by having a multinode setup containing a neutron server with a new agent attached, do something DSCP, then downgrade the agent, and try to do DSCP operations.20:09
*** gangil has quit IRC20:09
*** itisha has quit IRC20:09
*** safchain has joined #openstack-neutron20:10
davidshanjohnston: was looking more into unit tests at the moment, (I could also kill the q-agt manually change the version to 1.0 and try again)20:10
njohnstonUnless you mean 'how to functional/unit/fullstack test', which is hard.  I think fullstack would be the logical place, but I don't have the requisite skill yet - still learning in the fullstack testing area.  But fundamentally you're relying on Ajo's RPC rolling upgrades code and the underlying OVO code to work as expected.20:10
njohnstonYeah, this isn't really an arena for unit testing, I think.20:11
*** johnbelamaric has quit IRC20:11
*** baoli has quit IRC20:11
*** sdague has joined #openstack-neutron20:13
*** yamamoto has quit IRC20:13
*** yamamoto has joined #openstack-neutron20:13
*** yamamoto has quit IRC20:13
davidshanjohnston: Hmmmm... I'll keep at it, think I have the basis of how to test it... just don't think people are going to like it that much (manually changing VERSION and calling the version check)....20:14
njohnstondavidsha: Do you think testing that adds value?20:14
*** javeriak has joined #openstack-neutron20:15
davidshanjohnston: I think testing it will let me know if I made a mess of it ;)20:15
njohnstondavidsha: Then let's roll with it, and come what may!20:15
davidshanjohnston: kk, I'll go through the rest of it and pull out whatever comments we left in.20:16
*** javeriak has quit IRC20:16
*** javeriak has joined #openstack-neutron20:16
njohnstondavidsha: Excellent.  I'll read more about fullstack tests in the meantime, perhaps we can have a follow-on patch with a more holistic testing approach.20:17
*** baoli has joined #openstack-neutron20:18
davidshanjohnston: ack, I'll try and have this up within the hour.20:18
njohnstondavidsha: Thanks!  I know it's getting late there.20:18
ajohi :)20:18
ajonjohnston, ^what do you mean about functional/unit/fullstack?20:19
davidshaajo: hey, for Versioning.20:19
ajohmm, no, I mean you have to take neutron/objects/qos/policy.py20:20
*** alejandrito has joined #openstack-neutron20:20
ajoand in the QosPolicy bump the version to 1.120:20
*** javeriak_ has joined #openstack-neutron20:21
*** javeriak has quit IRC20:21
ajothen add a method like: https://github.com/openstack/oslo.versionedobjects/blob/e6c275a3fee177afa0ec734e9b52d0e2e637c6dc/oslo_versionedobjects/tests/test_objects.py#L11420:22
davidshaajo: ya I've done that, was just doing the function for removing dscp_marking_rule if it's version 1.020:22
ajoto remove DSCP rules20:22
ajoyeah20:22
ajocorrect20:22
davidshaajo: just adding tests to make sure it works! :)20:22
ajoawesome20:22
*** slaweq has joined #openstack-neutron20:22
*** yarkot_ has joined #openstack-neutron20:22
*** johnbelamaric has joined #openstack-neutron20:23
ajodavidsha, and may be we need to ask the remaining rules to downgrade to 1.0 too20:23
ajodavidsha, because otherwise the older agent won't know how to deserialize a 1.1 rule20:23
ajoeven though for the bandwidthlimit rule it'd be the same20:24
ajoin fact I'm not sure if you need to bump QoSRule or not by having a different subclass20:24
davidshaajo: when we added DSCP it changed the hash for QosRule so we bumped the version20:25
ajoaha20:25
ajook20:26
*** yarkot_ has quit IRC20:26
ajowe will check with ihar20:26
ajohttps://github.com/openstack/oslo.versionedobjects/blob/e6c275a3fee177afa0ec734e9b52d0e2e637c6dc/doc/source/usage.rst20:26
ajooh at least now oslo versioned objects has some doc now20:26
davidshaajo: Will I add a similar method for QosRule then?20:27
openstackgerritDoug Wiegley proposed openstack/neutron: Bump to neutron-lib 0.0.2  https://review.openstack.org/28544120:27
*** sbalukoff has joined #openstack-neutron20:28
ajodavidsha, I'm not sure how that method would work exactly20:28
*** baoli has quit IRC20:28
ajodavidsha, for QoSRule itself... I believe it's something to be left to the childs, the top class knows nothing20:29
ajodavidsha, may be there's something related to subclasses and the downgrade method in the ovo's lib testing20:29
ajoI need to dig back into my rpc patch20:29
davidshaajo: Is it the QosPolicy we need to be doing this to? I don't think the QosPolicy is aware of the rule types and it didn't need to be upgraded when we made the other changes.20:30
davidshajust in regards to the hash values at least.20:30
openstackgerritKevin Benton proposed openstack/neutron: Deprecate 'ovs_use_veth' and 'veth_mtu' options  https://review.openstack.org/28553220:30
openstackgerritKevin Benton proposed openstack/neutron: Remove deprecated veth options from OVS  https://review.openstack.org/28553320:30
ajodavidsha, yeah, but we will call the obj_make_compat thing20:30
*** abhiraut has quit IRC20:31
ajowe need it :) trust me20:31
*** baoli has joined #openstack-neutron20:31
ajodavidsha, make sure that when you downgrade it to 1.0, will have no DSCP rules, and the remaining Bandwidth rules are 1.020:31
openstackgerritEmilien Macchi proposed openstack/neutron-fwaas: add tempest-lib to test-requirements  https://review.openstack.org/28553420:32
davidshaajo: kk, but I don't think versioning out dscp needs to be done in QosPolicy, I think it might be in QosRule.20:32
ajodavidsha, yeah, but, think what happens to a QoSRule (DSCP) if you try to downgrade ?20:33
ajoand btw, our push/pull mechanism will call to downgrade on the QoSPolicy,20:33
ajonot on the rules themselves20:33
ajoso we need to make the QoSPolicy responsible for downgrading20:33
davidshaajo: kk20:34
*** baoli has quit IRC20:37
*** madhu_ak has quit IRC20:37
amullerkevinbenton: I'm just finding more and more code to remove... It's not ending20:38
slaweqajo: hello20:38
ajohi slaweq20:39
slaweqI just opened but on launchpad: https://bugs.launchpad.net/neutron/+bug/155051420:39
openstackLaunchpad bug 1550514 in neutron "L2 agents are not subscribing properly to push notifications queues" [Undecided,New] - Assigned to Slawek Kaplonski (slaweq)20:39
Sam-I-Ammhickey: http://t.qkme.me/3py8mt.jpg20:39
Sam-I-Ammhickey: that about describes america20:39
slaweqI think it will be better to fix it in separate patch, not to do it together with QoS for LB20:39
slaweqyes?20:39
kevinbentonamuller: yay!20:40
kevinbentonamuller: getting rid of those will really clean up the agents20:40
ajoslaweq, aha, you may need to patch somehow the CommonAgentLoop to let you do that20:40
slaweqyes, I already have such patch :)20:41
ajoslaweq: ahh, ok :)20:41
slaweqand it's working20:41
ajogood20:41
amullerkevinbenton: right now I'm only removing code from the scheduling layer in the server, and some DB methods20:41
amullerkevinbenton: and a ton of tests20:41
ajoslaweq, can I rephrase the title of your bug a bit?20:41
slaweqbut I will push it as another patch because it is not related to QoS IMHO20:41
slaweqyes, sure20:41
amullerkevinbenton: I need some tool that shows unused methods. I need a static language.20:41
slaweqI always have problem with writing such things :)20:41
amullerkevinbenton: maybe pylint has this if I remove some exceptions20:42
kevinbentonamuller: don't you think we'll have to deprecate and then remove in newton?20:43
ajoslaweq, done, so reference the bug from your patch, probably you didn't need a bug20:43
ajobut it's good for explaining if somebody asks why are you changing it :)20:43
openstackgerritDoug Wiegley proposed openstack/neutron: Bump to neutron-lib 0.0.2  https://review.openstack.org/28544120:43
amullerkevinbenton: I personally don't think so. The use case of having the option set to True makes no sense, I can't imagine anyone wants this.20:43
slaweqok, so I can add info in commit message that it will close this bug also and it will be fine?20:43
kevinbentonamuller: ok20:44
* ajo fills up the glass with Coke20:44
*** achanda has quit IRC20:45
*** apuimedo has quit IRC20:45
kevinbentonamuller: you're supposed to be reviewing the ALLOCATING patch ;)20:45
amullerkevinbenton: aye20:46
amullerkevinbenton: so, I was thinking about it20:46
kevinbentonamuller: actually, while i have you and ajo around, do you think it's finally safe to deprecate these? https://bugs.launchpad.net/neutron/+bug/155050120:46
openstackLaunchpad bug 1550501 in neutron "the 'ovs_use_veth' and 'veth_mtu' options should be deprecated" [Undecided,In progress] - Assigned to Kevin Benton (kevinbenton)20:46
amullerkevinbenton: I commented on the bug, I think it's safe to remove without a deprecation cycle20:46
ajokevinbenton, : reading20:46
amullerkevinbenton: About the ALLOCATING patch, if we remove auto_schedule_routers, is there a scenario where an agent receives a notification about an HA router without an HA interface?20:47
ajokevinbenton, what was ovs_use_veth for, the patch ports ?20:47
*** abhiraut has joined #openstack-neutron20:47
amullerajo: it was instead of OVS patch ports20:47
*** madhu_ak has joined #openstack-neutron20:47
ajooh,20:47
ajocan we leave those?20:47
ajoI suspect I'm going to need that option for QoS, sadly20:47
ajopatch ports don't allow QoS queue attachment, because they are not a linux kernel primitive device :(20:48
ajoand those ports are the best port to do min bandwidth guarantees (eventually)20:48
kevinbentonajo: :'(20:48
*** manjeets has joined #openstack-neutron20:48
ajoyeah :(20:48
*** dims has joined #openstack-neutron20:48
amullerajo: so you need veth pairs?20:48
amullerajo: between what bridges?20:48
manjeets?join ##osic-neutron20:48
ajoamuller, yes, optionally if anybody wants min bandwidth guarantees they will need to use veths20:49
ajoat performance expense...20:49
ajois a tradeoff :/20:49
amullerajo: so the API will depend on a configuration option in the OVS agent being enabled?20:49
amullerajo: something smells here20:49
amullerajo: will the API check the OVS agents configurations dict?20:49
ajoamuller, we definitely will need to20:50
amullerajo: how will you handle upgrades?20:50
ajoamuller, we send the agent config info in state reports20:50
kevinbentonamuller: so if we remove auto_schedule_routers we still have to worry about the update case20:50
ajoamuller, : carefully20:50
amullerhehe20:50
ajo':D20:50
ajoamuller, I haven't been able to think about that20:50
ajosec, kid crying..20:50
*** eddima has joined #openstack-neutron20:50
*** arosen12 has joined #openstack-neutron20:51
*** eddima has quit IRC20:51
kevinbentonamuller: however, i was thinking about it and since we are filtering before routers go out to the agent anyway, i can just adjust the filter to not send any routers in the 'ha' state that don't have 'ha interface' key set20:51
anteayakevinbenton mhickey http://www.eatmacs.com/menu/211387020:51
kevinbentonamuller: and then we don't need the new status20:51
kevinbentonamuller: what do you think? The patch would become drastically simpler20:52
kevinbentonamuller: with no state transitions20:52
amullerkevinbenton: I need to think about what you said about the update case, sec20:53
*** claudiub has joined #openstack-neutron20:53
*** absubram has quit IRC20:54
*** gangil has joined #openstack-neutron20:55
*** gangil has quit IRC20:55
*** gangil has joined #openstack-neutron20:55
*** abregman|afk has quit IRC20:55
*** manjeets has left #openstack-neutron20:55
amullerkevinbenton: can you highlight the race in update_router without auto_schedule_routers in the mix?20:56
*** dave-mccowan has quit IRC20:56
kevinbentonamuller: an agent can host both an L3 legacy router and an HA router, right?20:56
amullerkevinbenton: yes20:56
amullerkevinbenton: people actually do that20:56
kevinbentonamuller: issue two updates to the router20:57
*** claudiub|2 has quit IRC20:57
kevinbentonamuller: second converts to ha20:57
kevinbentonamuller: first triggers it to poll the server20:57
kevinbentonamuller: when l3 agent polls the server, the type has been set to HA20:57
kevinbentonamuller: but the interfaces haven't been created yet20:57
amullerkevinbenton: k20:57
amullerkevinbenton: you're right20:57
* amuller is thinking20:58
mhickeySam-I-Am, anteaya: thanks20:58
anteayaawesome20:59
*** manjeets has joined #openstack-neutron21:00
amullerkevinbenton: I think that an update_router that doesn't change the HA flag doesn't notify agents21:00
ajokevinbenton, if you feel in the mood of cleanups, may be end up the use_ipsets for the iptablesfirewalldriver ?21:00
ajodefault to true, and kill the rule expansions in if branches ?21:01
ajo:)21:01
ajoO:)21:01
ajoor.. just mark it deprecated for now21:01
kevinbentonajo: that might work :)21:01
kevinbentonamuller: but what updates do notify agents?21:01
*** ivar-lazzaro has quit IRC21:02
kevinbentonamuller: how about a router-gateway set?21:02
kevinbentonamuller: or an interface add21:02
amullerkevinbenton: yes21:02
amullerkevinbenton: those 221:02
kevinbentonamuller: right, so either of those could trigger it21:02
kevinbentonamuller: there is also the basic bad timing case of the agent starting up right while routers are being converted21:02
kevinbentonamuller: or it reconnects to oslo messaging21:02
openstackgerritMerged openstack/neutron: Add use_default_subnetpool to subnet create requests  https://review.openstack.org/28202121:02
*** absubram has joined #openstack-neutron21:07
*** skamithi14 has quit IRC21:11
*** skamithi13 has joined #openstack-neutron21:11
kevinbentonamuller: what do you think?21:12
*** yarkot_ has joined #openstack-neutron21:13
*** rickyrem has joined #openstack-neutron21:13
*** yamamoto has joined #openstack-neutron21:14
amullerkevinbenton: the ALLOCATING status is more future-proof21:14
amullerkevinbenton: if we add additional resources to an HA router, but it's unlikely21:14
amullerkevinbenton: how significant is the complexity difference?21:14
kevinbentonamuller: let me propose a separate patch for you to look at21:15
amullerkevinbenton: that would be ideal :)21:15
amullerkevinbenton++21:15
kevinbentonamuller: even if we add more resources to an HA router, we would just update the filter instead of the status changing logic, but i see what you mean21:15
amullerkevinbenton: you'd have to remember to do that21:15
amullerkevinbenton: and we don't really have a test for this21:15
*** alejandrito has quit IRC21:16
kevinbentonamuller: right21:16
kevinbentonamuller: ok, give me a few. how much longer are you on for today?21:16
amullerkevinbenton: if the complexity difference is significant, considering the scenario I'm talking about is not likely, I'm OK with just filtering on the existence of an HA port21:17
amullerkevinbenton: dunno, few hours21:17
kevinbentonamuller: ok, just wanted to make sure it wasn't in the next couple of minutes :)21:17
davidshaajo: ok, it's done for the QosPolicy (it steps through the rules and deletes any that are not bandwidth limit rules), what would I need to do for the QosRules then?21:18
amullerkevinbenton: no no21:19
*** javeriak_ has quit IRC21:19
*** yamamoto has quit IRC21:19
ajodavidsha, I'm not completely sure, we may need to discuss with ihar, but I'd say:21:19
ajoprovide a downgrade method on each rule type (DSCP/Bandwidth)21:20
ajoDSCP just throws an exception if you try to downgrade 1.1 to 1.021:20
ajoBandwidth limit rule, just does nothing  ? :)21:20
ajodavidsha, it's a bit weird with the subclasses, look at the oslo versionedobjects tests, and see if there's something like that related to subclasses21:21
ajoor look for the authors of that "stuff" and ask, or alternatively read the oslo versioned objects subclasses code...21:21
*** baoli has joined #openstack-neutron21:21
davidshaajo: kk.21:21
ajodavidsha: https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/tests/test_objects.py#L16521:22
ajoI wonder what that child_versions is for21:22
davidshaajo: VERSION is a static variable across all QosRule objects is it?21:22
*** evgenyf has quit IRC21:23
openstackgerritAssaf Muller proposed openstack/neutron: WIP: Remove auto_schedule_routers code and option  https://review.openstack.org/28548021:23
ajodavidsha, I wonder if we can have QoSBandwidthRule 1.0 and the DSCP 1.0, but QoSRule is 1.121:23
ajoI'm a bit new on that, sorry21:23
mlavallecarl_baldwin: ping21:23
ajoyou need to investigate :)21:23
carl_baldwinmlavalle: pong!21:23
*** john-davidge has quit IRC21:24
*** ritesh_ has joined #openstack-neutron21:24
*** tiswanso has quit IRC21:24
*** claudiub|2 has joined #openstack-neutron21:25
mlavallecarl_baldwin: I finished my first version of the segemtns host mapping. I wanted to push now, but your patchset needs to be rebased. SO, since I am not exactly an expert on this (as you might remember) and I have to leave in 10 minutes, I'll do the rebasing slowly when I get home21:25
*** tiswanso has joined #openstack-neutron21:25
carl_baldwinmlavalle: Let me take a look...21:25
mlavallecarl_baldwin: I don't want to mess up your patchset21:25
carl_baldwinmlavalle: Why does mine need to be rebased?21:26
Sam-I-Amaight folks, time to airporterize21:26
Sam-I-Amwas a fun mid-cycle21:26
mlavallecarl_baldwin: well, gerrit says it's in conflict wuth 3 patchsets21:27
carl_baldwinSam-I-Am: Safe travels.  I'll watch for your plane flying overhead.21:27
Sam-I-Amhaha... i'll wave.21:27
njohnstonajo: That is the way the tests look: https://review.openstack.org/#/c/251738/27/neutron/tests/unit/objects/test_objects.py21:27
openstackgerritSlawek Kaplonski proposed openstack/neutron: Add support for QoS for LinuxBridge agent  https://review.openstack.org/23621021:27
carl_baldwinmlavalle: That just means that 3 other patch sets in flight will conflict if they all try to merge.21:27
openstackgerritMerged openstack/neutron: Prevent binding IPv6 addresses to Neutron interfaces  https://review.openstack.org/26837321:28
*** claudiub has quit IRC21:28
ajonjohnston, ahaa21:28
carl_baldwinmlavalle: If it truly needs a rebase, it will say in bold red letters something like "Merge conflict"21:28
ajook, njohnston , davidsha, may be you don't need to provide anything on QoSRuleType then21:28
*** absubram has quit IRC21:28
njohnstonajo: I had to add that to get the DSCP tests to work, which taught me a lot21:29
mlavallecarl_baldwin: ok, then I'll try to push slowly when I get home. I got an error in git review. Time to leave for Minneapolis. Have a nice weekend!21:29
*** baoli has quit IRC21:29
*** claudiub has joined #openstack-neutron21:29
*** yarkot_ has quit IRC21:29
carl_baldwinmlavalle: Safe travels for you too!21:29
ajook, njohnston , davidsha, may be you don't need to provide anything on QoSRuleType then, just try to downgrade it to 1.0 and let's see, may be you need to go from the QoSpolicy on the downgrade loop and ask the rules to get downgraded too (the survivor rules)21:29
ajonjohnston, thanks :)21:30
njohnstonajo: Happy to help!21:30
*** claudiub|2 has quit IRC21:31
carl_baldwinFor everyone getting ready to travel from the Rochester meetup, safe travels!  It was a great meetup!21:33
openstackgerritMerged openstack/neutron: Allow address pairs to be cleared with None  https://review.openstack.org/27301821:33
*** vhosakot has quit IRC21:34
openstackgerritMiguel Lavalle proposed openstack/neutron: [WIP] Basic extension and CRUD for Segments  https://review.openstack.org/28444021:35
openstackgerritMiguel Lavalle proposed openstack/neutron: Add segments to hosts mappings for Routed Networks  https://review.openstack.org/28554821:35
davidshaajo: Ok so just waterfall the new version to the rules I don't delete?21:35
openstackgerritMartin Hickey proposed openstack/neutron: Add custom SQLAlchemy type for IP addresses  https://review.openstack.org/27755821:35
*** vhoward has quit IRC21:36
*** zhhuabj_ has quit IRC21:36
mlavallecarl_baldwin: I pushed: https://review.openstack.org/#/c/28554821:37
carl_baldwinmlavalle: Cool.21:37
mlavallecarl_baldwin: did di it wrong, though? Please look at your patchset21:37
* carl_baldwin looking...21:37
ajodavidsha, I'd guess that,21:38
davidshaajo, njohnston: wait do we need to version change the QosRules? I assume if the version isn't supported then they can't be created so once they are deleted from the policy it should be ok... right?21:38
ajowe will have to review and check21:38
ajodavidsha, they can't contain '1.1', or old agent's won't be able to deserialize21:38
njohnstonajo: You mean QosRuleType?21:39
davidshanjohnston: yeah QosRuleType, sorry!21:39
ajoyeah21:39
carl_baldwinmlavalle: You did upload a new version of my patch set which shouldn't have happened.  I can help you work through that.21:39
njohnstonthe '1.1' just needs to match whatever is in here: https://review.openstack.org/#/c/251738/27/neutron/objects/qos/rule_type.py21:39
njohnstonajo davidsha: so we could put '2.0' and it would be just as happy21:40
mhickeyBye all. Thanks to all those I met at the moidcycle. I enjoyed the fun. Safe home to those travelling.21:40
mlavallecarl_baldwin: mhhh.... sorry, let's fix it MOnday..... Sam-I-Am is getting nervous, we have to leave21:40
mlavallecarl_baldwin: have a nice weekend!21:40
carl_baldwinmhickey: Bye, have a nice (long) trip back.  It was great to meet you.21:40
mhickeymlavalle: mins the state troppers!:)21:41
mhickeymind*21:41
carl_baldwinmlavalle: bye21:41
mhickeycarl_baldwin: I enjoyde it too.21:41
*** mlavalle has quit IRC21:41
mhickey*enjoyed21:41
* njohnston likes the term 'moidcycle'21:41
carl_baldwinmhickey: :)21:41
*** agireud has quit IRC21:41
* carl_baldwin sure mhickey is just typing way to fast21:42
mhickeynjohnston: sorry; the piano has been drinking!:)21:43
openstackgerritOpenStack Proposal Bot proposed openstack/neutron: Updated from global requirements  https://review.openstack.org/28399121:43
*** jamielennox is now known as jamielennox|away21:43
*** agireud has joined #openstack-neutron21:43
mhickeybrain is shutting down21:43
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-fwaas: Updated from global requirements  https://review.openstack.org/28504121:43
*** mhickey has quit IRC21:44
*** porunov has quit IRC21:45
openstackgerritManjeet Singh Bhatia proposed openstack/python-neutronclient: Fix the unicode for address scope create  https://review.openstack.org/28555721:46
njohnstonsafe travels for those travelling, and happy weekend all.21:49
*** manjeets has quit IRC21:49
*** john-davidge has joined #openstack-neutron21:50
*** ritesh has quit IRC21:52
*** iyamahat has quit IRC21:55
*** iyamahat has joined #openstack-neutron21:55
*** ivar-lazzaro has joined #openstack-neutron21:55
*** baoli has joined #openstack-neutron21:57
*** baoli has quit IRC21:59
*** salv-orlando has joined #openstack-neutron21:59
*** salv-orl_ has quit IRC22:02
*** crose has quit IRC22:02
*** localloo1 has quit IRC22:03
*** boden has joined #openstack-neutron22:05
*** safchain has quit IRC22:05
*** tpsilva has quit IRC22:07
*** gvrangan_ has quit IRC22:09
*** gvrangan has quit IRC22:09
*** baoli has joined #openstack-neutron22:11
*** gvrangan_ has joined #openstack-neutron22:14
*** tbachman has quit IRC22:14
*** gvrangan has joined #openstack-neutron22:14
openstackgerritAssaf Muller proposed openstack/neutron: WIP: Remove auto_schedule_routers code and option  https://review.openstack.org/28548022:15
*** yamamoto has joined #openstack-neutron22:16
*** Marga_ has quit IRC22:16
*** Marga_ has joined #openstack-neutron22:16
*** ranjithd has quit IRC22:19
openstackgerritCarl Baldwin proposed openstack/neutron: Revert "Functional test for address scope"  https://review.openstack.org/28557022:20
*** abhiraut has quit IRC22:21
*** yamamoto has quit IRC22:21
openstackgerritKevin Benton proposed openstack/neutron: Filter HA routers without HA interface and state  https://review.openstack.org/28557222:25
davidshanjohnston, ajo: I'm gonna have to call it a night, weather is pretty bad here and I've a long commute. Will I upload what I have now (just object versioning for QosPolicys and unit tests for it)?22:25
*** thorst_ has quit IRC22:26
*** tiswanso has quit IRC22:26
kevinbentonamuller: still there?22:26
ajodavidsha, sure, perfect, have safe trip back home22:26
amullerkevinbenton: yarp22:26
kevinbentonamuller: https://review.openstack.org/28557222:26
ajodavidsha: thanks a lot22:26
*** iyamahat has quit IRC22:26
*** ivar-lazzaro has quit IRC22:27
davidshaajo: thanks, no problem. I'd stay on but the roads are bad enough during the day. that PS will be up in the next 15 mins22:27
openstackgerritKevin Benton proposed openstack/neutron: Collect details on ARP spoof functional failures  https://review.openstack.org/28518122:29
openstackgerritKevin Benton proposed openstack/neutron: Override addOnException to catch exceptions  https://review.openstack.org/28334022:29
*** abhiraut has joined #openstack-neutron22:30
amullerkevinbenton: that is pretty simple =p22:31
*** baoli has quit IRC22:31
*** abhiraut has quit IRC22:31
*** baoli has joined #openstack-neutron22:33
kevinbentonamuller: yeah22:34
*** rkukura has quit IRC22:36
*** yamahata has quit IRC22:37
*** baoli has quit IRC22:39
*** ivar-lazzaro has joined #openstack-neutron22:40
*** thorst has joined #openstack-neutron22:42
amullerkevinbenton: commented22:43
*** baoli has joined #openstack-neutron22:45
kevinbentonamuller: i was future proofing in case there were other fields! :)22:45
*** gvrangan_ has quit IRC22:46
*** thorst has quit IRC22:46
amullerkevinbenton: in that function specifically we care if the router is actually bound to the agent though no?22:46
amullereven if we envision the future =p22:47
*** gvrangan_ has joined #openstack-neutron22:47
ajohow beautiful is to catch your bugs upfront via tests...22:47
* ajo smiles22:47
*** marcusvrn_ has quit IRC22:47
jckasperkevinbenton: http://www.eatmacs.com/menu/211387022:47
*** gvrangan has quit IRC22:48
ajojckasper, greek restaurants, yummy22:48
ajoI could have dinner again, I almost forgot what I had for dinner :)22:48
jckasperhaven't had any myself22:48
*** Marga_ has quit IRC22:48
*** abhiraut has joined #openstack-neutron22:49
*** Marga_ has joined #openstack-neutron22:49
ajojckasper, Moussaka is a classic :)22:50
kevinbentonamuller: we do, but that would be the place to filter if there are other keys as well22:50
kevinbentonamuller: i suppose it's a case where we can just fix it when it's needed in the future22:50
amullerkevinbenton: the context of that function is per-router-per-host22:50
amullerkevinbenton: so any keys would be per host22:51
amullerkevinbenton: i.e. because of a binding22:51
openstackgerritMerged openstack/neutron: Qos policy RBAC DB setup and migration  https://review.openstack.org/25008122:51
kevinbentonamuller: i understand, but if the router body is supposed to have another key that hasn't been set yet that would be where to filter22:51
kevinbentonamuller: unrelated to the binding22:51
openstackgerritMerged openstack/neutron: Ensure DVR unit tests use '/tmp' directory  https://review.openstack.org/28384322:52
*** baoli has quit IRC22:52
*** iyamahat has joined #openstack-neutron22:52
*** boden has quit IRC22:53
*** Marga_ has quit IRC22:53
amullerkevinbenton: I won't insist22:54
amullerkevinbenton: not important anyway22:54
kevinbentonamuller: updating now22:55
kevinbentonamuller: gonna simplify some more if we're just looking at the binding22:55
ajokevinbenton,  ^ hi, thanks for the quick review (qos rbac and ovo-rbac) :)22:56
*** singhj has quit IRC22:56
*** pradk has quit IRC22:56
*** baoli has joined #openstack-neutron22:58
*** rossella_s has quit IRC22:58
*** fishbone has quit IRC22:58
*** rossella_s has joined #openstack-neutron22:58
openstackgerritKevin Benton proposed openstack/neutron: Filter HA routers without HA interface and state  https://review.openstack.org/28557223:01
kevinbentonamuller: ^^23:01
kevinbentonajo: no prob23:01
*** singhj has joined #openstack-neutron23:02
*** baoli has quit IRC23:02
openstackgerritMerged openstack/neutron: ML2: Increase segment_mtu from 0 to 1500 bytes  https://review.openstack.org/28440723:02
*** jckasper has quit IRC23:03
*** sridhar_ram1 has joined #openstack-neutron23:03
openstackgerritMerged openstack/neutron: Fix test_get_device_id() failure on OSX  https://review.openstack.org/28423423:03
*** singhj has quit IRC23:03
*** neelashah has quit IRC23:04
*** jwarendt has quit IRC23:04
*** BhavyaM has joined #openstack-neutron23:05
*** sridhar_ram has quit IRC23:05
*** rpothier has quit IRC23:06
*** NightKhaos has quit IRC23:06
*** singhj has joined #openstack-neutron23:07
*** dims has quit IRC23:07
*** skamithi has quit IRC23:12
*** yamahata has joined #openstack-neutron23:13
*** jckasper has joined #openstack-neutron23:14
*** Marga_ has joined #openstack-neutron23:15
*** ccard_ has joined #openstack-neutron23:16
*** jwarendt has joined #openstack-neutron23:17
*** yamamoto has joined #openstack-neutron23:17
*** jckasper has quit IRC23:18
*** baoli has joined #openstack-neutron23:19
*** ccard__ has quit IRC23:19
*** Marga_ has quit IRC23:19
openstackgerritDavid Shaughnessy proposed openstack/neutron: DSCP QoS rule implementation  https://review.openstack.org/25173823:23
*** yamamoto has quit IRC23:23
*** amuller has quit IRC23:23
*** armax has quit IRC23:23
davidshaajo: PS is up, sorry for the delay rebased my code without committing the changes.....23:24
*** haplo37 has quit IRC23:24
*** armax has joined #openstack-neutron23:25
*** davidsha has quit IRC23:26
*** tbachman has joined #openstack-neutron23:27
ajodavidsha, no worries, have a good night23:27
ajooh, he was out already :)23:27
*** shwetaap has quit IRC23:28
*** rossella_s has quit IRC23:28
openstackgerritKevin Benton proposed openstack/neutron: Filter HA routers without HA interface and state  https://review.openstack.org/28557223:29
*** singhj has quit IRC23:33
*** dims has joined #openstack-neutron23:34
*** skamithi13 has quit IRC23:36
*** tbachman has quit IRC23:37
*** tbachman has joined #openstack-neutron23:38
*** singhj has joined #openstack-neutron23:38
*** edmondsw has quit IRC23:39
*** sridhar_ram1 has quit IRC23:40
*** skamithi13 has joined #openstack-neutron23:40
*** haplo37 has joined #openstack-neutron23:40
*** erhudy has quit IRC23:40
*** sridhar_ram has joined #openstack-neutron23:42
*** tbachman has quit IRC23:51
openstackgerritMiguel Angel Ajo proposed openstack/neutron: RPC Callback rolling upgrades reporting, and integration  https://review.openstack.org/26804023:51
*** iyamahat has quit IRC23:51
*** yamamoto has joined #openstack-neutron23:54
*** Marga_ has joined #openstack-neutron23:55
*** emagana has quit IRC23:56
*** singhj has quit IRC23:58

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